Разница в версии Cassandra

Question

Я начал читать Cassandra окончательное руководство, основанное на Cassandra 0.7. Теперь я пытаюсь экспериментировать с Cassandra 2.1.5, и кажется, что существует множество различий, которые действительно запутывают.

Например, я вижу, что в версии 0.7 CQL не существует. С другой стороны, модель данных выглядит совсем по-другому. Теперь вы можете определить схему с CQL, а в версии 0.7 не было схемы.

Может ли кто-нибудь вкратце объяснить различия, особенно в отношении модели данных?

Я понимаю, что в версии 0.7 идея была о разных строках длины, то есть в строках с разным количеством столбцов. Но теперь я понимаю, что каждый столбец на самом деле является полем, содержащим ряд параметров, поэтому вы можете иметь столько полей, сколько хотите, в одной и той же строке (тот же ключ).

Может кто-нибудь обобщить различия? Может быть, я не понял правильно.

Answer 1

Важным моментом для рассмотрения является то, что базовая модель хранения остается неизменной. CQL - это просто слой абстракции поверх этой модели, чтобы упростить работу с вашими данными и их моделирование. DataStax MVP Джон Berryman имеет большую статью по этому поводу: Understanding How CQL3 Maps to Cassandra’s Internal Data Structure

В этой статье Berryman отмечает, что:

• Значение первичного ключа CQL используется внутренне в качестве ключа строки (который в новом CQL Парадигма называется «ключ раздела»).
• Имена полей CQL непервичного ключа используются внутренне как имена столбцов. Значения полей CQL непервичного ключа затем внутренне сохраняются как соответствующие значения столбца.

Кроме того, он описывает преимущество использования подхода на основе CQL:

• Это обеспечивает быстрый взгляд вверх по ключу разделов и эффективными сканировании и срезам с помощью ключа кластера.
• Он группирует связанные данные как строки CQL. Это означает, что вы можете сделать в одном запросе то, что в противном случае принимало бы несколько запросов в разных семействах столбцов.
• Позволяет добавлять, изменять и удалять отдельные поля независимо друг от друга.
• Это лучше, чем старая парадигма Кассандры. Доказательство. Вы можете принуждать таблицы CQL вести себя точно так же, как и старые Cassandra ColumnFamilies. (См. Примеры здесь.)
• Он легко распространяется на реализацию наборов списков и карт (которые очень уродливы, если вы работаете непосредственно в старой кассандре), но это для другого сообщения в блоге.
• CQL-протокол допускает асинхронную связь по сравнению с синхронной связью по требованию, требуемой Thrift. В результате CQL способен быть намного быстрее и менее ресурсоемким, чем Thrift - особенно при использовании однопоточных клиентов.

может иметь столько полей, сколько вы хотите в пределах одной строки (тот же ключ).

На самом деле существует жесткий предел около 2 миллиардов столбцов на раздел (rowkey).