О себе Основная область интересов - Oracle, включая настройку производительности и кластерные решения (Real Application Cluster)
Идея Протестировать технологию MySQL Cluster с ПО «Битриксом: Управление сайтом» на предмет масштабируемости базы данных и, в частности, сравнить производительность MySQL с использованием стандартного (myISAM/InnoDB) и кластерного (NDBCluster) методов хранения данных на производительность типичных генерируемых продуктом запросов к БД.
Тестовое оборудование Была выбрана конфигурация из 2-х доспупных, недорогих серверов - Intel Core Duo 2,2GHz, 4GB RAM, 140GB SATA HDD, 2x1GB NIC + выделенная Gigabit Ethernet сеть с использованием отдельного коммутатора 3com 2808 – с избытком обеспечивала минимально необходимые требования. Сразу отмечу, что используемая тестовая конфигурация далека от оптимальной: 6 серверов для обеспечения полной отказоустойчивости, RAID10 из 4 x SCSI + 16GB RAM на каждом data node – но, во-первых, это уже мало похоже на недорогую тестовую конфигурацию и , во-вторых, поскольку основная нагрузка ложится на data nodes, для оценки производительности достаточно было протестировать сервера данных и кластерную систему хранения.
На этих 2-х серверах были расположены все компоненты MySQL Cluster: 2 data nodes, 2 mysql server и один management server. Используемое ПО: Red Hat Enterprise Linux 4 (2.6.9-55.ELsmp), MySQL 5.0.45 (последний рабочий релиз).
[spoiler]
Нестандартные параметры конфигурации серверов MySQL Cluster (рекомендованные в документации MySQL для улучшения производительности):
/etc/my.cnf: ndb-use-exact-count=0 ndb-force-send=1 engine-condition-pushdown=1 /var/lib/mysql-cluster/config.ini: [NDBD DEFAULT] NoOfReplicas=2 MaxNoOfAttributes=100000 DataMemory=1300M IndexMemory=50M MaxNoOfOrderedIndexes=10240 MaxNoOfConcurrentOperations=100000 TimeBetweenLocalCheckpoints=18 NoOfFragmentLogFiles=10 RedoBuffer =48M [TCP DEFAULT] SendBufferMemory=2M ReceiveBufferMemory=1M |
Для сравнения на одном из серверов MySQL была созданы БД с некластерным размещением (myISAM и InnoDB БД) без дополнительной настройки.
Выявленные ограничения Существенные (но не единственные, см. Полное описание в документации MySQL) ограничения кластерной конфигурации, которые влияют на БД «Битрикс»:
• Вся БД должна быть расположена в ОЗУ – для конфигурации из 2-х нодов – целиком на каждом из нодов. Это концептуальная особенность реализации кластерной технологии MySQL. При этом под информацию, хранимую на диске каждым из нодов, рекомендуется резервировать 12-кратный размер БД (в тестовом случае при размере БД ~350MB, кластерные логи на диске занимали более 2GB). В версии 5.1 разработчики обещают допустить размещение части табличных данных на диске, однако, на производительности кластера (в частности, скорости доступа к нелокально хранимым данным) это может сказаться не лучшим образом, imho.
• Таблицы могут иметь только фиксированную длину строки, т.е. при хранении небольших данных в VARCHAR столбцах, место в памяти и на диске будет выделяться по-максимому, что значительно «раздувает» БД. В тестовом случае, например, БД размером 80MB в myISAM, занимала 350 MB в ОЗУ, при использовании NDBCluster.
• Строка таблицы не должна превышать 8KB. Серьёзное ограничение, решить можно храня табличные данные в BLOB. Для БД «Битрикс» это ограничение коснулось только таблицы B_USER.
• В таблице не должно быть более 128 столбцов – таблицы B_STAT_DAY и B_STAT_DAY_SITE потребовалось модифицировать.
Результаты тестов производительности
)*Первые суммируемые цифры –половинки скрипта на 1-м и 2-й нодах, последние - время выполнение объединённого скрипта на myISAM и InnoDB БД.
Тесты проводились с использованием трассировочного модуля Spider, разработанного и любезно предоставленного Максимом Смирновым.
Резюме В MySQL Cluster используется концепция т.н. Shared-nothing cluster, которая, по мнению авторов, избавлена от присущих прочим кластерным решениям слабых мест (shared disk storage для Oracle RAC, например). Однако, появляются новые серьёзные требования: большая память и быстрый интерконнект.
По результатам представленного экспресс-тестирования, трудно рекомендовать технологию к использованию для обеспечения масштабируемости, ввиду драматического снижения производительности при реальных нагрузках. Хотя разработчики честно упоминают в документации, что «response time – не самое главное качество для реально масштабируемого кластера», столь значительное падение производительности трудно признать допустимым. Возможно, что при использовании для хранения данных SCSI RAID, Scalable Coherent Interface (SCI) в качестве кластерного интерконнекта и MySQL Cluster Carrier Grade Solution (платное ПО) можно достичь почти линейной масштабируемости, как описано в , но это достаточно дорогие тесты.
А вот для обеспечения отказоустойчивости небольших БД с невысокими требованиями по производительности этот кластер вполне можно попробовать использовать. «Data node failover» обеспечивается кластерным ПО и происходит автоматически: действительно быстро и прозрачно для пользователя. Для организации «MySQL server connection failover» - универсальный встроенный механизм отсутствует - разработчики предлагают использовать либо официальный MySQL JDBC, Connector/J (обеспечивающий round-robin failover and load-balancing), либо round-robin DNS, либо Hardware load balancing solution(Cisco, Big-IP), либо Software load balancing solution(Linux virtual servers, Linux-HA,…) – выбор есть.
Надеюсь, что разработка MySQL Cluster будет успешно продолжена и в будущий редакциях MySQL мы увидим сравнимое по производительности с традиционными для MySQL (myISAM, InnoDB) кластерное решение для использования на доступном оборудовании.
Насколько я понял из выших выводов - текущая технология в MySQL снижает скорость выполнения операций над данными.
Требование о хранении всей БД в оперативной памяти означает необходимый выделенный сервер для больших проектов - так как даже средних размеров база данных может и не поместится в RAM ограничения на обычном хостинге, если, как вы говорите, она при этом увеличивается в 4+ раза (80 Mb -> 350 Mb).
Вы всё правильно поняли, снижает и, по моим наблюдениям, значительно.
Если говорить о кластере, то потребуется, как минимум, 2 сервера с достаточным объёмом RAM. Что касается увеличения требуемого объёма RAM - это следствие ограничений реализации My SQL Cluster - поля VARCHAR хранятся в максимально допустимом объёме - как CHAR поля, т.е. в отличие от myisam и innodb никакой экономии пространства не получается. В версии 5.1 эта проблема решена, судя по описаниям, однако остались другие проблемы, связанные с объёмом БД: минимальный размер страницы хранения - 32KB, память, занятая таблицей освобождается только при удалении всех данных или таблицы (DROP TABLE or TRUNCATE),...
Те можно ли модифицировать таблицы, чтобы они соответсвовали ограничениям, налагаемыми механизмом хранения NDBCluster? Как это сделать? Куда и где спросить ?
Это, скорее, иллюстрация на тему масштабирование в направлении MySQL
С учетом того, что в принципе кластер на mysql достаточно давно работает в не бетте то почему бы и нет.