Горизонтальная масштабируемость (дублирование) монолитных приложений: как обрабатываются базы данных?

извините за неконкретный вопрос, но он меня сбивает с толку.
Насколько я понимаю, монолитное приложение может масштабироваться двумя способами: вертикально и горизонтально. Последнее предполагает дублирование сервиса путем добавления дополнительных его копий. Мои сомнения касаются роли баз данных в таком подходе.

Скажем, например, у меня есть приложение А, которое подключается к базе данных. Допустим, я дублирую это приложение и называю дубликат A'. Будут ли A и A' совместно использовать одну и ту же базу данных, что позволит базе данных стать узким местом, или будут ли A и A' иметь свои собственные базы данных, что потребует реализации некоторого механизма для обеспечения согласованности данных между двумя экземплярами база данных?


architecture scalability horizontal-scaling
person MFranc    schedule 21.09.2020    source источник
comment
Здесь нужно немного больше пояснений, какой тип хранилища вы используете, какой тип нагрузки у вас есть, что, по вашему мнению, БД может стать узким местом?   -  person Mavi Domates    schedule 21.09.2020
comment
Mavi Мне вообще интересно, со временем Если дублировать приложение более одного раза, оно станет узким местом. Теперь я понятия не имею, какая нагрузка потребуется для этого, но я предполагаю, что это произойдет. Из вашего комментария я бы сказал, что оба подхода возможны в пользу приложений, использующих одну и ту же базу данных?   -  person MFranc    schedule 22.09.2020
comment
БД в таком дизайне будет узким местом, если вы не спроектируете ее. Пример: если у вас есть 2 узла с одним и тем же приложением, один из США, а другой из ЕС, и они пытаются подключиться к одной и той же БД, расположенной в одном из этих мест, вы создаете проблему. Требования действительно имеют значение в этом случае. Вам никогда не придется реализовывать согласованность данных самостоятельно, почти все приличные системы хранения предлагают вам это. Вы должны понимать, будет ли у вас больше операций чтения, чем записи из определенного региона/экземпляра - будет ли достаточно одного аварийного переключения и т. д.   -  person Mavi Domates    schedule 23.09.2020

Ответы (1)


arrow_upward
1
arrow_downward

Существует 2 подхода к горизонтальному масштабированию базы данных:

  1. Используйте базу данных со встроенным горизонтальным масштабированием. Например: Кассандра, MongoD и т. д.
  2. Используйте логику уровня приложения для маршрутизации трафика на соответствующий сервер базы данных. Вы в основном берете набор пользователей и делите их на несколько серверов БД. Так, например, у вас обычно будет метабаза данных/таблица, в которой будут храниться клиенты, сервер БД/строки подключения и т. д., и таблица, в которой хранится сопоставление клиент/сервер. Экран входа/домашний экран приложения будет общим и будет использовать данные из этой метабазы ​​данных. После входа в систему или когда у вас есть информация о том, кто использует, просто направляйте запросы от каждого клиента на сервер БД, с которым они сопоставлены. то есть вы используете динамическую строку подключения на основе пользователя. Вместо пользователя вы можете использовать некоторые другие критерии для горизонтального разделения ваших данных.
person Dharmendar Kumar 'DK'    schedule 28.09.2020