Модель данных Cassandra — семейство столбцов

Я проверил некоторые вопросы здесь, такие как Понимание модели данных Cassandra и Концепция семейства столбцов и модель данных, а также несколько статей о Cassandra, но я до сих пор не понимаю, что это за данные модель.

Cassandra следует модели данных семейства столбцов, которая похожа на модель данных ключ-значение. В семействе столбцов у вас есть данные в строках и столбцах, поэтому двумерная структура, и, кроме того, у вас есть группировка в семействах столбцов? Я предполагаю, что это организовано в семейства столбцов, чтобы иметь возможность разделить базу данных на несколько узлов?

Как строки и столбцы группируются в семейства столбцов? Почему у нас есть семейства столбцов?

Например, допустим, у нас есть база данных сообщений в виде строк:

id: 123, message: {author: 'A', recipient: 'X', text: 'asd'}
id: 124, message: {author: 'B', recipient: 'X', text: 'asdf'}
id: 125, message: {author: 'C', recipient: 'Y', text: 'a'}

Как и зачем нам организовывать это вокруг модели данных семейства столбцов?

ПРИМЕЧАНИЕ. При необходимости исправьте или дополните пример.


nosql database cassandra data-modeling column-family
person croraf    schedule 17.01.2018    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Какой-то неправильный вопрос. Вместо того, чтобы моделировать данные, моделируйте то, как вы собираетесь запрашивать данные. Что вы хотите прочитать? Вы создаете свою модель данных вокруг этого, так как хранилище строго определяет, как вы можете получить доступ к данным. Скорее всего, идентификатор не является ключом, если вы хотите, чтобы автор или получатель при чтении использовали его в качестве ключа раздела с уникальным идентификатором (используйте uuid, а не auto inc) в качестве индекса кластеризации. то есть:

CREATE TABLE message_by_recipient (
  author text,
  recipient text,
  id timeuuid,
  data text,
  PRIMARY KEY (recipient, id)
) WITH CLUSTERING ORDER BY (id DESC)

Затем, чтобы увидеть пять новейших электронных писем для "боб"

select * from message_by_recipient where recipient = 'bob' limit 5

использование timeuuid для идентификатора гарантирует уникальность без узкого места автоматического увеличения, а также обеспечивает сортировку по времени. Вы можете дублировать записи в новом сообщении, записывая в несколько таблиц, чтобы каждое чтение было одним поиском. Если data может стать большим, может потребоваться заменить его на uuid (тип 4) и сохранить его в хранилище больших двоичных объектов или в распределенной файловой системе (например, s3) с его ключом. Это уменьшит влияние на C*, а также снизит стоимость денормализации.

person Chris Lohfink    schedule 17.01.2018