Как смоделировать Cassandra DB для временного ряда, метрики сервера

Question

Меня зовут Даниэль, Я новичок, но долгое время люркер. Я решил изучить Apache Cassandra для моего следующего проекта «Let write some code while the kids sleeping».

Что я пишу, это аккуратный маленький api, который будет читать и писать с базы данных cassandra. У меня было много макете БД разобрался в MongoDB, но для меня пришло время двигаться дальше и расти как инженер :)

Миссия: соберу метрики с серверов в моей стойке, Агенту каждую минуту отправлять полезную нагрузку. У меня есть часть api, которая в значительной степени вычисляется, будет использовать токены JWT, которые подписывают полезную нагрузку. Тип данных, которые я буду хранить, можно увидеть ниже. cpuload, cpuusage, memusage, DiskUsage и т.д.

часть, где я путаюсь с Кассандрой, как написать реальную модель, я понимаю storagengines рода записывает все это в качестве временной ряд на диске для меня делает чтение довольно удивительно. я знаю, что все, что я сейчас буду бить вместе, будет работать для моей лаборатории, так как это jsut 30 machines, , но я пытаюсь понять, как все это делается правильно и как это можно сделать для сценария реальной жизни, такого как плотность сервера, данные, msgstr "добавить предпочитаемую службу мониторинга сервера". :)

Но как вы более опытные инженеры, проектирующие такую ​​схему?

Сценарии использования для базы данных:

• записи полезных нагрузок каждую минуту через API. (Позволяет представить себе то будет по крайней мере 100k пишет в минуту для изучения чего-то полезно)

• Прочитайте активы, связанные с единицами идентификатору пользователя самые последние данные

  • тянуть (3h)
  • тянуть последние данные (ежедневно)
  • тянуть последние данные (еженедельно)
  • тянуть последние данные (ежемесячно)
  • и т.д. и т.п.

• Создавайте ежемесячные отчеты в формате PDF, показывающие время безотказной работы и т. Д.

Если я вставить строки, содержащие полную полезную нагрузку или я лучше вставки их в сервис основе: timeuid | cpuusage
Per обслуживания подряд

CREATE TABLE metrics(
    id uuid PRIMARY KEY, 
    assetid int, 
    serviceType text, 
    metricValue int 
) 

Все в одном

CREATE TABLE metrics(
    id uuid PRIMARY KEY, 
    assetid int, 
    cpuload int, 
    cpuusage int, 
    memusage int, 
    diskusage int, 
) 

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

Примеры для гантелей высоко оценены. Надеюсь, вы сможете расшифровать мой довольно плохой английский.

Только что нашел этот URL-адрес в предложениях SO: Cassandra data model for time series Я думаю, что это то, что касается и меня.

Sincerly Daniel Olsson

Answer 1

Для вашей модели данных, я хотел бы предложить добавить время в качестве колонков кластерных:

CREATE TABLE metrics(
id uuid, 
time timeuuid, 
assetid int, 
cpuload int, 
cpuusage int, 
memusage int, 
diskusage int, 
PRIMARY KEY (id, time) WITH CLUSTERING ORDER BY (time DESC)) 

Используйте убывающий порядок, чтобы сохранить последние показатели первыми. Вы можете затем запрос с помощью предложения LIMIT, чтобы получить самый последний час:

SELECT * FROM metrics WHERE id = <UUID> LIMIT 60 

Или день:

SELECT * FROM metrics WHERE id = <UUID> LIMIT 1440 

В зависимости от того, как долго вы планируете хранить данные, вы можете добавить столбец за год, месяц или дни до таблицы, чтобы ограничить размер раздела. Например, если вы хотите хранить данные в течение 3-х месяцев, колонок месяца может быть добавлен для разделения ключей по идентификатору и месяц:

CREATE TABLE metrics(
id uuid, 
time timeuuid, 
month text, 
assetid int, 
cpuload int, 
cpuusage int, 
memusage int, 
diskusage int, 
PRIMARY KEY ((id, month), time) WITH CLUSTERING ORDER BY (time DESC)) 

Если хранить данные в течение нескольких лет, использование года + месяца или значение даты.

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

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

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