Блог

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

Моя схема:

 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?

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

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

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