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

Question

У меня есть небольшое недоразумение о составных клавишах строк с 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 столбцами, содержащими имена для каждого пользователя?

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

Answer 1

Итак, после перекачки немного больше и reading an article предложено Lyuben Todorov (спасибо) Я нашел ответ на свой вопрос.

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

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

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

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

Это будет представлена ​​в Кассандре в одном ряду, как

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

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

Обновление: Позже я нашел this blog post by Aaron Morton, чем объясняет то же самое в более подробной информации.