Почитал тут всякого про хранение временных рядов (time series), послушал подкаст про Akumuli и пощупал ручками Influx DB. Что хочу сказать?
Почти во всех проектах такого рода первый же рассматриваемый «юзкейс» — это мониторинг серверов (с неизменным киданием говна в сторону RRDtool). В рамках того же подхода довольно неплохо чувствуют себя всякие «классические» SCADA-системы и модный IoT (провести границу между ними уже проблематично). А вот когда начинается что-то нестандартное (с точки зрения разработчиков) — то тут «тушите свет».
Я вот, например, ругался на то, что datetime в SQL неспособен хранить данные с “разрешением” меньше секунды. Любая нормальная TSDB, конечно, поддерживает запись временных меток с хорошей дискретностью — милли-, микро- и даже наносекунды. Но вот возьмем line protocol из Influx DB и попробуем записать несколько подряд идущих значений:
steering,tag1=some,tag2=shit value=1.51 1542646126000000000
steering,tag1=some,tag2=shit value=1.46 1542646126010000000
steering,tag1=some,tag2=shit value=1.40 1542646126020000000
steering,tag1=some,tag2=shit value=1.34 1542646126030000000
steering,tag1=some,tag2=shit value=1.31 1542646126040000000
steering,tag1=some,tag2=shit value=1.28 1542646126050000000
steering,tag1=some,tag2=shit value=1.26 1542646126060000000
steering,tag1=some,tag2=shit value=1.23 1542646126070000000
steering,tag1=some,tag2=shit value=1.20 1542646126080000000
steering,tag1=some,tag2=shit value=1.17 1542646126090000000
steering,tag1=some,tag2=shit value=1.14 1542646126100000000
...ну и так далее
Я взял «живые» данные из автомобильной (точнее, «автосимуляторной») телеметрии (датчик угла поворота руля) с частотой дискретизации в 100 Гц. Полный набор тегов я писать, конечно же, не хочу — скажу только, что их может быть довольно много. Для записи же каждого значения тут требуется передать аж 60 байт (HTTP API позволяет сэкономить несколько байт из временной метки, но в целом получается примерно столько же). Пусть контролируемых параметров — десяток (это, кстати, довольно мало), а частота оцифровки — все те же 100 Гц — и мы непринужденно получаем требуемую скорость обмена данными аж в 480 кБит/с.
Вроде бы немного в наше время гигабитных каналов и всего такого, и жить с этим в принципе можно — но давайте прикинем, сколько data points влезет в канал со скоростью 1 Гбит/с (Gigabit Ethernet на коленке я еще могу представить). Получится что-то около 2 миллионов в секунду — и это уже попадает в категорию Probably unfeasible (на русский это переводится довольно прикольно — «Возможно, невозможно») в руководстве по выбору «железа». Может быть, именно поэтому — как бы вы не пыжились, а пропихнуть в Influx столько данных все равно проблематично — об этом и не задумываются?
Немного больше о совершенно неуместной избыточности и многословности такого рода текстовых форматов подумал автор Akumuli — там хотя бы можно писать наблюдения, относящиеся к одному и тому же моменту, не повторяя всякий раз метку времени и теги. Но блин, я в своей попытке сделать TSDB после трех бутылок пива первым же делом реализовал «наколеночный» бинарный протокол (на основе CoAP — официально это расшифровывается Constrained Applications Protocol, но мне кажется, что Co обозначает Contiki в смысле «из говна и палок»), который позволял писать те самые 2-3 миллиона data points в секунду поверх обычного стомегабитного Ethernet.
Короче говоря, есть некоторые мысли по доведению того поделия до ума — во всяком случае, я видел уже пару систем, где Influx уже слегка неудобен, а при дальнейшем расширении — приближается к пределу своих возможностей.