лента новостей как данные временных рядов на cassandra

Question

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

CREATE TABLE Posts(
    ID uuid, 
    title text, 
    insertedTime timestamp, 
    postHour int, 
    contentURL text, 
    userID text, 
    PRIMARY KEY (postHour, insertedTime) 
) WITH CLUSTERING ORDER BY (insertedTime DESC); 

вопрос я столкнулся в том, когда пользователь посещает страницу сообщений, она извлекает самые последние из них, запрашивая

SELECT * FROM Posts WHERE postHour = ?; 

? = текущий час

Пока пользователь прокручивает вниз, запросы ajax создаются для получения большего количества сообщений с сервера. Javascript отслеживает postHour элемента lastFetched и отправляет обратно сервер вместе с Cassandra PagingState при запросе новых сообщений.

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

Кто-то, пожалуйста, укажите мне в правильном направлении. Спасибо.

Answer 1

Это хорошее начало, но несколько указателей:

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

   PRIMARY KEY ((postYear, postMonth, postDay, postHour), insertedTime) 
   

2. Но все еще есть проблема. Ваш PRIMARY KEY должен однозначно идентифицировать строку (в этом случае сообщение). Я собираюсь предположить, что это возможно, хотя и вряд ли, что два пользователя могут сделать сообщение с тем же значением insertedTime. Что вам действительно нужно, то это добавить ID, чтобы убедиться, что они являются уникальными:

   PRIMARY KEY ((postYear, postMonth, postDay, postHour), insertedTime, ID) 
   

3. На данный момент, я бы рассмотреть только совмещая ID и insertedTime столбцов в один ID колонки типа timeuuid. С учетом этих изменений, ваш финальный стол выглядит следующим образом:

   CREATE TABLE Posts(
       ID timeuuid, 
       postYear int, 
       postMonth int, 
       postDay int, 
       postHour int, 
       title text, 
       contentURL text, 
       userID text, 
       PRIMARY KEY ((postYear, postMonth, postDay, postHour), ID) 
   ) WITH CLUSTERING ORDER BY (ID DESC); 
   

   Независимо от языка программирования вы используете должны иметь способ создания timeuuid от вставленного времени, а затем извлечь, что время от значения timeuuid, если вы хотите показать это в пользовательском интерфейсе или что-то в этом роде. (Или вы можете использовать CQL timeuuid functions для выполнения конвертирования.)

Что касается вашего вопроса о запросе нескольких разделов, да, это совершенно нормально сделать, но вы можете столкнуться с проблемами, если вы не будете осторожны. Например, что происходит, если есть 48-часовой период без сообщений? Вам нужно отправить 48 запросов, которые возвращают пустые результаты, прежде чем, наконец, вернутся к вашему 49-му запросу? (Вероятно, это будет очень медленный процесс, а также дрянной пользовательский интерфейс.)

Есть пару вещей, которые вы могли бы сделать, чтобы попытаться смягчить, что:

1. сделать ваши разделы менее зернистым. Например, вместо того, чтобы делать сообщения за час, сделайте его сообщениями день или сообщениями от month. Если вы знаете, что эти разделы не будут слишком большими (то есть пользователи не будут делать столько сообщений, что раздел становится огромным), это, вероятно, самое простое решение.

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

   CREATE TABLE post_hours (
       postYear int, 
       postMonth int, 
       postDay int, 
       postHour int, 
       PRIMARY KEY (postYear, postMonth, postDay, postHour) 
   ); 
   

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