MySQL Sharding против MySQL Cluster

Учитывая только производительность , может ли MySQL Cluster превзойти решение MySQL для разделения данных? осколок = горизонтальное разделение

Когда я имею в виду шардинг, я имею в виду шардинг, сделанный на прикладном уровне, например, равномерное распределение записей между независимыми экземплярами MySQL. Для двух серверов это может быть (ключ мод 2).

mysql ndbcluster

— GSB
источник

Раскрытие информации: я сотрудник 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

— Фрейзер Клемент
источник

Привет, Фрейзер. Я прочитал ссылку, которую вы предоставили. Просто для пояснения, мой комментарий «составной ключ» был основан на неуникальных индексах. Компания моего работодателя опробовала MySQL Cluster примерно в первом квартале 2007 года, и ей не понравилось из-за низкой производительности. ИМХО, это был неудачный выбор клиента по ключам (небольшая мощность) и его запросы. MySQL Cluster, должно быть, созрел больше с тех пор на основе вашей ссылки. Что касается моего второго утверждения, это то, сколько пользователей MongoDB заполняют конкретные шарды. Некоторые клиенты моего работодателя сделали это с помощью пользовательских настроек MySQL.

— RolandoMySQLDBA

В вашей ссылке упомянуто «упорядоченное сканирование индекса», которое не может быть сокращено, поскольку совпадающие строки не гарантированно хранятся в одном фрагменте таблицы. Вот почему я предлагал изолировать данные в специальные сегменты (узлы данных), чтобы минимизировать места, в которых будут распространяться данные. Поскольку ваш ответ обнаруживает положительную сторону MySQL Cluster, он лучше соответствует оригинальному опубликованному вопросу. Мой ответ ошибочен в пользу осторожности, пессимизма и некоторой наивности сегодняшних возможностей MySQL Cluster.

— RolandoMySQLDBA

Вместо моего разглагольствования и бреда +1 за ваш ответ !!!

— RolandoMySQLDBA

Привет, Роландо. Спасибо за разъяснения. Это правда, что сканирование без упорядоченного индекса является «дорогим» в кластере, так как задействованы все узлы данных. Похоже, что сканирование по низким показателям кардинальности было бы дорого в любой системе, но в кластере они стали заметно дороже. Ваша осторожность и пессимизм, без сомнения, спасли вас не раз :) Спасибо за +1

— Фрейзер Клемент