Zookeeper/Chubby -vs-MySql NDB

Я недавно читал документ Paxos, теорему FLP и т.д. и оценивал Apache Zookeeper для проекта. Я также проходил через Chubby (служба распространения Google для распространения) и различную литературу по нему, доступную в Интернете. Мое фундаментальное использование для Zookeeper заключается в реализации репликации и общей координации для распределенной системы.

Мне было просто интересно, каково конкретное преимущество, которое Zookeeper или Chubby, такие как распределенная система блокировки, приносит в таблицу. В принципе, мне просто интересно, почему я не могу просто использовать кластер MySQL NDB. Я продолжаю слышать, что у MySQL много проблем с репликацией. Я надеялся, что некоторые с большим опытом по этому вопросу могут пролить свет на него.

Спасибо заранее.

Простейший список моих требований:

  • У меня однородная распределенная система.
  • Мне нужны некоторые средства поддержания согласованного состояния во всех моих узлах.
  • Моя система предоставляет услугу, а взаимодействие с клиентами приведет к некоторому изменению коллективного состояния моей системы.
  • Высокая доступность - это цель, поэтому сбой node не должен влиять на услугу.
  • Я ожидаю, что система будет обслуживать по крайней мере пару 1000 req/sec.
  • Я ожидаю, что коллективное состояние системы будет ограничено по размеру (в основном вставки/удаления будут временными... но в устойчивом состоянии я ожидаю много обновлений и чтений)

Ответы

Ответ 1

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

Я могу ответить с точки зрения ZooKeeper. Перед запуском я должен упомянуть, что ZooKeeper не является Chubby clone. В частности, он не делает блокировки напрямую. Он также разработан с учетом различных требований к порядку и производительности.

В ZooKeeper вся копия состояния системы является резидентной. Изменения реплицируются с использованием атомного широковещательного протокола и синхронизируются с диском (с использованием журнала изменений) большинством серверов ZooKeeper перед обработкой. Из-за этого ZooKeeper имеет детерминированную производительность, которая может терпеть неудачи, если большинство серверов работают. Даже при большом отключении, например, при сбое питания, если большинство серверов возвращаются в исходное состояние, состояние системы будет сохранено. Информация, хранящаяся в ZooKeeper, обычно считается основной истиной системы, поэтому очень важны такие гарантии последовательности и долговечности.

Другие вещи, которые ZooKeeper дает вам, связаны с мониторингом состояния динамической координации. Эфемерные узлы позволяют легко обнаруживать ошибки и членство в группах. Гарантии заказа позволяют делать выбор лидеров и блокировку на стороне клиента. Наконец, часы позволяют контролировать состояние системы и быстро реагировать на изменения состояния системы.

Итак, если вам нужно управлять динамической конфигурацией и реагировать на нее, обнаруживать сбои, выбирать лидеров и т.д. ZooKeeper - это то, что вы ищете. Если вам нужно хранить много данных или вам нужна реляционная модель для этих данных, MySQL намного лучше.

Ответ 2

MySQL с Innodb обеспечивает хорошее решение общего назначения и, вероятно, будет легко соответствовать вашим требованиям к производительности на не слишком дорогостоящем оборудовании. Он может легко обрабатывать много тысяч обновлений в секунду на двухъядерном четырехъядерном ящике с достойными дисками. Встроенная асинхронная репликация даст вам большую часть возможностей для ваших требований к доступности - но вы можете потерять несколько секунд данных, если первичный сбой. Некоторые из этих потерянных данных могут быть восстановлены, если первичный ремонт или может быть восстановлен из журналов приложений: можно ли вы терпеть это, зависит от того, как работает ваша система. Меньшая потеря, но более медленная альтернатива - использовать MySQL Innodb с общим диском между первичными и отказоустойчивыми модулями: в этом случае модуль отказоустойчивости возьмет на себя диск, если первичный сбой не будет без потери данных - до тех пор, пока основной не было какой-то дисковой катастрофы. Если общий диск недоступен, DRBD можно использовать для имитации этого путем синхронного копирования блоков диска в блок отказоустойчивости по мере их написания: это может повлиять на производительность.

Используя Innodb и один из вышеперечисленных решений для репликации, ваши данные будут скопированы на ваш блок отказоустойчивости, что является значительной частью проблемы восстановления, но для повторной настройки вашей системы требуется дополнительный клей, чтобы он мог подключить блок отказоустойчивости в режиме on-line, Обычно это выполняется с помощью кластерной системы, такой как RHCS или Pacemaker или Heartbeat (в Linux) или материал MS Cluster для Windows. Эти системы - инструментальные средства, и вам остается не допустить, чтобы ваши руки грязно строили их в решение, соответствующее вашей среде. Тем не менее, для всех этих систем существует короткий период отключения, в то время как система замечает, что Primary не удалось, и перенастраивает систему для использования модуля отказоустойчивости. Это может быть десятки секунд: попытка уменьшить это может сделать вашу систему обнаружения сбоев слишком чувствительной, и вы можете обнаружить, что ваша система не работает излишне.

Перемещение вверх, MySQL NDB предназначен для сокращения времени восстановления и в некоторой степени поможет увеличить вашу базу данных для повышения производительности. Однако MySQL NDB имеет довольно узкий диапазон применимости. Система сопоставляет реляционную базу данных с распределенной хеш-таблицей, поэтому для сложных запросов, связанных с несколькими объединениями между таблицами, между компонентом MySQL и компонентами хранилища (узлами NDB) довольно много трафика, что делает сложные запросы медленными. Тем не менее, запросы, которые подходят хорошо, работают очень быстро. Я несколько раз рассматривал этот продукт, но мои существующие базы данных были слишком сложными, чтобы соответствовать требованиям и потребовали бы большой редизайн, чтобы получить хорошую производительность. Однако, если вы находитесь на стадии разработки новой системы, NDB будет работать хорошо, если вы сможете нести свои ограничения в виду, когда идете. Кроме того, вы можете обнаружить, что вам нужно немало машин для обеспечения хорошего решения NDB: несколько узлов MySQL и 3 или более узлов NDB, хотя узлы MySQL и NDB могут сосуществовать, если ваши потребности в производительности не слишком экстремальные.

Даже MySQL NDB не может справиться с общей потерей сайта - пожар в центре обработки данных, ошибка администратора и т.д. В этом случае вам обычно нужен другой поток репликации, запущенный на сайт DR. Как правило, это выполняется асинхронно, так что связь на межсайтовой ссылке не останавливает всю вашу базу данных. Это обеспечивается опцией NDB Geographic replication (в платной версии telco), но я думаю, что MySQL 5.1 и выше могут обеспечить это изначально.

К сожалению, я мало знаю о Zookeeper и Chubby. Надеюсь, кто-то другой сможет подобрать эти аспекты.