Получение записи в базу данных при выполнении операции удаления в Cassandra

Question

У меня есть веб-служба, которая поддерживает состояние «запроса». Возможными состояниями являются «Active» и «InActive». Я сохраняю информацию запроса в БД Cassandra. У меня две таблицы - одна для активных запросов, другая - для запросов InActive. Оба они имеют одну и ту же схему.

Моя схема выглядит следующим образом:

ActiveRequests{ 
    UserId text, 
    RequestId int, 
    RequestData text 
    PRIMARY KEY(UserId, RequestId) 
} 

Мне нужно реализовать API, который будет двигаться запрос из активного состояния в неактивное состояние. Я планирую сделать это, удалив запись из таблицы Active, а затем добавив удаленную запись в таблицу InActive.

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

EDIT

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

Я хочу, чтобы мои запросы к активному столу были очень быстрыми. Если я хочу запросить все активные запросы в таблице, в которой есть как запросы Active, так и InActive, которые не будут оптимальными. РазделKey является userId, и я ожидаю, что таблица InActive имеет несколько 1000 запросов для данного UserId. Но, Active должен иметь только 10 или более запросов на UserId.

Answer 1

Основной ответ на то, что DELETE возвращает данные, заключается в том, что это действительно не то, что может сделать Кассандра. Удаление в Кассандре - это фактически надпись надгробия. Кассандра вообще не будет читать до записи и нуждается в том, что на самом деле считается анти-шаблоном.

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

Являются ли эти запросы во все времена? Если это так, вы могли бы подумать о том, чтобы разбудить запросы. Таким образом, вы бы одного стола что-то вроде:

Requests{ 
    UserId text, 
    TimeBucket text, 
    RequestId int, 
    RequestData text, 
    Active boolean, 
    PRIMARY KEY((UserId, TimeBucket) RequestId) 
} 

Временные ведра может быть в час или минуту, что когда-либо имеет смысл для вашего использования. Затем вы можете работать с данными ведрами с различными выборами. Это не даст вам слишком большого количества запросов для данного ключа раздела. Предположение - это время, которое достаточно велико, чтобы охватить большинство активных запросов, поэтому вам не нужно также смотреть на все ведра.

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