Мне любопытно узнать, как большие сайты распределяют нагрузку между разными серверами БД в случае, когда пользователи пишут столько же, сколько читают, т.е. когда стандартное решение с одним мастером для приема записи и несколькими ведомыми устройствами, которые позволяют пользователям только читать данные, не работает, потому что это просто превращает главный сервер в узкое место.
Для тех из вас, кто управляет большим сайтом с балансировщиком нагрузки -> несколько веб-серверов -> несколько серверов БД, как равномерно распределить нагрузку между серверами БД, чтобы пользователям (в лучшем случае) не приходилось ждать master для обновления ведомых устройств, или (в худшем случае) пользователи в конечном итоге читают грязные данные с ведомых устройств, которые еще не были обновлены?
Спасибо.
Проверять, выписываться http://highscalability.com/
Вы можете использовать более сложные методы хранения данных в основном для денормализации и сегментирования их на куски, которые вы можете распределить по серверам. Ищите осколки.
Общий ответ, по-видимому, заключается в том, чтобы сделать единую машину для записи БД как можно более мощной, прежде чем вы переходите к этим другим методам.
В большинстве случаев лучший способ решить проблему - это переосмыслить, как работает ваш сайт, чтобы сократить количество операций записи / сделать их доступными для пакетной обработки.
Что вам нужно, так это правильная база данных с несколькими мастерами. И, насколько мне известно, единственный движок БД, который до сих пор надежно это реализовал, - это Oracle. Это в какой-то мере объясняет, почему все большие парни используют Oracle.
При этом MySql поддерживает репликацию с несколькими мастерами, хотя (AFAIK) не в полной производственной версии. Видеть http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-multi-master.html для более подробной информации.
Я предполагаю, что вы говорите о MySQL, исходя из ваших условий. К сожалению, эта СУБД не поддерживает распределенную запись, это поддерживает только NDB.
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-nodes-groups.html
Другим решением может быть: использовать раздел уровня DNS на основе местоположения вашего клиента GEO, разрешающего разные IP-адреса, к которым необходимо подключиться, и в основном разделять данные по этой информации. Есть проблема с такого рода решением, если у вас есть запрос, например, вы хотите узнать, сколько элементов у вас есть в мире, тогда это не будет работать очень хорошо.
Это зависит от сайта и от части сайта.
У некоторых частей будет один сервер записи, который затем будет реплицироваться на несколько серверов чтения.
В других частях сайта будет множество серверов, на каждом из которых будет храниться небольшая часть данных. Например, пара миллионов учетных записей клиентов на сервер базы данных с логикой в приложении, чтобы оно знало, на каком сервере вы находитесь, на основе вашего UserId.
Решение состоит в том, чтобы переосмыслить ваше приложение, чтобы вы могли разделить данные между несколькими серверами баз данных. Иногда это просто ... иногда нет.
Этот ответ не отвечает на заголовок вопроса, потому что он не пытается поддерживать синхронизацию БД, но он отвечает на тело вопроса, связанное с распределением запросов для крупномасштабных веб-сайтов.
Вы можете использовать Sharding для разделения данных, например, у вас есть 26 серверов баз данных, по одному на каждую букву алфавита. Все пользователи с именами, начинающимися с A, переходят на один сервер. Вы можете использовать различные алгоритмы для равномерного распределения запросов. Это сложное решение, которое не следует использовать, пока не будут исчерпаны другие варианты.