Масштабируемая система баз данных, требуется критика - PullRequest
1 голос
/ 16 сентября 2009

Я ищу решение для масштабируемой базы данных для серверной части моего сайта. В последнее время я читал о дизайне баз данных и, похоже, сам разработал идею, которая может сработать. Я думаю, что это новый способ поддержки n баз данных с синхронизированными данными, но я могу ошибаться. Поэтому я прошу ТАК оценить идею и сказать, сумасшедшая она или нет. (или если он уже существует и реализован)

В этой схеме есть группа узлов сервера. На одном узле выполняется балансировщик нагрузки запросов (назовем его A ), а на остальных выполняется типичная dbms, давайте назовем эти узлы N вместе.

Каждый N отключен от других. то есть) узлу в N не нужно связываться ни с кем другим. Каждый N имеет подключение только к A .

Процесс работает следующим образом

  • Все запросы к базе данных проходят через A . (Давайте предположим, что A имеет бесконечную пропускную способность и способность к обработке)
  • A проверяет каждый запрос ( Q ) и определяет, является ли это операцией, которая будет читать из базы данных, или запросом, который будет записывать в базу данных. (в sql чтение будет выбрано и запись будет обновление)
  • Если Q является операцией read , перенаправьте ее на один узлов в N
  • , если Q - операция write , перенаправьте ее на все узлов в N

Если все реализовано правильно, это приводит к тому, что все узлы в N имеют синхронизированный контент базы данных. Запросы, которые только читают данные, должны быть отправлены на один узел.

Эта идея, кажется, работает особенно хорошо для меня, потому что в моей системе очень мало операций записи, менее 1%.

Итак, несколько вопросов по этой идее

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

Ответы [ 3 ]

7 голосов
/ 16 сентября 2009

Типичная настройка для многих операций чтения и записи - наличие главной базы данных для чтения / записи и n реплицированных ведомых баз данных, которые доступны только для чтения. Репликация обрабатывается RBDMS. Запросы только для чтения могут быть сбалансированы по нагрузке на всех ваших n узлах только для чтения, и если ваш мастер чтения / записи временно отключится, по крайней мере, ваше приложение сможет обслуживать операции чтения. Вам не нужен центральный прокси «А», чтобы решить, является ли запрос чтением или записью. Клиент, отправляющий запрос, должен быть достаточно умен, чтобы знать, читает он или пишет. Таким образом, вы не будете узким местом на своем сервере "А".

Ваша предложенная установка имеет явный недостаток в том, что если вы одновременно записываете на n узлов, что если одна или несколько из этих записей завершатся неудачно?

1 голос
/ 16 сентября 2009

Не прямой ответ на ваш вопрос, но SQL Server 2008 уже поддерживает нечто эквивалентное тому, что вы описываете. Она называется Одноранговая транзакционная репликация . Я уверен, что другие RDBMS делают то же самое. Я думаю, что MySQL называет это репликация мастер-мастер.

1 голос
/ 16 сентября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...