Я много читал о доступных вариантах. Я также получил в свои руки 2-е издание High Performance MySQL, которое очень рекомендую.
Вот что мне удалось собрать воедино:
Кластеризация
Кластеризация в общем смысле - это распределение нагрузки по множеству серверов, которые внешнему приложению кажутся одним сервером.
Кластер MySQL NDB
MySQL NDB Cluster - это распределенный механизм хранения в памяти без совместного использования ресурсов с синхронной репликацией и автоматическим разделением данных (извините, я буквально заимствую из книги High Performance, но они там очень хорошо изложили это). Это может быть высокопроизводительное решение для некоторых приложений, но обычно веб-приложения с ним плохо работают.
Основная проблема заключается в том, что помимо очень простых запросов (которые касаются только одной таблицы), кластеру, как правило, придется искать данные на нескольких узлах, что приводит к появлению задержки в сети и значительному замедлению времени выполнения запросов. Поскольку приложение рассматривает кластер как один компьютер, оно не может сказать ему, с какого узла получить данные.
Кроме того, требование оперативной памяти не выполняется для многих больших баз данных.
Континент Секвойя
Это еще одно решение кластеризации для MySQL, которое действует как промежуточное ПО поверх сервера MySQL. Он предлагает синхронную репликацию, балансировку нагрузки и аварийное переключение. Это также гарантирует, что запросы всегда получают данные из последней копии, автоматически выбирая узел, на котором есть свежие данные.
Я прочитал о нем несколько хороших отзывов , и в целом он звучит многообещающе.
Федерация
Федерация похожа на кластеризацию, поэтому я ее тоже потянул. MySQL предлагает объединение через механизм объединенного хранилища. Подобно кластерному решению NDB, оно хорошо работает только с простыми запросами - но еще хуже кластер для сложных (поскольку сетевая задержка намного выше).
Репликация и балансировка нагрузки
MySQL имеет встроенную способность создавать репликации базы данных на разных серверах. Это можно использовать для многих вещей - разделения нагрузки между серверами, горячего резервного копирования, создания тестовых серверов и аварийного переключения.
Базовая настройка репликации включает в себя один главный сервер, обрабатывающий в основном записи, и один или несколько подчиненных серверов, обрабатывающих только чтение. Более продвинутый вариант - это конфигурация мастер-мастер , которая также позволяет масштабировать операции записи за счет одновременной записи нескольких серверов.
У каждой конфигурации есть свои плюсы и минусы, но одна проблема, которую они все разделяют, - это задержка репликации: поскольку репликация MySQL является асинхронной, не все узлы имеют самые свежие данные за все время. Это требует, чтобы приложение знало о репликации и включало запросы с поддержкой репликации, чтобы работать должным образом. Для некоторых приложений это может не быть проблемой, но если вам всегда нужны самые свежие данные, все становится несколько сложнее.
Репликация требует некоторой балансировки нагрузки для разделения нагрузки между узлами. Это может быть простое изменение кода приложения или использование специальных программных и аппаратных решений.
Шардинг и разделение
Шардинг - это обычно используемый подход для масштабирования решений для баз данных. Вы разделяете данные на более мелкие сегменты и распределяете их по разным узлам сервера. Это требует, чтобы приложение было осведомлено об изменениях в хранилище данных, чтобы работать эффективно, поскольку ему необходимо знать, где найти необходимую информацию.
Существуют инфраструктуры абстракции, которые помогают справиться с сегментированием данных, такие как Hibernate Shards , расширение ORM Hibernate (которое, к сожалению, находится в Java. Я использую PHP). HiveDB - еще одно такое решение, которое также поддерживает ребалансировку сегментов .
Другие
Сфинкс
Sphinx - это система полнотекстового поиска, которую можно использовать не только для тестового поиска. Для многих запросов он намного быстрее, чем MySQL (особенно для группировки и сортировки), и может запрашивать удаленные системы параллельно и агрегировать результаты, что делает его очень полезным при использовании с сегментированием.
В общем, sphinx следует использовать с другими решениями для масштабирования, чтобы получить больше доступного оборудования и инфраструктуры. Обратной стороной является то, что вам снова нужен код приложения, чтобы знать о sphinx, чтобы использовать его с умом.
Резюме
Решения для масштабирования различаются в зависимости от потребностей приложения, которому это необходимо. Для нас и для большинства веб-приложений я считаю, что репликация (возможно, с несколькими мастерами) - это способ балансировки нагрузки, распределяющей нагрузку. Разделение конкретных проблемных областей (огромные таблицы) также необходимо для возможности масштабирования по горизонтали.
Я также собираюсь попробовать Continuent Sequoia и посмотреть, действительно ли он может делать то, что обещает, поскольку это потребует наименьшего количества изменений в коде приложения.