Раскрытие информации: я сотрудник MySQL, работаю над MySQL Cluster.
Я бы сказал, что MySQL Cluster может достичь более высокой пропускной способности / хоста, чем защищенный MySQL + InnoDB, при условии, что:
- Запросы просты
- Все данные помещаются в память
С точки зрения задержки MySQL Cluster должен иметь более стабильную задержку, чем защищенный MySQL. Фактическая задержка для данных только в памяти может быть аналогичной.
По мере усложнения запросов и сохранения данных на диске сравнение производительности становится все более запутанным. Чтобы получить более конкретный ответ, вам необходимо подробнее рассказать о вашем приложении и выполняемых вами запросах, а также о количестве хостов и объеме данных. MySQL Cluster недавно получил параллельное локализованное выполнение запросов (AQL), что означает, что он может быть конкурентоспособным с автономным MySQLD, несмотря на то, что данные распределены по нескольким хостам.
MySQL Cluster в настоящее время ограничен «разбиением» более 48 хостов. Осколки MySQL в теории не имеет границ. Однако для данной целевой пропускной способности может потребоваться меньше узлов MySQL Cluster, чем защищенных узлов MySQL.
Более интересные отличия, когда вы смотрите на другие области, кроме производительности:
- MySQL Cluster поддерживает произвольные запросы ко всем шардам
- MySQL Cluster поддерживает произвольные транзакции через все шарды
- MySQL Cluster поддерживает синхронную репликацию сегментов с автоматическим переключением при сбое и восстановлением
- MySQL Cluster поддерживает сетевой узел добавления (расширение кластера)
- Оскверненный MySQL - это скорее «катайся сам»
Наличие встроенного в ваше приложение шардинга дает вам максимальный потенциал масштабирования, но добавляет сложности и ограничивает вашу гибкость с точки зрения межсегментных запросов и операций. Если ваш шардинг преждевременен, то это может стать причиной некоторых проблем для вас. MySQL Cluster позволяет вам получить некоторые преимущества шардинга, не ограничивая свое приложение только одиночным шардом.
Что касается предыдущего ответа, несколько уточнений:
«Хотя MySQL Cluster является ACID-жалобой, он не предоставляет подходящего механизма хранения данных с составными ключами».
MySQL Cluster поддерживает составные первичные и вторичные ключи. Не уверен, что не подходит для этого. Возможно, предыдущий плакат может объяснить?
«Чтобы данные с одинаковыми ключевыми характеристиками хранились в определенном наборе узлов данных, вы можете сделать следующее:
- Переведите все узлы данных в автономный режим, оставив только те узлы данных, для которых вы хотите разместить данные с одинаковыми ключевыми характеристиками.
- Загрузите ваши данные в MySQL Cluster, который заполняет только выбранные вами узлы данных
- Переведите все узлы данных в оперативный режим »
Это неверно Распределение данных не зависит от того, какие узлы подключены к сети в любое время. MySQL Cluster поддерживает различные схемы распределения данных для поддержки описанных вами оптимизаций. Я описываю распределение данных в MySQL Cluster в своем блоге здесь: Распределение данных в MySQL Cluster
