суббота, 20 июля 2024 г.

Какие ошибки допустила команда InfluxDB по ходу своего развития

Сегодня наткнулся на статью от разработчиков плагина для Postgres TimescaleDB "What InfluxDB Got Wrong", в которой коллеги рассуждают об ошибках, которые допустила команда InfluxDB на своем пути построения базы данных для работы с временными рядами. 

Напомню, что в своем блоге я писал серию статей в далеком 2016 году о том, как работать с первой версией базы данных:

Я в своей деятельности на практике много работаю с InfluxDB и, увидев эту статью, я решил поделиться ей в своем блоге, так как многие мысли считаю верными и они коррелируют с моим пониманием проблем.

Ошибки

    Коллеги в своей статье рефлексируют по поводу траектории развития базы данных и анализируют их ошибки, которые они допустили. Кратко по ошибкам.

    1. Вместо того, чтобы совершенствовать свою базу данных, команда InfluxDB произвела не одно, а два переписывания серверной части

      InfluxDB имеет 3 мажорные версии: 1.x, 2.x, 3.x (на момент написания статьи еще нет релиза). И в каждой версии был переписан серверный движок работы с данными. 

    2. InfluxDB дважды меняла свой API запросов

      В 1.x для работы с данными пользователям предлагался InfluxQL, во второй версии команда свернула с пути разработки БД и пошла сторону развития экосистемы мониторинга и предложила своим пользователям новый язык Flux. В версии 3.x разработчики опять возвращаются к языку запросов и говорят о том, что будет SQL. 

      Изменения API доставили наибольшее количество боли, так как командам, использующим InfluxDB в своих приложениях требуется много ресурсов потратить на переходы с одной версии на другую. Мы на своей шкуре это прочувствовали боль перевода своих приложений и безусловно - это отталкивает от дальнейшего использования продукта.

    3. Недостаток внимания InfluxData сбил с толку пользователей (и нанес ущерб их доле на рынке)

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

      Со временем нишевые решения типа grafana и prometheus в итоге вытеснили с рынка аналоги из TICK стека (Telegraf-Prometheus, Chronograf-Grafana). Оказалось, что разработчикам не нужна платформа для мониторинга, и я подтверждаю это - мы использовали только базу данных InfluxDB в своих проектах, так как она была очень удачно спроектирована для своего времени.

    4. Пользователи InfluxDB были наказаны слишком большим количеством опций продукта

      Здесь нас не сильно затронуло, но действительно со временем очень сложно стало ориентироваться в документации Influx - читатель теряется в огромном количестве продуктов и предложений. Иногда складывалось впечатление, что команда специально тебя запутывает, чтобы ты купил у них поддержку =)

    5. InfluxDB — это не PostgreSQL

      Ха-ха - без комментариев. Тут пункт явно предвзятый, так как TimescaleDB построена на Postgres. Что тут сказать - все мы любим Postgres💛🐘 Но не все мы им являемся.

    Выводы

    Подумав немного, я пришел к выводу, что описанные выше ошибки, допущенные командой Influx, можно распространить на любую продуктовую команду. 
    • Продукт не должен отнимать драгоценное время своих пользователей на свою поддержку: будь то миграции на новые мажорные версии или изменения в названиях. Пользователи должны заниматься своим любимым делом - а не писать миграции с одной версии на другую.
    • Распыляться вредно. Погонишься за несколькими зайцами - ни одного не поймаешь.
    • Postgres - отличная БД, которой можно довериться в большинстве случаев. Огромное сообщество, множество плагинов, поддержка стандартов SQL, открытый исходный код.