MySQL Cluster (NDB) против репликации MySQL (InnoDB) для приложений Rails 3: плюсы/минусы?

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

В настоящее время мы запускаем множество внутренних Rails-приложений и нашего сайта на основе Rails. Некоторые из них уже Rails 3, некоторые из них конвертируются в Rails 3. Они все подключаются к следующей установке MySQL.

mysql01 ( master server) => mysql02 (slave) = > (ежедневное резервное копирование БД на диск, которое создается на ежедневной, еженедельной, ежемесячной и полугодовой основе).

Все записи происходят на mysql01, и большинство коротких прочитанных идут к нему, некоторые "более ресурсоемкие чтения" (например, ежемесячные/еженедельные отчеты, которые занимают 3-10 минут для запуска и выводят данные в csv или резервные копии), перейдите в mysql02 сервер. Мы посещаем 3-5 тыс. Посещений в день на нашем сайте и имеем около 20-30 внутренних пользователей, ежедневно использующих различные приложения для инвентаризации, обработки заказов и т.д. Таким образом, эти серверы не особенно находятся под большими нагрузками, кроме тех отчетов, которые запуск ведомого устройства в любом случае.

Все серверы запускаются в пуле virtualized XEN на виртуальных машинах Debian Lenny.

Итак, мы делаем обзор систем, и кто-то бросил предложение переключиться на MySQL Cluster (NDB) setup. Я знаю это теоретически, но на самом деле никогда не запускал его. Так кто-нибудь, у кого есть опыт работы с ним, знает какие-либо про/против против нашей текущей настройки и какие-то особые оговорки, когда речь идет о приложениях Ruby/Rails?

Ответ 1

Есть хорошее сравнение InnoDB и MySQL Cluster (ndb), недавно отправленных в документы... стоит взглянуть: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

Архитектура кластера состоит из пула серверов MySQL, к которым обращаются приложения (приложения); эти серверы MySQL фактически не хранят данные кластера, данные разбиваются по пулу узлов данных ниже. Каждый MySQL-сервер имеет доступ к данным во всех узлах данных. Если один сервер MySQL меняет часть данных, он мгновенно отображается всем другим серверам MySQL.

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

Архитектура MySQL Cluster shared-nothing означает, что она может обеспечить чрезвычайно высокую доступность (99,999% +). Каждый раз, когда вы меняете данные, он синхронно реплицируется во вторую информацию node; если одна из данных node терпит неудачу, запросы чтения и записи приложений автоматически обрабатываются данными резервного копирования node.

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

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

Чтобы получить максимальную производительность и масштабируемость из MySQL Cluster, вам может понадобиться настроить ваше приложение (см. технический документ настройки производительности кластера: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php). Если у вас есть приложение, это обычно не очень важно, но если вы используете другое приложение, которое невозможно изменить, это может быть проблемой.

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