Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования. В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок". В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как: * зависимость пропускной способности на запись от различных параметров; * время исполнения запроса на чтение; * степень сжатия данных; * пропускная способность при нагрузочном тестировании. В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.

1. Выбираем СУБД для
хранения
временных рядов
Павел Филонов

2. Мы слишком часто склонны доверять своему оптимизму
(или эксплуатировать оптимистические надежды своих
спонсоров). Мы слишком часто не хотим прислушиваться к
голосу рассудка и обращаем много внимания на продавцов
панацей, поющих голосами сирен.
Фредерик Брукс «Мифический человеко-месяц»

4. digitalsubstation.ru

5. http://taneco.tatneft.ru/

6. Как мы видим данные

7. Модель данных и характеристики
• Схема
{
“id”: 42,
“ts”: 1023213221,
“value”: 3.14
}
• Число сенсоров ~ 104
• Частота опроса сенсоров ~ 1 раз в секунду

8. Проблема выбора!
www.wordclouds.com

9. Неинженерный подход
 я в другом проекте все хранил в X. Значит, нужно
использовать X;
 я в другом проекте все хранил в X. Значит, нужно
использовать всё что угодно, кроме X;
 а давайте возьмем X, а там уже разберемся;
 мне на конференции рассказали, что X - это
очень «круто»;
 я раньше никогда не работал с X. Давайте
отправим его в «продакшн».

10. Инженерный подход
1. Ознакомиться с литературой
2. Выбрать критерии сравнения
3. Выбрать конкурсантов
4. Выбрать методику тестирования
5. Провести тестирование
6. Провести анализ результатов
7. Оформить отчет
8. Предложить рекомендации
Трудозатраты

11. Критический обзор
• Если тест проводит компания-разработчик СУБД Bingo-BongoDB,
то в нем побеждает
• Bingo-BongoDB
• Для грамотного сравнения пропускной способности
нужно для разных СУБД
• использовать разные данные

12. Критерии
• Пропускная способность на запись
• В зависимости от размеров «батча»
• В зависимости от числа потоков
• Под продолжительной нагрузкой
• Время выполнения запросов
• В зависимости от длины запрашиваемого интервала
• Степень сжатия

13. Конкурсанты

14. Тестовый стенд и версии
Hardware
Core i7-4790
32 Gb RAM
256 Gb SSD (OS)
1 Tb HDD (data)
Software
Ubuntu 16.04.1 amd64
Docker 1.11.2
OpenTSDB 2.2.0
InfluxDB 13.0
MongoDB 3.2.10
PostgreSQL 9.6.0Client
Rust 1.12.1
postgres 0.11
mongo-driver 0.3.0
hyper 0.9

15. Пропускная способность на запись
m — размер батча
k — число потоков
MongoDB

16. Пропускная способность на запись
m — размер батча
k — число потоков
MongoDB

17. Пропускная способность на запись
m — размер батча
k — число потоков
MongoDB

18. Пропускная способность и размер батча

19. Пропускная способность и размер батча

20. Линейная регрессия
𝛼
𝛽
𝛼 ≈ 14𝐾
𝛽 ≈ 22𝐾

21. Нормированные результаты

22. Пропускная способность и число клиентов

23. Пропускная способность и число клиентов

24. Пропускная способность и число клиентов

25. Нормированные результаты

26. Пропускная способность под нагрузкой

27. Пропускная способность под нагрузкой

28. Пропускная способность под нагрузкой

29. Нормированные результаты

30. Время выполнения запросов

31. Время выполнения запросов

32. Нормированные результаты

33. Нормированные результаты

34. Многокритериальное сравнение Важность
критериев
Скалярная
оценка
×
InfluxDB
OpenTSDB
MongoDB
PostgreSQL
Вне конкурса

35. Многокритериальное сравнение Важность
критериев
Скалярная
оценка
×
InfluxDB
OpenTSDB
MongoDB
PostgreSQL
Вне конкурса

36. Многокритериальное сравнение Важность
критериев
Скалярная
оценка
×
InfluxDB
OpenTSDB
MongoDB
PostgreSQL
Вне конкурса

37. Image from: http://analitika-forex.ru

38. Последний конкурсант
Image from: habrahabr.ru

39. Нормированные результаты

40. ×
ClickHouse
InfluxDB

41. ×
ClickHouse
InfluxDB

42. Заключение
• Доверяй, но проверяй
• Use math, Luke
• Субъективную оценку тоже можно измерить

43. Источники
1. Y. Bassil. A Comparative Study on the Performance of the Top DBMS Systems
– paper
2. C. Pungila, O. Aritoni, TF. Fortis. Benchmarking Database Systems for the
Requirements of Sensor Readings – paper
3. B. Cooper, , A. Silberstein, E.Tam, R. Ramakrishnan, and R. Sears.
Benchmarking Cloud Serving Systems with YCSB – paper
4. T. Goldschmidt, H. Koziolek, A. Jansen. Scalability and Robustness of Time-
Series Databases for Cloud-Native Monitoring of Industrial Processes – paper
5. T. Person. InfluxDB Markedly Outperforms Elasticsearch in Time-Series Data
& Metrics Benchmark – blogpost
6. Д. Калугин-Балашов. Как выбрать In-memory NoSQL базу данных с
умом? - slides

44. Источники
7. B. Schwartz. Time-Series Databases and InfluxDB – blogpost
8. K. Eamonn and K. Shruti. On the Need for Time Series Data Mining
Benchmarks: A Survey and Empirical Demonstration – paper
9. R. Sonnenschein. Why industrial manufactoring data need special
considerations – slides
10. S.Acreman. Top10 Time Series Databases – blogpost
11. J. Guerrero. InfluxDB Tops Cassandra in Time-Series Data & Metrics
Benchmark – blogpost
12. J.Guerrero. InfluxDB is 27x Faster vs MongoDB for Time-Series Workloads –
blogpost
13. Яндекс открывает ClickHouse - blogpost

45. Спасибо за внимание!
email: Pavel.Filonov@Kaspersky.com
github: github.com/sdukshis
twitter: @filonovpv