Есть ли недостатки у «избыточной» кластерной колонки?

Question

Я заметил, что изменение обычного столбца Cassandra на столбец кластеризации может значительно уменьшить размер таблицы при некоторых обстоятельствах.

Для этого примера таблицы:

id     UUID        K
time   TIMESTAMP   C
state  TINYINT    (C)
value  DOUBLE

размер 100000 строк оценивается в 3,9 МБ, если state - обычный столбец, или 2,4 МБ, если state - столбец кластеризации (оценивается по методу курс DataStax DS220 ).

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

Второй столбец кластеризации не создаетлюбые новые ограничения на то, что может быть запрошено.SELECT * FROM table WHERE id=? AND time>=? AND time<? все еще в порядке.

Это похоже на беспроигрышную ситуацию.Есть ли какие-либо недостатки, в частности, с точки зрения производительности?

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

---

Дополнительные комментарии Стоит отметить, что в приведенном выше определении вы не можете фильтровать по state без фильтра равенства на time, что делает его не очень полезным для фильтрации state.И если вы поставите столбец state над time, чтобы решить эту проблему, тогда да, вы можете отфильтровать по неравенствам state и time, но если вы хотите, чтобы все состояния (предложение IN), тогда строки возвращались в порядке state сначала, потом time, что опять же не очень полезно.

Answer 1

1) Вы создаете строку для state.Ваша модель данных должна понимать и понимать это.Вы можете потенциально создать две строки с разными state s для одного и того же id, time, что запрещено исходной моделью.

2) Если вы удалите, вам нужно будет либо указать state или вы создадите Range Tombstones (диапазон удаляется, потому что вы удаляете все строки для данных id и time, но это может быть диапазон state с).Надгробия дальности особенно дороги (на пути чтения) в 2.1 и не учитываются должным образом в обработчиках исключений TombstoneOverwhelming до сравнительно недавней версии Cassandra, поэтому избегание надгробий дальности, как правило, хорошая идея, если только они вам не нужны.

Answer 2

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