Горизонтальное масштабирование для любого приложения в конечном итоге будет ограничено по мере увеличения спроса на данные. Эти ограничения определяются нагрузкой и производительностью сервера / базы данных. В какой-то момент, если спрос и нагрузка увеличиваются с масштабированием, количество серверов / баз данных также должно увеличиться. В зависимости от данных, которые хранятся, серверы / базы данных должны будут дублироваться и синхронизироваться, или потребуется использовать какой-то алгоритм хеширования для разделения данных между несколькими серверами. По мере увеличения количества синхронизированных источников данных стоимость репликации / синхронизации этих серверов также увеличивается. Вот почему хэшированный подход может быть более привлекательным для минимизации затрат.
Решения True High Availability очень дороги в реализации. Я также видел различные степени высокой доступности, но по определению это означает абсолютное минимальное время простоя или отсутствие доступа к источнику данных. Для этого требуется большое количество избыточного оборудования, сетей и программного обеспечения, которое может использовать избыточное оборудование без потери возможности доступа к данным в случае сбоя одного из источников данных. Аппаратный сбой неизбежен, это произойдет, а также перебои с питанием и другие случайные природные явления. В зависимости от того, насколько важны эти данные для решения высокой доступности, также потребуется несколько центров обработки данных на нескольких независимых энергосистемах. Очевидно, что это будет очень дорого, поэтому все зависит от того, насколько важны эти данные для конечного пользователя.
Итак, HA - это экстремальный сценарий, требующий дорогой архитектуры. Я обнаружил, что большую часть времени люди заинтересованы в том, чтобы просто минимизировать время простоя, и в зависимости от размера источника данных это может быть достигнуто довольно недорого с добавлением горячих резервов источников данных.