Служитель зоопарка-vs-/Полный-vs-MySql NDB
Я читал газету Паксоса, теорема FLP и т.д. недавно и оценивал Служителя зоопарка Apache для проекта. Я также проходил Полный (Google распределил сервис блокировки), и различная литература по нему, которая доступна онлайн. Мой фундаментальный вариант использования для Служителя зоопарка состоит в том, чтобы реализовать репликацию и общую координацию для распределенной системы.
Я просто задавался вопросом, хотя, что является определенным преимуществом, которое Служитель зоопарка или Полное как распределенная запирающая система приносят к таблице. В основном я просто задаюсь вопросом, почему я не могу только использовать MySQL NDB Cluster. Я продолжаю слышать, что MySQL имеет много проблем репликации. Я надеялся, что некоторые с большим опытом в предмете могли бы пролить некоторый свет на него.
Заранее спасибо..
Упрощенный список моих требований:
- У меня есть гомогенная распределенная система.
- Мне нужны некоторые средства поддержания согласованного состояния через все мои узлы.
- Моя система представляет сервис, и взаимодействие с клиентами приведет к некоторому изменению в коллективном состоянии моей системы.
- Высокая доступность является целью, таким образом потеря работоспособности узла не должна влиять на сервис.
- Я ожидаю систему к сервису по крайней мере несколько 1000 req/sec.
- Я ожидаю, что коллективное состояние системы будет ограничено в размере (в основном вставляет/удаляет, будет переходным..., но в устойчивом состоянии, я ожидаю много обновлений и чтений),
2 ответа
Это зависит от типа данных, которыми вы управляете, а также от масштаба и отказоустойчивости, на которую вы рассчитываете.
Я могу ответить с точки зрения ZooKeeper. Прежде чем начать, я должен отметить, что ZooKeeper не является клоном Chubby. В частности, он не выполняет блокировки напрямую. Он также разработан с учетом других требований к упорядочиванию и производительности.
В ZooKeeper вся копия состояния системы находится в памяти. Изменения реплицируются с помощью протокола атомарной трансляции и синхронизируются на диск (с помощью журнала изменений) большинством серверов ZooKeeper перед обработкой. Благодаря этому ZooKeeper имеет детерминированную производительность, которая может переносить сбои до тех пор, пока большинство серверов работает. Даже при большом сбое, например, отключении электричества, пока большинство серверов не вернется в строй, состояние системы будет сохранено. Информация, хранящаяся в ZooKeeper, обычно считается основной истиной системы, поэтому такие гарантии согласованности и долговечности очень важны.
Другие возможности, которые дает ZooKeeper, связаны с мониторингом динамического состояния координации. Эфемерные узлы позволяют легко обнаруживать сбои и членство в группах. Гарантии упорядочивания позволяют вам делать выборы лидера и блокировку на стороне клиента. Наконец, часы позволяют отслеживать состояние системы и быстро реагировать на его изменения.
Таким образом, если вам нужно управлять динамической конфигурацией и реагировать на нее, обнаруживать сбои, выбирать лидеров и т.д., ZooKeeper - это то, что вам нужно. ZooKeeper - это то, что вы ищете. Если вам нужно хранить много данных или вам нужна реляционная модель для этих данных, MySQL - гораздо лучший вариант.
MySQL с Innodb представляет собой хорошее решение общего назначения, и, вероятно, легко справится с вашими требованиями к производительности на не слишком дорогом оборудовании. Он может легко обрабатывать многие тысячи обновлений в секунду на двух четырехъядерных компьютерах с приличными дисками. Встроенная асинхронная репликация обеспечит вам большую часть требований к доступности - но вы можете потерять несколько секунд данных, если основной сервер выйдет из строя. Некоторые из этих потерянных данных могут быть восстановлены при ремонте основной системы, или могут быть восстановлены из журналов приложений: сможете ли вы с этим смириться, зависит от того, как работает ваша система. Альтернативой с меньшими потерями - но более медленной - является использование MySQL Innodb с общим диском между первичным и отказоустойчивым блоками: в этом случае отказоустойчивый блок возьмет на себя диск при отказе первичного без потери данных - при условии, что первичный не потерпел какой-либо катастрофы диска. Если общий диск недоступен, для имитации этого можно использовать DRBD, синхронно копируя блоки диска на Failover unit по мере их записи: это может повлиять на производительность.
Использование Innodb и одного из описанных выше решений для репликации позволит скопировать данные на аварийное устройство, что является значительной частью проблемы восстановления, но потребуется дополнительная работа по перенастройке системы, чтобы привести аварийное устройство в рабочее состояние. Это обычно выполняется с помощью кластерной системы, такой как RHCS или Pacemaker или Heartbeat (в Linux) или MS Cluster для Windows. Эти системы представляют собой наборы инструментов, и вам остается только запачкать руки, создавая из них решение, подходящее для вашей среды. Однако для всех этих систем существует короткий период перерыва в работе, пока система замечает, что основной сервер вышел из строя, и перенастраивает систему на использование аварийного блока. Это могут быть десятки секунд: попытка уменьшить это время может сделать вашу систему обнаружения сбоев слишком чувствительной, и вы можете обнаружить, что ваша система переходит в аварийное состояние без необходимости.
Двигаясь вверх, MySQL NDB предназначен для сокращения времени восстановления, и в некоторой степени помогает масштабировать вашу базу данных для повышения производительности. Однако MySQL NDB имеет довольно узкий диапазон применимости. Система отображает реляционную базу данных на распределенную хэш-таблицу, поэтому при выполнении сложных запросов, включающих несколько объединений таблиц, возникает довольно большой трафик между компонентом MySQL и компонентами хранения (узлами NDB), что замедляет выполнение сложных запросов. Однако запросы, которые хорошо подходят, выполняются очень быстро. Я рассматривал этот продукт несколько раз, но мои существующие базы данных были слишком сложными, чтобы хорошо вписаться в них, и для достижения хорошей производительности их пришлось бы переделывать. Однако, если вы находитесь на стадии проектирования новой системы, NDB будет хорошо работать, если вы сможете учитывать ее ограничения в процессе работы. Кроме того, вы можете обнаружить, что для обеспечения хорошего решения NDB вам потребуется довольно много машин: несколько узлов MySQL плюс 3 или более узлов NDB - хотя узлы MySQL и NDB могут сосуществовать, если ваши потребности в производительности не слишком высоки.
Даже MySQL NDB не может справиться с полной потерей сайта - пожар в центре обработки данных, ошибка администратора и т.д. В этом случае обычно требуется еще один поток репликации, работающий на DR-сайт. Обычно это делается асинхронно, чтобы разрывы связи на межсайтовом канале не привели к остановке всей базы данных. Это обеспечивается с помощью опции географической репликации NDB (в платной версии для телекоммуникационных компаний), но я думаю, что MySQL 5.1 и выше может обеспечить это нативно.
К сожалению, я мало знаю о Zookeeper и Chubby. Надеюсь, кто-то другой сможет поднять эти аспекты.