Какой тип базы данных использовать при большом объеме информации и высокой скорости её записи/чтения?

Question

[TRIG]

Здравствуйте!
Уточняю суть вопроса на примере:

Есть 1000 измерительных приборов.
Каждый прибор передает одновременно сразу несколько разных показаний (до 30).
Показания нужно снимать одновременно со всех приборов, записывать эти показания в БД и анализировать на предмет колебаний (анализ свой для каждого прибора).
Показания в основном представлены в виде чисел с плавающей точкой, отсутствуют какие-либо сложные типы данных.
Съем показаний, их запись и простой анализ должны происходить за 1 секунду.
Показания снимаются на протяжении 24 часов.
Данные можно периодически полностью очищать (раз в неделю, например), т.к. их хранение на постоянной основе не требуется в БД.

Какой тип БД лучше выбрать под такие цели?
Я изначально начал смотреть в сторону Time Series DataBase (TSDB), но у меня нет уверенности в этом.

Comments

[Василий Банников]

30к флоатов в секунду + метка времени + ключ чтобы отличать одно показание от другого - это выходит порядка 500 мбайт в секунду.

Вроде вполне реально, но с учётом чтения и отправки каких-то алертов единственный узел может не справиться.

На сколько вообще важны задержки и нужно ли при анализе вычитывать показания сразу по нескольким датчикам?

[TRIG]

Задержки критичны, т.е. с учетом всех операций, превышение в 1 секунду на весь цикл может быть фатально.
Запись и чтение всех показаний должно также производиться за 1 секунду. В эту же секунду происходит примитивный анализ в виде сравнения показаний за предыдущую секунду с показаниями текущей секунды.
Да, все еще и одновременно для всей тысячи приборов.

На счет флоатов не уверен. Там скорее всего даблы, т.к. числа не умещаются в диапазон флоатов (пример 99999.99999).
1000 * (30 * 64 * 2) = 3840000 бит (0.5 мегабайта)
Т.е. как минимум данные в чистом виде, без доп. флагов и временных отметок составляют до 0.5 мб в секунду.
Если туда докинуть временные метки (8 бит), флаги (8 бит) и еще что-нибудь примитивное, то 1 мб в секунду - это видимо предел объемов передаваемой полезной информации (исключая служебную) в одну сторону (запись) и столько же в другую (чтение).
Прям со всеми-всеми издержками и объемами 5 мб в секунду - это прям сказочно. Больше - это практически невозможно.
Ключом по логике вещей в TSDB служит временная отметка и/или отметка о приборе. По сути больше ничего не нужно.

Стабильность канала передачи и скорости обработки информации тут не учитывается, но как бы и фиг бы с ним, т.к. это уже другой раздел ПО. Скорость даже в 100 мбит/секунду у канала вообще избыточна, даже половины хватит.
Пока стоит вопрос о выборе именно типа БД.

Answer 1

[mayton2019]

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Comments

[TRIG]

Анализ - это по сути сравнение данных за предыдущий временной промежуток с текущим. Разница, как вы поняли, это как раз 1 секунда (максимум).
Сложные типы данных - это я об объектах. Фактически будут одни примитивные типы.

Схема работы ПО проста:
1. Сняли данные с приборов
2. Записали в БД
3. Сняли следующую порцию данных
4. Записали их в БД
5. Сравнили друг с другом, и сделали что-то, если колебания достигли какой-то константы (критическая отметка, например).

Естественно, я тут не учитываю многопоточность, параллелизм и т.д. Но это все предполагается в ПО по умолчанию.
Вопрос не в сложности анализа для каждого прибора, а в объемах информации.
Прогнозирования тоже нет, мы не пытаемся смотреть в будущее.

А между приборами нет никаких связей, даже косвенных. Каждый прибор живет своей жизнью. Поэтому о консистентности речи даже не идет.

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

Правильно ли выбран тип БД под такие задачи? Или есть варианты лучше?

Answer 2

[Сергей Горностаев]

Проблемы интенсивных нагрузок обычно решают комплексно. Не только выбором подходящих СУБД, брокеров и т.п., но и архитектурно. Например Tesla используют Akka Cluster Sharding для работы с сенсорами своих авто, а работу с базой организовали через event sourcing, так что база данных у них не очень сильно нагружена, несмотря на миллионы запросов в секунду.

Comments

[TRIG]

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

Важно понять, какой тип БД лучше подходит для информации, которая записывается и извлекается строго по заданным временным промежуткам, при том, что сама информация примитивна и однотипна, но в довольно больших объемах.
Пускай это даже будет теоретический вопрос.

[Сергей Горностаев]

TRIG, тогда надо определяться с критериями, как написал mayton2019 в своём ответе. Для сферических условий в вакууме, 30 000 вставок в секунду без проблем вывозит PostgreSQL.

[TRIG]

Сергей Горностаев, а если каждая вставка имеет размер в 1 мб и при этом ее нужно получить еще обратно? И это все менее чем за 1 секунду.

[AUser0]

TRIG, в базу данных данные будет заносить скрипт/API/обрабочик/любое-название. И нелогично записав данные, следующим шагом читать их обратно. Проще всегда держать последнее записанное значение в памяти (в кэше), оттуда и использовать. Сразу снизится поток данных. Конечно при условии, что обработчик сам будет реагировать на скачки значений, выдавать алерты или чего у вас там...

[TRIG]

AUser0, это ни к чему объяснять, потому что уровень архитектуры программы мы даже не затрагиваем.
Меня только вопрос нагрузки и производительности БД интересует, при том если будет необходимо последовательно совершать запись и чтение за единицу времени (1с).
Это как бы теоретический вопрос о пределах возможностей той или иной БД, до практики еще далеко.

[Сергей Горностаев]

TRIG,

а если каждая вставка имеет размер в 1 мб и при этом ее нужно получить еще обратно? И это все менее чем за 1 секунду.

Тогда никакая СУБД сама по себе не подойдёт. Так как ляжет сеть, ведь это 240 или даже 480 гигабит в секунду. Нужен кластер машин, наверняка с геозонами, если они имеют прикладной смысл в вашей задаче. Нужна распределённая СУБД, то есть сразу можно забывать про ACID. Вероятно не удастся обойтись без промежуточного звена в виде Кафки. В некоторых сценариях лучше будет гнать все эти данные в систему потоковой обработки, типа Spark'а, агрегировать и потом уже укладывать в БД. Тогда опять же подойдёт практически любая СУБД, так как на неё нагрузка ложиться не будет. В общем it depends, как всегда с задачами на нагрузку.

Answer 3

[rPman]

В вашей задаче все определит какой именно нужно делать анализ

Съем показаний, их запись и простой анализ должны происходить за 1 секунду.

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

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

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

P.s. и кстати, не важно какая база данных хоть файлы, все решить алгоритм анализа