Сегодня наткнулся на статью от разработчиков плагина для Postgres TimescaleDB "What InfluxDB Got Wrong", в которой коллеги рассуждают об ошибках, которые допустила команда InfluxDB на своем пути построения базы данных для работы с временными рядами.
Напомню, что в своем блоге я писал серию статей в далеком 2016 году о том, как работать с первой версией базы данных:
- Мониторинг с помощью InfluxData. Часть 1. InfluxDB
- Мониторинг с помощью InfluxData. Часть 2. Telegraf
- Мониторинг с помощью InfluxData. Часть 3. Chronograf
Я в своей деятельности на практике много работаю с InfluxDB и, увидев эту статью, я решил поделиться ей в своем блоге, так как многие мысли считаю верными и они коррелируют с моим пониманием проблем.
Ошибки
Коллеги в своей статье рефлексируют по поводу траектории развития базы данных и анализируют их ошибки, которые они допустили. Кратко по ошибкам.
- Вместо того, чтобы совершенствовать свою базу данных, команда InfluxDB произвела не одно, а два переписывания серверной частиInfluxDB имеет 3 мажорные версии: 1.x, 2.x, 3.x (на момент написания статьи еще нет релиза). И в каждой версии был переписан серверный движок работы с данными.
- InfluxDB дважды меняла свой API запросовВ 1.x для работы с данными пользователям предлагался InfluxQL, во второй версии команда свернула с пути разработки БД и пошла сторону развития экосистемы мониторинга и предложила своим пользователям новый язык Flux. В версии 3.x разработчики опять возвращаются к языку запросов и говорят о том, что будет SQL.Изменения API доставили наибольшее количество боли, так как командам, использующим InfluxDB в своих приложениях требуется много ресурсов потратить на переходы с одной версии на другую. Мы на своей шкуре это прочувствовали боль перевода своих приложений и безусловно - это отталкивает от дальнейшего использования продукта.
- Недостаток внимания InfluxData сбил с толку пользователей (и нанес ущерб их доле на рынке)Команда распылилась и вместо того, чтобы сконцентрироваться на отличной идее - базе данных временных рядов, она стала строить платформу для мониторинга (TICK стек).
Со временем нишевые решения типа grafana и prometheus в итоге вытеснили с рынка аналоги из TICK стека (Telegraf-Prometheus, Chronograf-Grafana). Оказалось, что разработчикам не нужна платформа для мониторинга, и я подтверждаю это - мы использовали только базу данных InfluxDB в своих проектах, так как она была очень удачно спроектирована для своего времени. - Пользователи InfluxDB были наказаны слишком большим количеством опций продуктаЗдесь нас не сильно затронуло, но действительно со временем очень сложно стало ориентироваться в документации Influx - читатель теряется в огромном количестве продуктов и предложений. Иногда складывалось впечатление, что команда специально тебя запутывает, чтобы ты купил у них поддержку =)
- InfluxDB — это не PostgreSQLХа-ха - без комментариев. Тут пункт явно предвзятый, так как TimescaleDB построена на Postgres. Что тут сказать - все мы любим Postgres💛🐘 Но не все мы им являемся.
Выводы
Подумав немного, я пришел к выводу, что описанные выше ошибки, допущенные командой Influx, можно распространить на любую продуктовую команду.
- Продукт не должен отнимать драгоценное время своих пользователей на свою поддержку: будь то миграции на новые мажорные версии или изменения в названиях. Пользователи должны заниматься своим любимым делом - а не писать миграции с одной версии на другую.
- Распыляться вредно. Погонишься за несколькими зайцами - ни одного не поймаешь.
- Postgres - отличная БД, которой можно довериться в большинстве случаев. Огромное сообщество, множество плагинов, поддержка стандартов SQL, открытый исходный код.
