#architecture #scalability #horizontal-scaling
#архитектура #масштабируемость #горизонтальное масштабирование
Вопрос:
извините за расплывчатый вопрос, но он поражает мой разум.
Насколько я понимаю, монолитное приложение может масштабироваться двумя способами: по вертикали и по горизонтали. Последнее включает в себя дублирование службы путем добавления дополнительных ее копий. Мои сомнения касаются роли баз данных в этом типе подхода.
Допустим, например, у меня есть приложение A, которое подключается к базе данных. Допустим, я дублирую это приложение и вызываю дубликат A’. Будут ли A и A’ совместно использовать одну и ту же базу данных, что делает возможным, чтобы база данных стала узким местом, или A и A’ будут иметь свои собственные базы данных, что делает необходимым внедрение какого-либо механизма для обеспечения согласованности данных между двумя экземплярами базы данных?
Комментарии:
1. Это требует немного больше разъяснений, какой тип хранилища вы используете, какой тип нагрузки у вас есть, что вы думаете, что БД может стать узким местом?
2. Mavi Мне было интересно, в общем, в конечном итоге, если вы будете дублировать приложение более одного раза, это станет узким местом. Теперь я понятия не имею, какая нагрузка потребуется для этого, но я бы предположил, что это произойдет. Из вашего комментария я бы сказал, что возможны оба подхода в пользу приложений, использующих одну и ту же БД?
3. БД в таком дизайне будет узким местом, если вы не разрабатываете для нее. Пример: если у вас есть 2 узла, на которых запущено одно и то же приложение, один из США, а другой из ЕС, и они пытаются подключиться к одной и той же базе данных, расположенной в одном из этих местоположений, вы создаете проблему. В этом случае требования действительно имеют значение. Вам никогда не придется самостоятельно обеспечивать согласованность данных, практически все приличные системы хранения данных предлагают вам это. Вы должны понимать, будет ли у вас больше операций чтения, чем записи, поступающих из определенного региона / экземпляра — достаточно ли одного перехода на другой ресурс и т. Д…
Ответ №1:
Существует 2 подхода к горизонтальному масштабированию базы данных:
- Используйте базу данных, которая обеспечивает встроенное горизонтальное масштабирование. Например: Cassandra, MongoD и т. Д.
- Используйте логику уровня приложения для маршрутизации трафика на соответствующий сервер базы данных. Вы в основном берете набор пользователей и разделяете их на несколько серверов БД. Так, например, у вас обычно есть «мета» база данных / таблица, в которой будут храниться клиенты, сервер БД / строки подключения и т. Д., И таблица, в которой хранится сопоставление клиент / сервер. Экран входа в приложение / домашний экран будет общим и будет использовать данные из этой «мета» базы данных. После входа в систему или после получения информации о том, кто используется, просто направляйте запросы от каждого клиента на сервер БД, к которому они сопоставлены. т. Е. Вы используете динамическую строку подключения на основе пользователя. Вместо user вы можете использовать некоторые другие критерии для горизонтального разделения ваших данных.
Ответ №2:
Базы данных являются источником истины в монолитных приложениях. Другими словами, это «состояние» вашей системы. Следовательно, даже если у вас несколько экземпляров, имеет смысл сохранить единую базу данных (часто устойчивую и с высокой емкостью), чтобы у вас был единый источник достоверности.
Конечно, реальная жизнь отличается. Из-за масштабирования могут возникать медленные запросы. Для борьбы с этим существует несколько стратегий. Одна из наиболее распространенных стратегий — иметь несколько баз данных для чтения и одну центральную базу данных для записи. Операции записи распространяются на считываемые базы данных. Базы данных для чтения могут быть настроены для обслуживания географических областей. Благодаря этому проблема с узким местом устранена. Конечно, «сглаживание» — это реальная работа, чтобы все это произошло.
На мой взгляд, не лучший выбор иметь несколько баз данных, поскольку это противоречит принципу состояния достоверности (несоответствия данных) в монолитных системах. Кроме того, базы данных дороги.