Как смоделировать кассандру в этой конкретной ситуации?

Question

, если у меня есть структуру таблицы ниже, как я могу запросить по

"source = 'abc' and created_at >= '2016-01-01 00:00:00'"? 

CREATE TABLE articles (
    id text, 
    source text, 
    created_at timestamp, 
    category text, 
    channel text, 
    last_crawled timestamp, 
    text text, 
    thumbnail text, 
    title text, 
    url text, 
    PRIMARY KEY (id) 
) 

Я хотел бы моделировать свою систему в соответствии с этим: http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/

Edit:

Что мы делаем очень подобно тому, что вы предлагаете. Разница заключается в том, что наш первичный ключ не имеет скобок вокруг источника: PRIMARY KEY (source, created_at, id). У нас также есть два других показателя:

CREATE INDEX articles_id_idx ON crawler.articles (id); 
CREATE INDEX articles_url_idx ON crawler.articles (url); 

Наша система очень медленная, как эта. Что ты предлагаешь?

Спасибо за ваши ответы!

Answer 1

Учитывая структуру таблицы

CREATE TABLE articles (
    id text, 
    source text, 
    created_at timestamp, 
    category text, 
    channel text, 
    last_crawled timestamp, 
    text text, 
    thumbnail text, 
    title text, 
    url text, 
    PRIMARY KEY ((source),created_at, id) 
) 

Вы можете оформить следующие запросы:

SELECT * FROM articles WHERE source=xxx // Give me all article given the source xxx 

SELECT * FROM articles WHERE source=xxx AND created_at > '2016-01-01 00:00:00'; // Give me all articles whose source is xxx and created after 2016-01-01 00:00:00 

Пара (created_at, идентификатор) в первичном ключе здесь, чтобы гарантировать статью единственность. В самом деле, можно иметь, в то же created_at время, 2 разные статьи

Answer 2

Учитывая знание от previous question you posted, где я сказал, индекс замедляя запроса вам нужно решить две вещи:

1. Написать статью только если он уже не существует
2. Query статьи, основанной на источник и диапазон запросе на созданной в

основываясь на этих два я бы с двумя таблицами:

Обратный индекс таблицы

CREATE TABLE article_by_id (
    id text, 
    source text, 
    created_at timestamp, 
    PRIMARY KEY (id)) WITH comment = 'Article by id.'; 

Эта таблица будет использоваться для вставки статьи, когда они впервые приходят. Основываясь на возврате после INSERT ... IF NOT EXISTS, вы узнаете, существует ли статья или нет, и если она новая, вы будете писать во вторую таблицу. Также эта таблица может служить для поиска всех ключевых частей для второй таблицы на основе идентификатора статьи. Если вам нужны полные данные о статье, вы можете добавить в эту таблицу также все поля (категория, канал и т. Д.). Это будет тощий ряд, содержащий только одну статью в одном разделе.

Пример вставки:

INSERT INTO article_by_id(id, source, created_at) VALUES (%s,%s, %s) IF NOT EXISTS; 

драйвер возвращает Java, истинным или ложным, был ли применен этот запрос или нет. Вероятно, он такой же в драйвере python, но я его не использовал.

Таблица для запросов по диапазону и запросов по источникам

Как doanduyhai предложил создать вторую таблицу:

CREATE TABLE articles (
    id text, 
    source text, 
    created_at timestamp, 
    category text, 
    channel text, 
    last_crawled timestamp, 
    text text, 
    thumbnail text, 
    title text, 
    url text, 
    PRIMARY KEY ((source),created_at, id) 
) 

В этой таблице вы будете писать только тогда, когда первый ВСТАВИТЬ возвращается истинный смысл у вас есть новый статья, не существующая. Эта таблица будет обслуживать запросы и запросы диапазона по источникам.

рационализаторское предложение

Используя timeuuid вместо timestamp для created_at вы уверены, что не две статьи не может иметь такой же created_at и вы можете потерять id все вместе и полагаться на timeuuid. Однако из второго вопроса я вижу, что вы полагаетесь на внешний идентификатор, поэтому хотели бы упомянуть об этом как о побочном эффекте.