2014-06-20 2 views
0

В сенсорном приложении ежедневно отслеживается до 300 тыс. Объектов в час на 30 метриках, каждый из которых имеет успешные и отказоустойчивые счетчики.Cassandra: Является ли это подходящей схемой для модели данных?

Моя схема:

CREATE TABLE measurements(
    objId int, 
    hour timestamp, 
    metric text, 
    succ int, 
    fail int, 
    PRIMARY KEY (objId, hour, metric)); 

период хранения данных в течение 1 года, таким образом, таблица будет иметь 300 тыс строк каждая из которых имеет 24 * 360 * 30 * 2 колонки (ячейки).

Обычные запросы: получать счетчики, агрегированные за указанный промежуток времени (могут быть дни, недели, месяцы) и определенные объекты (от 1 до сотен).

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

Общий запрос я могу думать:

select * from measurements where objId in (id1, id2, id3...idn) and hour >= <startTime> and hour < <endTime>; 

конечно агрегация придется делать вручную в приложении.

В: Это оптимальный способ структурирования данных с учетом шаблона запроса?

Худший случай - получить «общий» результат за определенный период, что означает учет всех объектов. Это означает, с моей точки зрения, полное сканирование таблицы. Любая рекомендуемая практика для выполнения такой задачи без применения MapReduce?

ответ

0

Если вы знаете, что вы обычно ограничиваете подмножество времени, а возможный набор объектов в течение каждого часа может быть разреженным, вы можете рассмотреть возможность изменения порядка индекса, так что время является первым измерением. Таким образом, вы будете выделять столбцы из ограниченного набора строк, так что вам все равно понадобится multi-get, но если запрос для всех объектов является общим, то количество строк может быть меньше.

Если вы обычно запрашиваете/агрегируете данные в разные моменты времени, вы также можете хранить повторяющиеся данные с большей детализацией времени, например, в день, неделю, месяц и т. Д. Это может значительно ускорить запросы для более крупных временных масштабов , Де-нормализация - ваш друг в Кассандре!

Возможно, что вы сохраняете индексы для обоих заказов и выбираете индекс, основанный на типе запроса, который вы выполняете.

+0

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

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