Подход к модели данных Cassandra

Question

Обратите внимание, что я впервые использую NoSQL, и почти каждая концепция является новой в этом мире NoSQL, будучи долгое время из RDBMS!

В одном из моих тяжелых приложений я хочу использовать NoSQL для некоторой части данных и выходить из MySQL, где транзакции/реляционная модель не имеют смысла. Что я получу, C AP [Доступность и Толерантность раздела].

Данная модель данных проста, как это

ID (integer) | ENTITY_ID (integer) | ENTITY_TYPE (String) | ENTITY_DATA (Text) | CREATED_ON (Date) | VERSION (interger)| 

Мы можем с уверенностью предположить, что эта часть приложения аналогична лесозаготовительной деятельности! Я хотел бы переместить это на NoSQL в соответствии с моими требованиями и отдельно от БД, ориентированного на производительность.

Cassandra говорит, что все в нем просто Map<Key,Value> type! Думая о терминах уровня карты, Я могу использовать ENTITY_ID|ENTITY_TYPE|ENTITY_APP в качестве ключа и хранить остальную часть данных в значениях!

После прочтения пользовательских типов в Кассандре я могу использовать UserDefinedType как значение, которое по существу использует как один ключ, так и несколько значений! В противном случае используйте его как обычный уровень столбца без UserDefinedType! Одна из идей состоит в том, чтобы использовать одну и ту же модель для разных приложений в системах, где это было бы простое ведение журнала/данные о деятельности, можно подталкивать к тому же, поскольку ключ варьируется от приложения к приложению и внутри приложения, каждый объект будет уникальным!

Никакой прикладной/бизнес-функции для доступа к этим данным без ключа или в простых выражениях не требуется получение данных случайным образом!

Ссылки: http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/

Answer 1

Позвольте мне объяснить модель данных Cassandra немного (или, по крайней мере, часть его). Вы создаете такие таблицы:

create table event(
    id uuid, 
    timestamp timeuuid, 
    some_column text, 
    some_column2 list<text>, 
    some_column3 map<text, text>, 
    some_column4 map<text, text>, 
    primary key (id, timestamp ....); 

Обратите внимание на первичный ключ. Указано несколько столбцов. Первый столбец - это ключ раздела. Все «ряды» в разделе хранятся вместе. Внутри раздела данные упорядочиваются с помощью второй, затем третьей, а затем четвертой ... ключей в первичном ключе. Они называются клавишами кластеризации. Для запроса вы почти всегда попадаете в раздел (путем указания равенства в предложении where). Любые дополнительные фильтры в вашем запросе затем выполняются на выбранном разделе. Если вы не укажете ключ раздела, вы делаете запрос с широким диапазоном, который может быть медленным или, скорее всего, тайм-аутом. После того, как вы нажмете раздел, вы можете по очереди фильтровать совпадения на последующих ключах, с запросом диапазона на последнем ключе кластеризации, указанном в вашем запросе. Во всяком случае, все дело в запросе.

С точки зрения структуры у вас есть несколько типов столбцов. Некоторые примитивы, такие как текст, int и т. Д., Но также три коллекции - наборы, списки и карты. Да, карты. UDT обычно более полезны при использовании в коллекциях. например У человека может быть карта адресов: карта. Как правило, вы храните информацию в столбцах, если вам нужно запросить ее или указать на ней, или вы знаете, что каждая строка будет иметь эти столбцы. Вы также можете использовать столбец карты, который позволит вам хранить «произвольные» данные о значении ключа; это то, что, как вам кажется, вы хотите сделать.

Остерегайтесь ... ваш первичный ключ уникален для каждой записи. Если вы сделаете другую вставку с тем же pk, вы не получите ошибку, она просто перезапишет существующие данные. Все в кассандре - это волнение. И вы не сможете изменить значение любого столбца, который находится в первичном ключе для любой строки.

Вы упомянули, что запрос не является фактором. Однако, если вам нужно выполнить агрегацию, вы должны проверить Apache Spark, который очень хорошо работает с Cassandra (а также поддерживает реляционные источники данных .... так что вы должны иметь возможность агрегировать данные в mysql и cassandra для аналитики).

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