Группируйте данные и извлекайте среднее значение в Cassandra cqlsh - PullRequest
Новая
       38

Группируйте данные и извлекайте среднее значение в Cassandra cqlsh

0 голосов
/ 05 января 2019

Допустим, у нас есть пространство клавиш с именем датчиков и таблица с именем sensor_per_row. эта таблица имеет следующую структуру: 

sensor_id | ts | value

В этом случае senor_id представляет ключ раздела, а ts (который является датой создания записи) представляет ключ кластеризации. 

 select sensor_id, value , TODATE(ts) as day ,ts from sensors.sensor_per_row

Результат этого выбора 

  sensor_id | value | day       | ts

 -----------+-------+------------+---------------

  Sensor 2 |  52.7 | 2019-01-04 | 1546640464138

  Sensor 2 |  52.8 | 2019-01-04 | 1546640564376

  Sensor 2 |  52.9 | 2019-01-04 | 1546640664617

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

 sensor_id | system.avg(value) | day
-----------+-------------------+------------
  Sensor 2 |          52.52059 | 2018-12-11
  Sensor 2 |          42.52059 | 2018-12-10
  Sensor 3 |          32.52059 | 2018-12-11

Один из способов, по-моему, использовать udf (пользовательские функции), но эта функция работает только для одной строки. Можно ли выбрать данные внутри udf? Другой способ - использовать java и т. Д. С несколькими запросами на каждый день или с обработкой данных в какой-либо другой точке контакта в качестве веб-службы для отдыха, но сейчас я не говорю об эффективности этого ... какого-либо предложения?

Ответы [ 2 ]

0 голосов
/ 05 января 2019

Так что я нашел решение, я опубликую его на тот случай, если у кого-то еще возникнет тот же вопрос. Когда я читаю моделирование данных , кажется, ответ. Что означает:

В Cassandra db у нас есть ключи разделения и ключи кластеризации . Cassandra имеет возможность обрабатывать несколько вставок одновременно. Это дает нам возможность вставлять данные в более чем одну таблицу одновременно, что в значительной степени означает, что мы можем создавать разные таблицы для одного и того же приложения сбора данных, которое будет использоваться таким же образом, как и материализованные представления (MySql).

Например, допустим, у нас есть схема журнала {sensor_id, region, value}, Первое, что приходит на ум, - это создать таблицу с именем sensor_per_row , например: 

    sensor_id | value | region     | ts

   -----------+-------+------------+---------------

Это очень эффективный способ хранения данных в течение длительного времени, но, учитывая функции Кассандры, не так просто визуализировать и извлекать из них аналитику. Поэтому мы можем создавать разные таблицы с ttl (ttl обозначает время жизни), что просто означает, как долго будут храниться данные.

Например, если мы хотим получить ежедневные измерения нашего конкретного датчика, мы можем создать таблицу с day & sensor_id в качестве ключей разделения и меткой времени в качестве ключа кластеризации с порядком Desc.

Если мы добавим и ttl значение 12 * 60 * 60 * 60, которое обозначает день, мы можем хранить наши ежедневные данные.

Таким образом, при создании, скажем, таблица sensor_per_day с указанным выше форматом и ttl будет фактически давать ежедневные измерения. И в конце дня таблица будет сброшена с помощью новые измерения, пока данные сохраняются в таблице предварительного просмотра sensor_per_row

Я надеюсь, что дал вам идею.

0 голосов
/ 05 января 2019

Ограничения NoSQL

При работе с NoSQL мы обычно должны отказаться:

  1. Некоторые гарантии ACID.
  2. Консистенция от CAP.
  3. Операции тасования: JOIN, GROUP BY.

Вы можете выполнять вышеуказанные операции, считывая данные (строки) из таблицы и суммируя.

Вы также можете обратиться к ответу MAX (), DISTINCT и группировать по Кассандре

...