MySQL кластер догоняет Кассандру?

Question

Я недавно искал решения nosql для нашей довольно большой будущей базы данных и обнаружил, что cassandra хороша, но в Интернете очень мало доступных ресурсов о новых выпусках cassandra, и большинство блогов и статей относятся к версии 0.6, хотя сейчас также реализована поддержка hadoop и hive. С другой стороны, версия кластера mysql также специально предназначена для работы в горизонтальном масштабируемом режиме с использованием обычных серверов.

Поскольку мы привыкли к реляционной модели в течение многих лет, и для перехода на Кассандру потребуется декомпиляция мозга, в то время как продукт все еще не очень зрелый, и сообщество не настолько велико, чтобы быстро реагировать на любую конкретную проблему, которую я проверил веб-сайт профессиональных провайдеров поддержки и их форумы в значительной степени мертвы.

Итак, как сравнить кластер MySQL с Кассандрой, оставив в стороне реляционное и нереляционное сравнение?

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

Я также старался изо всех сил выяснить, как cassandra физически хранит обновленные запросы, например, для строки, когда редактируется подколонка, и добавляется довольно большой кусок данных, как физически хранится эта запись и как быстро осуществляется доступ к этой записи. ? Потому что в MySQL столбцы имеют фиксированную длину, поэтому это не большая проблема.

Answer 1

Чтобы ответить на ваш вопрос физического хранилища, ключевая функция, которая позволяет Cassandra писать быстро, состоит в том, что они только для добавления . То есть Кассандра всегда записывает только последовательные блоки на диск; во время записи не требуется выполнять медленный поиск случайных расположений дисков.

Когда столбец обновляется, происходят две вещи: запись добавляется в журнал фиксации (для восстановления после сбоя), и Memtable в памяти обновляется. Как только Memtable заполнится, он будет записан на диск как новый SSTable. Таким образом, длина данных не имеет значения, поскольку вы не пытаетесь вписать их в структуру диска фиксированной длины.

SSTable доступны только для чтения - вы никогда не возвращаетесь и не перезаписываете старые значения при обновлении, вы просто пишете новые. На чтении, Кассандра сначала ищет в Memtable ключ. Если он не находит его, Кассандра сканирует SSTables в порядке от самого нового до самого старого и останавливается, когда находит ключ. Это дает вам самое последнее значение.

Также есть несколько оптимизаций. Каждый SSTable имеет связанный фильтр Блума для своих ключей, который представляет собой компактный вероятностный индекс, который может давать ложные срабатывания, но не ложные отрицания. Если ключ отсутствует в фильтре Блума, вы можете безопасно пропустить этот SSTable, поскольку он гарантированно не содержит ключ, хотя иногда вы можете прочитать SSTable, который вам не нужен.

Когда вы получаете слишком много SSTable, они объединяются в больший в процессе, называемом compaction . По сути, это делает большую сортировку слиянием на SSTables. Это позволяет Cassandra освободить пространство для значений, которые были перезаписаны или удалены, и дефрагментировать строки, которые были распределены по нескольким таблицам SSTable.

См. http://www.mikeperham.com/2010/03/13/cassandra-internals-writing/ и http://wiki.apache.org/cassandra/MemtableSSTable для получения дополнительной информации.

Answer 2

Вот некоторые области, где я подозреваю, что у Кассандры есть преимущество:

• Отличная поддержка наборов данных, превышающих объем памяти
• Репликация: Cassandra поддерживает произвольное количество полностью распределенных реплик вместо просто разделенных реплик (поэтому вам не нужно иметь количество узлов, делимых на количество ваших реплик в Cassandra, и нет угловых случаев, чтобы иметь дело с вокруг первичного аварийного переключения), лучшая в своем классе поддержка нескольких центров обработки данных, поддержка синхронной репликации, а также асинхронной (важно, если вы заботитесь о полной долговечности) и надежного самовосстановления (передача обслуживания с подсказкой, восстановление при чтении, антиэнтропия). ) чтобы вам никогда не пришлось сдавать резервную копию и восстанавливать ее с нуля
• Нет блокировки во время ALTER TABLE, создания индекса и т. Д.
• Значительно более простое и менее подверженное ошибкам администрирование (сравните http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-online-add-node.html и http://wiki.apache.org/cassandra/Operations#Bootstrap). В частности, я бы обратил ваше внимание на то, сколько клиентских или других узлов необходимо перезапустить в сценарии Cassandra: доли не имеет.

Чтобы уточнить последнее, большинство людей, которые фактически не запускали Cassandra в многоузловом кластере, не понимают, насколько хорошо Cassandra была разработана для этого. Для двухминутного вкуса см. Демо Джейка Лучани .

Answer 3

1-й отказ от ответственности - я работаю в составе группы разработчиков MySQL Cluster

Если вы ищете Cluster, стоит начать с последней версии 7.2 Development Release, которая включает новые возможности для значительного улучшения производительности JOIN, а также новый интерфейс memcached, минуя уровень SQL http://dev.mysql.com/tech-resources/articles/mysql-cluster-labs-dev-milestone-release.html

Если вы уже знакомы с MySQL, то в следующей документации подчеркиваются различия между InnoDB и текущей версией GA 7.1: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndb-innodb-workloads.html

Хотя они не обеспечивают прямых сравнений с Кассандрой, они, по крайней мере, предоставляют самую последнюю информацию о кластере, из которой вы можете основывать любое сравнение

Answer 4

Другим вариантом в наши дни является реляционная модель в cassandra с playORM, и пока вы разбиваете свои действительно большие таблицы, вы можете делать объединения и все, что вам знакомо, с использованием Scalable SQL, например,

@NoSqlQuery(name="findJoinOnNullPartition", query="PARTITIONS p(:partId) select p FROM TABLE as p INNER JOIN p.security as s where s.securityType = :type and p.numShares = :shares"),

ПРИМЕЧАНИЕ. TABLE - это таблица сделок, а p.security ссылается на таблицу безопасности.Сделки разделены, поэтому у них может быть неограниченное количество разделов, а таблица безопасности меньше, поэтому она не разделена, но вы можете делать все SQL Scalabla с необходимыми объединениями.