2013-10-26 3 views
0

Я работаю над созданием схемы семьи колонн Cassandra для моего нижнего варианта использования. Я не уверен, что лучший способ создать семейство столбцов cassandra для моего нижнего варианта использования? Я буду использовать драйвер CQL Datastax Java для этого ..Как получить только информацию, полученную из Кассандры?

Ниже мой случай использования и схема выборки, которые я разработал сейчас -

SCHEMA_ID  RECORD_NAME    SCHEMA_VALUE    TIMESTAMP 
1     ABC      some value     t1 
2     ABC      some_other_value   t2 
3     DEF      some value again   t3 
4     DEF      some other value   t4 
5     GHI      some new value    t5 
6     IOP      some values again   t6 

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

  1. впервые, когда мое приложение работает, я буду просить за все из приведенных выше таблиц .. Значению дать мне все, что из приведенных выше таблиц ..
  2. Затем через каждые 5 или 10 минут , мой backgrou nd будет проверять эту таблицу и попросит дать мне все, что только изменилось (полная строка, если что-то изменилось для этой строки). Поэтому я использую временную метку в качестве одного из столбцов здесь.

Но я не уверен, как спроектировать шаблон запроса таким образом, чтобы оба моих варианта использования были удовлетворены легко и что будет правильным способом создания таблицы для этого? Здесь SCHEMA_ID будет первичный ключ, я имею в виду использовать ...

Я буду использовать CQL и драйвер Datastax Java для этого ..

Обновление: -

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

CREATE TABLE TEST (SCHEMA_ID TEXT, RECORD_NAME TEXT, SCHEMA_VALUE TEXT, LAST_MODIFIED_DATE TIMESTAMP, PRIMARY KEY (ID)); 

INSERT INTO TEST (SCHEMA_ID, RECORD_NAME, SCHEMA_VALUE, LAST_MODIFIED_DATE) VALUES ('1', 't26', 'SOME_VALUE', 1382655211694); 

Потому что, в моем этом прецеденте, я не хочу, чтобы кто-нибудь вставить такой же SCHEMA_ID каждый раз .. SCHEMA_ID должен быть уникальным, когда мы вставляем любую новую строку в эту таблицу .. Так что с вашим примером (@ omnibear), возможно, кто-то может вставить один и тот же SCHEMA_ID дважды? Я прав?

А также о type вы взяли в качестве дополнительного столбца, этот столбец типа может быть record_name в моем примере ..

+0

Off верхней части моей головы: нет необходимости выполнять все варианты использования с 1 таблицей. Одним из принципов хранения NoSQL является использование избыточности, когда это имеет смысл. Вы работаете в распределенной среде, поэтому хранилище не так дорого. Если вы можете решить проблему, создав две вместо одной таблицы, просто сделайте это :-) – omnibear

+0

Спасибо за предложение. Но я думаю, что я могу получить свой второй вопрос с моей текущей табличной архитектурой? Правильно? Если да, то как я могу это сделать? Есть предположения? – AKIWEB

ответ

2

Что касается 1) Cassandra используются для тяжелой письменной формы, много данных на нескольких узлах. Извлечение ВСЕХ данных из такого типа настройки является смелым, поскольку это может включать огромные суммы, которые должны обрабатываться одним клиентом. Лучшим подходом было бы использование pagination. Это natively supported in 2.0.

Относительно 2) Дело в том, что ключи разделов поддерживают только запросы EQ или IN. Для LT или GT (< />) вы используете клавиши столбца. Поэтому, если имеет смысл группировать записи по некоторому идентификатору типа «тип», вы можете использовать это для своего ключа раздела и timeuuid в качестве столбца. Это позволяет запросить все записи новее, чем X, как так

create table test 
    (type int, SCHEMA_ID int, RECORD_NAME text, 
    SCHEMA_VALUE text, TIMESTAMP timeuuid, 
    primary key (type, timestamp)); 

select * from test where type IN (0,1,2,3) and timestamp < 58e0a7d7-eebc-11d8-9669-0800200c9a66; 

Update:

Вы спросили:

кто-то может вставить же SCHEMA_ID дважды?Я прав?

Да, вы всегда можете сделать вставку с существующим первичным ключом. Значения в этом первичном ключе будут обновляться. Поэтому, чтобы сохранить уникальность, UUID часто используется в первичном ключе, например timeuuid. Это уникальное значение, содержащее метку времени и MAC-адрес клиента. Существует excellent documentation on this topic.

Общие рекомендации:

  1. Запишите свои запросы, а затем разработать модель. (Use case!)
  2. Ваши запросы определяют вашу модель данных, которая в свою очередь определяется главным образом вашими основными ключами .

Таким образом, в вашем случае, я бы просто адаптировать мою схему выше, например, так:

CREATE TABLE TEST (SCHEMA_ID TEXT, RECORD_NAME TEXT, SCHEMA_VALUE TEXT, 
LAST_MODIFIED_DATE TIMEUUID, PRIMARY KEY (RECORD_NAME, LAST_MODIFIED_DATE)); 

Что позволяет этот запрос:

select * from test where RECORD_NAME IN ("componentA","componentB") 
    and LAST_MODIFIED_DATE < 1688f180-4141-11e3-aa6e-0800200c9a66; 

the uuid corresponds to -> Wednesday, October 30, 2013 8:55:55 AM GMT 
so you would fetch everything after that 
+0

Большое спасибо за предложение. Теперь это имеет смысл. Но у меня есть одна проблема с этим подходом. Я обновил свой вопрос с моей путаницей. – AKIWEB

+0

Спасибо большое за предложение .. Теперь имеет смысл .. – AKIWEB

Смежные вопросы