Как Cassandra хранит многоколоночный первичный ключ (CQL)

У меня есть небольшое недоразумение о составных ключах строк с CQL в Cassandra. Скажем, у меня есть следующее

cqlsh:testcql> CREATE TABLE Note (
           ... key int,
           ... user text,
           ... name text
           ... , PRIMARY KEY (key, user)
           ... );
cqlsh:testcql> INSERT INTO Note (key, user, name) VALUES (1, 'user1', 'name1');
cqlsh:testcql> INSERT INTO Note (key, user, name) VALUES (1, 'user2', 'name1');
cqlsh:testcql>
cqlsh:testcql> SELECT * FROM Note;

 key | user  | name
-----+-------+-------
   1 | user1 | name1
   1 | user2 | name1

Как хранятся эти данные? Есть 2 строки или один.

Если два, то как можно иметь более одной строки с одним и тем же ключом? Если один из них имеет записи с ключом = 1 и пользователь от "user1" до "user1000" означает ли это, что у него будет одна строка с ключевыми = 1 и 1000 столбцами, содержащими имена для каждого пользователя?

Может кто-нибудь объяснить, что происходит на заднем плане? Спасибо.

Ответы

Ответ 1

Итак, после копания немного больше и чтение статьи, предложенное Любен Тодоров (спасибо) Я нашел ответ на свой вопрос.

Cassandra хранит данные в структурах данных, называемых строками, которые полностью отличаются от реляционных баз данных. Строки имеют уникальный ключ.

Теперь, что происходит в моем примере... В таблице Note У меня есть составной ключ, определенный как PRIMARY KEY (key, user). Только первый элемент этого ключа действует как ключ строки и называется ключом раздела. Внутренне остальная часть этого ключа используется для построения составных столбцов.

В моем примере

 key | user  | name
-----+-------+-------
   1 | user1 | name1
   1 | user2 | name1

Это будет представлено в Кассандре в одной строке как

-------------------------------------
|   | user1:name    | user2:name    |
| 1 |--------------------------------
|   | name1         | name1         |
-------------------------------------

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

Обновление. Позже я нашел этот пост в блоге от Aaron Morton, чем объясняет это более подробно.