Лучшие практики или дизайн для масштабирования / горизонтального масштабирования базы данных для микросервисов

Question

Основным преимуществом микросервисов является то, что один «тип» службы можно масштабировать, используя несколько экземпляров контейнеров и балансировку нагрузки для улучшения с помощью пут.

Но есть одна вещь: несколько экземпляров (т. Е. Контейнеров)«Тип сервиса» совместно используют один и тот же экземпляр базы данных;и это может привести к снижению производительности при записи / чтении нескольких экземпляров в этом экземпляре базы данных.

Традиционно мы увеличиваем вычислительную мощность этого экземпляра базы данных, чтобы удовлетворить высокий спрос.

Основные вопросы для меня: какова текущая лучшая практика / дизайн / решение для горизонтального / горизонтального масштабирования, чтобы мы могли иметь несколько экземпляров этой базы данных и иметь повышение производительности?

ВВ частности, я хочу заархивировать:

• Один экземпляр не работает, другой экземпляр может справиться с нагрузкой -> Высокая доступность

• Можетчтение баланса нагрузки или, возможно, даже запись в несколько экземпляров базы данных

• Поддержание постоянства и согласованности данных в случае, если я хочу создать больше экземпляра базы данных

Насколько мне известно,

Одним из решений является Microsoft SQL Server, обеспечивающий высокую доступность для контейнеров SQL Server, которые могут выполнять большую частьтребования выше (https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sql-server-2017). Но мне интересно, есть ли лучшее решение, позволяющее избежать блокировки технологии?

Еще одно решение, о котором я думаю: репликация на несколько экземпляров с использованием потока CDCДанные из основного экземпляра базы данных для нескольких копий.Это позволяет читать репликацию.

Но я все еще не убежден, потому что для обеспечения согласованности каждый экземпляр службы должен записывать в экземпляр master-database-instance, это также может стать узким местом для экземпляра master-базы данных.

Answer 1

Существует 3 возможных архитектуры базы данных на широком уровне:

1. Один лидер (например, СУБД)
2. Много лидер (например, СУБД в нескольких DC)
3. Лидер меньше (например, Риак, Кассандра)

При переходе сверху вниз в приведенном выше списке потенциал горизонтальной масштабируемости увеличивается, но постоянство становится слабее.

Потенциал масштабируемости увеличивается, посколькубольше узлов могут принимать записи, когда вы идете вниз по списку.Постоянство становится слабее, так как записи требуют времени для распространения или репликации на все узлы, ответственные за данные.Конфликты возникают, когда одна и та же запись записывается в двух разных узлах практически одновременно и поэтому во время репликации система не знает, какой из них правильный.

Существуют различные стратегии разрешения конфликтов.Разные базы данных используют разные стратегии.Вам нужно изучить эти стратегии, чтобы понять, какая из них подходит вашему сценарию использования, и на основании чего вы выбираете свою БД.

Answer 2

При выборе всегда есть компромисс.У базы данных есть свои ограничения, и, несмотря на масштабирование базы данных, мы можем избежать снижения производительности, используя простые рекомендации.вы не можете оставить его в базе данных для обработки высокой частоты запросов и помнить, что масштабирование базы данных является дорогостоящим вариантом, и вы в конечном итоге достигнете пределов базы данных, если не будете приняты правильно, поэтому планируйте всю систему, а не только базу данных.

Приходя к вашей точке, вы можете иметь одного мастера и слейва для чтения и записи по отдельности, это очень распространенный подход, но вы должны полагаться на конечную согласованность, и sql всегда включен, это то, на что вы можете взглянуть.Вы можете кэшировать наиболее часто данные.Если у вас очень высокая частота запросов, вам, возможно, придется учитывать очереди, в которые вы помещаете запрос, и удалять из очереди позже, чтобы избежать снижения производительности базы данных.