Удалить строки и производительность удаления столбцов

Я думаю, все будет зависеть от того, сколько данных вы планируете иметь для данного ключа раздела, который вы в конечном итоге выберете, каков ваш TTL и какие запросы вы делаете.

Обычно я склоняюсь к варианту №1, особенно если ваш TTL одинаков для всех операций записи. Кроме того, если вы используете LeveledCompactionStrategy или DataTieredCompactionStrategy, Cassandra отлично справится с сохранением данных из одного раздела в одной SSTable, что значительно повысит производительность чтения.

Если вы используете вариант № 2, данные для одного и того же раздела, вероятно, могут быть распределены по нескольким уровням (при использовании LCS) или просто по нескольким sstables, что может привести к чтению из большого количества SSTables, в зависимости от характера ваших запросов. . Существует также проблема горячих точек, когда вы можете перегрузить определенные узлы cassandra, если у вас действительно широкий раздел.

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

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

Что касается производительности, считаете ли вы вероятным, что вам нужно будет читать кросс-разделы, когда ваше приложение делает запросы? Например, если у вас есть запрос на «последние 1000 записей», а раздел обычно шире, вам может потребоваться сделать только 1 запрос для варианта № 1. Однако, если вы хотите получить запрос типа «дайте мне все записи», вариант № 2 может быть лучше, так как в противном случае вам нужно будет делать запросы для каждого сегмента.

После создания описанных выше таблиц:

CREATE TABLE option1 (
                 ...   id bigint,
                 ...   bucket bigint,
                 ...   timestamp timestamp,
                 ...   data text,
                 ...   PRIMARY KEY ((id, bucket), timestamp)
                 ... ) WITH default_time_to_live=10;

CREATE TABLE option2 (
                 ...   id bigint,
                 ...   timestamp timestamp,
                 ...   data text,
                 ...   PRIMARY KEY (id, timestamp)  
                 ... ) WITH default_time_to_live=10;

Я вставил тестовую строку:

INSERT INTO option1 (id,bucket,timestamp,data) VALUES (1,2015,'2015-03-16 11:24:00-0500','test1');
INSERT INTO option2 (id,timestamp,data) VALUES (1,'2015-03-16 11:24:00-0500','test2');

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

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

тл;др;

Поскольку вопросы производительности и надгробий будут одинаковыми независимо от того, какой вариант вы выберете, я думаю, что вариант № 2 лучше, просто из-за простоты запросов.