Обработка нескольких запросов как одного результата - PullRequest
0 голосов
/ 29 мая 2018

Допустим, у меня есть эта таблица

CREATE TABLE device_data_by_year (
    year int,
    device_id uuid,
    sensor_id uuid,
    nano_since_epoch bigint,
    unit text,
    value double,
    source text,
    username text,
    PRIMARY KEY (year, device_id, nano_since_epoch,sensor_id)
) WITH CLUSTERING ORDER BY (device_id desc, nano_since_epoch desc);

Мне нужно запросить данные для конкретного устройства и датчика в период между 2017 и 2018. В этом случае будет выдано 2 запроса:

select * from device_data_by_year where year = 2018 AND device_id = ? AND sensor_id = ? AND nano_since_epoch >= ? AND nano_since_epoch <= ?

select * from device_data_by_year where year = 2018 AND device_id = ? AND sensor_id = ? AND nano_since_epoch >= ? AND nano_since_epoch <= ?

В настоящее время я перебираю наборы результатов и строю список со всеми результатами.Я знаю, что это может (и будет) когда-нибудь столкнуться с проблемами OOM.Есть ли лучший подход, как обрабатывать / объединять результаты запроса в один набор?

Спасибо

Ответы [ 2 ]

0 голосов
/ 29 мая 2018

Изменена структура таблицы:

CREATE TABLE device_data (
   week_first_day timestamp,
   device_id uuid,
   sensor_id uuid,
   nano_since_epoch bigint,
   unit text,
   value double,
   source text,
   username text,
   PRIMARY KEY ((week_first_day, device_id), nano_since_epoch, sensor_id)
) WITH CLUSTERING ORDER BY (nano_since_epoch desc, sensor_id desc);

в соответствии с предложением @AlexOtt.Требуются некоторые изменения в логике приложения - например, findAllByYear должен выполнять итерацию в течение нескольких недель.

Возвращаясь к исходному вопросу: вы бы отправили 52 запроса (getDataByYear, один запрос в неделю) илииспользуйте оператор IN здесь?

0 голосов
/ 29 мая 2018

Вы можете использовать IN для указания списка лет, но это не очень оптимальное решение - поскольку поле year является ключом раздела, тогда, скорее всего, данные будут на разных машинах, поэтому один из узловбудет работать как «координатор», и ему нужно будет запросить результаты на другой машине и собрать данные.С точки зрения производительности, 2 асинхронных запроса, выполняемых параллельно, могут быть быстрее, а затем объединяться на стороне клиента.

PS У вашей модели данных довольно серьезные проблемы - вы разбиваете по годам, это означает:

  • Данные не очень хорошо распределены по кластеру - только N = RF-машины будут хранить данные;
  • Эти разделы будут очень большими, даже если вы получите только сотню устройств,отчет об одном измерении в минуту;
  • Только один раздел будет «горячим» - он будет получать все данные в течение года, а другие разделы будут использоваться не очень часто.

Вы можете использовать месяцы или даже дни в качестве ключа раздела для уменьшения размера раздела, но это все равно не решит проблему «горячих» разделов.

ЕслиЯ правильно помню, Курс моделирования данных в DataStax Academy содержит пример модели данных для сенсорной сети.

...