Лучший способ хранить высокочастотные периодические данные временных рядов? - PullRequest
Новая
       8

Лучший способ хранить высокочастотные периодические данные временных рядов?

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

Я создал MVP для проекта nodejs, вот некоторые из функций, которые имеют отношение к вопросу, который я собираюсь задать:

1-Приложение имеет список IP-адресов с действиями CRUD,2-приложение будет пинговать каждый IP-адрес через каждые 5 секунд.3. И отображать для каждого IP-адреса его статус, т. Е. "Жив" или "мертв", а время работы, если "жив"

, я создал работающий MVP на nodejs с помощью библиотеки net-ping, express, mongo и angular.Теперь у меня есть новый запрос функции:

"для расчета времени прохождения сигнала (задержки) для каждого пинга, который генерируется для каждого IP-адреса, и заполнения гистограммы или любого типа диаграммы, которая будет отображатьRTT (время ожидания) истории (1 месяц-1 год) каждого соединения "

Мне нужно сохранить ответ каждого пинга в базе данных, при условии, что в лучшем случае, если каждый документ, который я буду хранить, имеет размер0,5 Кбайт, что позволит хранить данные объемом 9,5 МБ каждый день, 285 МБ каждый месяц и 3,4 ГБ в год для одного IP-адреса, и в моем приложении будет 100-200 IP-адресов.

Какое самое лучшее решение (включая платное), которое наилучшим образом соответствует моим требованиям, учитывая, что приложение может масштабироваться больше?

Ответы [ 2 ]

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

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

предыдущая схема выглядела так: 

{
  timestamp: ISODate("2013-10-10T23:06:37.000Z"),
  type: "Latency",
  value: 1000000
},
{
  timestamp: ISODate("2013-10-10T23:06:38.000Z"),
  type: "Latency",
  value: 15000000
}
Size of each document: 0.22kb
number of document created in an hour= 720
size of data generated in an hour=0.22*720 = 158.4kb
size of data generated by one IP address in a day= 158 *24 = 3.7MB

Поскольку каждый следующий time_Stamp представляет собой шаг в 5 секунд по сравнению с предыдущим, схема может быть оптимизирована для сокращения избыточных данных.Новая схема выглядит следующим образом: 

{
  timestamp_hour: ISODate("2013-10-10T23:06:00.000Z"),// will contain hours
  type: “Latency”,
  values: {//will contain data for all pings in the specific hour
    0: 999999,
    …
    37: 1000000,
    38: 1500000,
    … 
    720: 2000000
  }
}
Size of each document: 0.5kb
number of document created in an hour= 1
size of data generated in an hour= 0.5kb
size of data generated by one IP address in a day= 0.5 *24 = 12kb

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

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

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

Я бы не рекомендовал хранить этоданные в традиционной СУБД или базе данных объектов / документов.

Наилучшим вариантом является использование специализированного механизма базы данных временных рядов, такого как InfluxDB , который может поддерживать понижающую выборку (агрегацию) и необработанные данныеправила хранения

...