Большие данные с очень быстрым доступом

Question

Я столкнулся с проблемой: база данных для технологических установок. Есть до 50 000 датчиков с частотой дискретизации 50 мс. Все измеренные значения должны храниться не менее 3 лет и должны поддерживать запросы в реальном времени (то есть пользователи могут видеть исторические данные с задержкой менее 1 секунды). Недавно я прочитал статью о Time-series Database, у меня есть много вариантов: OpenTSDB, KairosDB, InfluxDB, ...

Я смущен, какой из них подходит для этой цели? Кто-нибудь знает об этом, пожалуйста, помогите мне!

UPDATE 15.06.25

Сегодня я запустить тест, основанный на OpenTSDB. Я использовал Virtual Box для создания кластера из 3 CentOS x64 VM (1 мастер, 2 подчиненных). Конфигурация хоста - 8 ГБ ОЗУ, ядро ​​i5. Конфигурация главной виртуальной машины - 3 ГБ ОЗУ, а конфигурация ведомых устройств - 1,5 ГБ. Я пишу питон программу для отправки данных в OpenTSDB, как показано ниже:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
s.connect(("192.168.10.55", 4242)) 

start_time = time.time() 
start_epoch = 1434192418; 

for x in range(0, 1000000): 
    curr_epoch = start_epoch + x 

    tag1 = "put TAG_1 %d 12.9 stt=good\n" % (curr_epoch) 
    tag2 = "put TAG_2 %d 12.9 stt=good\n" % (curr_epoch) 
    tag3 = "put TAG_3 %d 12.9 stt=good\n" % (curr_epoch) 
    tag4 = "put TAG_4 %d 12.9 stt=good\n" % (curr_epoch) 
    tag5 = "put TAG_5 %d 12.9 stt=good\n" % (curr_epoch) 
    tag6 = "put TAG_6 %d 12.9 stt=good\n" % (curr_epoch) 
    tag7 = "put TAG_7 %d 12.9 stt=good\n" % (curr_epoch) 
    tag8 = "put TAG_8 %d 12.9 stt=good\n" % (curr_epoch) 
    tag9 = "put TAG_9 %d 12.9 stt=good\n" % (curr_epoch) 
    tag10 = "put TAG_10 %d 12.9 stt=good\n" % (curr_epoch) 
    str = tag1 + tag2 + tag3 + tag4 + tag5 + tag6 + tag7 + tag8 + tag9 + tag10 

    s.send(str) 

print("--- %s seconds ---" % (time.time() - start_time)) 

Я бег питона на хосте, и работа завершается после ~ 220 секунд. Итак, у меня есть avg. скорость ~ 45000 записей в секунду.

ОБНОВЛЕНИЕ 15.06.29

На этот раз я использовал только 1 ВМ (5 Гб оперативной памяти, 3 ядра, CentOS 64, псевдо-распределенной Hadoop). Я запускаю 2 процесса python на хосте Windows 7 для отправки 2 половин данных в OpenTSDB. Сред. скорость ввода данных составляла ~ 100 000 записей в секунду.

Answer 1

Чтобы обрабатывать миллион записей в секунду, вам нужно будет установить серьезную инженерию.

Не все базы данных смогут хранить этот объем данных в компактной форме.

Например, ATSD использует от 5 до 10 байтов на образец (тип данных с плавающей точкой) в зависимости от наблюдаемой дисперсии.

Существует тип распределенных (кластерных) баз данных, построенных на базе HBase, которые смогут обрабатывать такую ​​нагрузку.

Например, вы можете попробовать посмотреть openTSDB и ATSD.

Update 1.

Мы запустили следующий тест для вашего конкретного случая использования:

30.000 аналоговых датчиков записи данных типа поплавка, в результате 540.000.000 записей

20000 цифровых датчиков (нули и единицы), что привело к 552 000 000 записей

Данные заняли 3,68 гигабайта. Сжатие было без потерь.

Результатом является среднее значение 3,37 байт на запись.

Это был тест эффективности хранения.

Полное раскрытие информации, я работаю для компании, которая разрабатывает ATSD.

Answer 2

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

Я бы сказал, что зайдите в команду InfluxDB за 8-12 недель, и мы могли бы лучше понять, как справиться с вашей проблемой. Мой совет, однако, заключается в том, чтобы найти способ разбить это. Если вы действительно являетесь дискретизирующими 50k-машинами с интервалом 50 мс, это огромный объем данных, сетевой трафик и т. Д.

Answer 3

MemSQL может обрабатывать 1M второй. Я бы рекомендовал использовать для этого хранилища столбцов Kafka и MemSQL. В зависимости от типа запросов субсекундный ответ очень возможен.

Answer 4

Очень интересный прецедент.

Я не могу говорить за других, так как я только сильно оценил и использовал KairosDB & Кассандра, но я могу говорить о своем собственном опыте.

KairosDB + Cassandra будет поддерживать пропускную способность, но для записи 1M в секунду вам понадобится кластер с несколькими интерфейсами (я бы рекомендовал не менее 10 узлов, но вы должны были протестировать) и серверные серверы (они при необходимости может быть размещен в помещении).

В любом случае пропускная способность 200 выборок в секунду для каждого датчика ... Извлечение исторических данных может быть проблемой для длинных запросов (1s для исторических данных интересен, но вы должны определить количество выборок длительности запроса) ,

Насколько я могу судить, эффективность хранения не будет такой же, как у AOT (вероятно, в два раза больше, что уже хорошо).

Что мне лично нравится с KairosDB & Cassandra и почему мы его приняли: это просто, действительно распространено, KairosDB не возится с данными, дизайн элегантный и не требует сложных систем, Cassandra управляет данными и kairosDB предлагает услуги TSDB, а производительность и эффективность совсем не плохи ... Кроме того, Cassandra намного проще управлять как кластер, чем его коллеги.