Краткое объяснение одной из концепций базы данных для микросервисов

Концепция «ведущий-ведомый» существует уже некоторое время. На самом деле это довольно простая концепция, все, что вам нужно понять, это то, что есть один мастер и много подчиненных. Ведущий-ведомый - это способ оптимизации ввода-вывода в вашем приложении, кроме использования кеширования. Основная база данных служит, так сказать, хранителем информации. Истинные данные хранятся в базе данных master, поэтому запись происходит только туда. С другой стороны, чтение выполняется только в ведомом устройстве. Для чего это? Эта архитектура служит цели защиты надежности сайта. Если сайт получает много трафика и единственной доступной базой данных является одна главная, он будет перегружен запросами на чтение и запись. Делает всю систему медленной для всех на сайте.

Визуализация реализации

На диаграмме примера я использую Postgresql в качестве основного. Postgres - это реляционная база данных. Реляционные базы данных структурированы и просты в обслуживании. В качестве ведомого я использую MongoDB, потому что MongoDB - это нереляционная база данных или NoSQL. Вы можете узнать, как реализовать эту архитектуру, в сообщении в блоге Грега Сабино. Хотя подчиненные базы данных не обязательно должны быть NoSQL, есть еще один пример использования MySQL как в качестве главного, так и в качестве подчиненного устройства. Наличие одного типа базы данных как для ведущего, так и для ведомого может быть удобным, потому что в конечном итоге поддерживать кодовую базу будет намного проще.

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

Чего ждать?

Почему существует концепция «господин-раб»? Представьте себе, что вы пытаетесь управлять крупномасштабной системой и в конечном итоге получаете узкое место на сервере. Несколько позже вы обнаружите, что одна из причин - это трафик чтения / записи на ваш сервер базы данных. Вы останавливаетесь и думаете. «Что теперь?» одним из решений было бы применить главный-подчиненный. Конечно, это может быть не первое, что приходит вам в голову, других методов, таких как использование кластера Redis, может быть достаточно, чтобы поддерживать себя в течение нескольких лет, но эта концепция может быть еще одним отличным вариантом.

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

Мнения

Расходы

По сравнению с добавлением большего количества кластеров в настройку Postgres / SQL Server, я бы сказал, что концепция главный-подчиненный будет дешевле и может иметь аналогичные или даже лучшие результаты, чем первая.

В конце концов, какой объем трафика сможет эффективно обработать реляционная база данных? Вероятно, много, но не так много, как около трех подчиненных кластеров MongoDB. Я не имею в виду, что 3 кластера MongoDB более эффективны, чем одна реляционная база данных, но в долгосрочной перспективе я бы сказал, что наличие подчиненных баз данных NoSQL может быть преимуществом.

Различия в реализации

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

Реализация кеширования тоже не сильно поможет базе данных. Кэширование приведет только к избранным данным, которые будут доступны в вашем кеше. Если запрошенные данные недоступны, процесс чтения будет происходить в мастере. Внедрение кэширования отлично подходит для оптимизации вашего сайта, но концепция главный-подчиненный работает лучше, если у нас есть отдельный источник данных, идентичный главному, который можно использовать для чтения. Вот как я себе представляю кеширование, это не пример того, как делать master-slave:

В приведенном выше примере архитектура является примером того, чем отличаются кеширование и главный-подчиненный. Чтобы выполнить кэширование WITH в режиме master-slave, я, вероятно, сделал бы это так:

Сложность архитектуры

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

Если честно, здесь многое может пойти не так. Что делать, если репликация не удалась? Сколько времени должна занять синхронизация между главной базой данных Postgres и MongoDB? Разве Redis не хватило бы? Зачем вам вообще нужно беспокоиться?

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

Простым способом было бы использовать распределенную базу данных, такую ​​как CosmosDB, в качестве альтернативы NoSQL MongoDB от Microsoft Azure. CosmosDB работает, добавляя кластеры к себе и данным для обработки исключительных нагрузок. Таким образом, при использовании этой службы в Azure с вас взимается плата за использование RU (тип счетчика чтения / записи данных, используемого для CosmosDB), а не за количество активных кластеров CosmosDB.

Но давайте посмотрим правде в глаза, иногда легкий выход просто неинтересен!

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

Заключение

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

Эта статья была адаптирована и изменена из исходной статьи, опубликованной на https://www.datadriveninvestor.com 28 мая 2020 г.

Особая благодарность Ричарду М. Симармате за ценный вклад.