Разработка схемы для запроса выбора между двумя отдельными датами - PullRequest
2 голосов
/ 22 мая 2019

У меня есть таблица сообщений, например:

messages (
    user_id uuid,
    id uuid,
    message blob,
    created_at timestamp,
    updated_at timestamp,
    PRIMARY KEY (user_id, id)
)

Я могу создать MV для сортировки и выбора сообщений по updated_at.Но когда мне нужно выбрать последние обновленные сообщения в последний раз при синхронизации клиента (например, select where updated_at > 1555602962006 and created_at < 1555602962006) - единственный способ - выбрать все сообщения по updated_at и отфильтровать строки в коде?Это нормальная практика в производстве?

Может быть, в этом случае можно создать какой-то токен для сортировки путем объединения created_at и updated_at или чего-то еще?

1 Ответ

1 голос
/ 23 мая 2019

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

Один из способов, которые я смоделировал в прошлом, состоял в том, чтобы иметь один столбец для метки времени, но разные строки для типа времени. Я соберу здесь пример, используя вашу таблицу выше. Для времени я буду использовать месяц; по сути, я знаю, что буду когда-либо запрашивать только сообщения, созданные / обновленные за последний месяц (которые могут работать, а могут и не работать).

CREATE TABLE messages_by_month (
  month_bucket int,
  event_time timestamp,
  user_id uuid,
  id uuid,
  message text,
  event text,
  PRIMARY KEY (month_bucket, event_time, id));

После ВСТАВКИ некоторых данных я могу теперь запросить диапазон созданных и обновленных времен события, например:

SELECT id,event_time,event,message
FROM messages_by_month 
WHERE month_bucket=201905
  AND event_time > 1558619000000
  AND event_time < 1558624900000;

 id                                   | event_time                      | event   | message
--------------------------------------+---------------------------------+---------+---------
 a4d60c29-ad4e-4023-b869-edf1ea6207e2 | 2019-05-23 14:00:00.000000+0000 | CREATED |     hi!
 66e78a1e-dbcb-4f64-a0aa-6d5b0e64d0ed | 2019-05-23 14:20:00.000000+0000 | CREATED |     hi!
 f1c59bf4-1351-4527-a24b-80bb6e3a2a5c | 2019-05-23 15:00:00.000000+0000 | UPDATED |    hi2!
 a4d60c29-ad4e-4023-b869-edf1ea6207e2 | 2019-05-23 15:20:00.000000+0000 | UPDATED |    hi3!

(4 rows)

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

Примечание. В этом примере вам нужно следить за размерами разделов. Возможно, вам придется добавить еще один ключ раздела, если эта таблица получает более 50–100 тыс. Сообщений в месяц.

...