На прошлой неделе мы запустили бета-версию TimescaleDB с нашим первым сообщением в блоге, а затем разместили его в Hacker News…
С тех пор наш пост HN получил более 300 баллов с более чем 130 комментариями, наш пост в блоге был просмотрен более 20000 раз, а наш проект набрал 1000 звезд на GitHub. (Какая неделя!)
Наш пост в HN также вызвал множество замечательных комментариев (некоторые положительные, некоторые отрицательные, но все одинаково ценные). В частности, мы заметили 6 тем, которые мы хотели бы обсудить подробно.
Но сначала большое спасибо сообществу HN! Без вашей поддержки мы не смогли бы достичь этих вех.
И это только начало. В ближайшие месяцы мы планируем: подробно описать нашу архитектуру, дизайнерские решения и мотивацию; выпускать новые оптимизации и функции; публиковать (и открывать исходный код) больше тестов; интегрироваться с важными сторонними инструментами (например, Grafana); и более. Ваши отзывы и поддержка будут неоценимы по мере того, как мы продолжаем совершенствоваться и расти.
Вот 6 идей из наших комментариев к публикациям HN:
1. TimescaleDB опровергает некоторые предположения о базе данных
Оглядываясь назад на эти последние несколько дней, можно сказать, что самое большое, что бросилось в глаза, - это здоровый характер дискуссии. Люди очень увлечены базами данных и имеют глубокие убеждения, некоторые из которых оспариваются TimescaleDB.
Вот один вопрос, который волновал многих: Действительно, хранилище на основе строк для данных временных рядов?
Хотя я ценю PostgreSQL каждый день, разве я единственный, кто считает это плохой идеей? Механизм PG на основе строк - это полная противоположность эффективному хранению и извлечению временных рядов схожих шаблонов, почти не давая сжатия. Столбчатое хранилище, естественно, должно быть намного лучше (BigQuery, Redshift, Citus), что приведет к появлению специализированных магазинов, таких как Influx, Prometheus или KDB. Prometheus, например, удается сжать средний 64-битный образец FP, включая метаданные, всего до 1,3–3,3 байта в зависимости от движка. Поскольку большая часть материалов БД связана с вводом-выводом, это обычно приводит к ускорению поиска как минимум на порядок. (Через endymi0n)
Хотя хранилища данных, ориентированные на столбцы, хороши для некоторых типов запросов (например, поиск значений ключа, сведение в одном поле), они весьма ограничивают или неэффективны, когда дело доходит до более сложных запросов (например, сложных предикатов, включающих несколько столбцов). . Именно на эту мощность запросов мы делаем ставку на PostgreSQL.
Мы также считаем, что наличие доступа к полному интерфейсу SQL - это тоже мощный инструмент. Этот ответ на комментарий endymi0n отражает это мнение:
Не все данные временных рядов являются метриками (для чего адаптированы Influx и Prometheus). Любой вид журнала аудита - например, для поддержки консоли обслуживания клиентов - будет временным рядом довольно сложных многополевых записей. Заказы (и модификации заказов), запросы на поддержку, выплаты и переводы… Большая часть деловой активности подпадает под эгиду временных рядов, номинально неизменяемых, даже если это не числа. Работе с такими данными определенно помогает исчерпывающий диалект SQL.
Возьмем противоположную позицию: чья инфраструктура настолько велика, что необходим специализированный SQL и механизм хранения (например, Influx)? На самом деле не так много компаний ... так почему же инфраструктура всегда заканчивается этими особыми версиями вещей в виде снежинок? (Через solidsnack9000)
(Кстати: мы действительно думаем, что TimescaleDB хорошо работает с метриками, но мы работаем над тем, чтобы сделать это проще. Подробнее в пункте 4 ниже.)
Тем не менее, одна из причин популярности баз данных NoSQL заключается в том, что не всем нравится SQL:
Хорошая производительность временных рядов - это больше, чем просто использование хранилища на основе столбцов. Вам также понадобится язык запросов, чтобы воспользоваться этим и обеспечить гарантии упорядочения. SQL, хотя он и пытался заново изобрести себя, является очень плохим языком для запросов к базам данных TS. (Через jnordwick)
Хотя мы считаем, что SQL - это очень богатый язык для данных временных рядов, мы признаем, что SQL не для всех (например, популярность PromQL). Тем не менее, SQL - довольно мощный инструмент, и многие разработчики с ним знакомы:
Вау, много очень критических комментариев. Я, например, считаю, что это очень хорошая идея. Прямо сейчас у меня есть вариант использования, который в значительной степени соответствует манифесту шкалы времени. Возможности SQL очень важны [sic]. Я хочу перенести текущую настройку на шкалу времени. Дам вам, ребята, как дела. (Через артель интеллигент)
Фактически, возможность применять SQL к данным временных рядов также может заставить вас переосмыслить, как наиболее эффективно хранить ваши данные, например, чтобы воспользоваться такими функциями, как JOINs:
Соединения с данными временных рядов звучат очень хорошо. (Через мркурт)
(Да, мы тоже так думаем.)
2. Ложь, проклятая ложь и ориентиры
Контрольные показатели - это палка о двух концах при оценке базы данных. С одной стороны, при таком большом количестве вариантов баз данных тесты обеспечивают некоторую степень объективного сравнения. Тем не менее, как мы все видели, тесты можно тщательно выбирать и настраивать таким образом, чтобы не раскрывать всей картины (аналогично жалобе на статистику в целом).
Что вы планируете делать для сравнительного анализа? Я не ожидаю, что вы сделаете что-то вроде STAC, но попытаетесь ли вы найти общие тесты, которые используют другие?
Я работаю с базами данных TS в течение долгого времени, и никогда не ошибаюсь, что у каждого поставщика баз данных всегда есть тесты, показывающие, что они лучшие (не говоря уже об этом, когда вы выпускаете свой собственный набор тестов, и вы самый быстрый / самый маленький / самый лучший, не удивлюсь и не поверю вам).
Я не ожидаю, что вы будете самым быстрым со строковой архитектурой, и это было бы несправедливым сравнением с несвободными базами данных, но мне нужны реалистичные цифры.
На самом деле, если бы вы заняли 2–3 места по сравнению с рабочими нагрузками конкурентов, я был бы гораздо более впечатлен [sic]. (Через jnordwick)
Мы согласны с тем, что тщательно подобранные тесты - это своего рода шок для нашей отрасли (и мы сами испытали раздражение из-за невозможности воспроизвести ранее разрекламированную производительность). Мы делаем все возможное, чтобы быть прозрачными в отношении тестов, и вскоре опубликуем более широкие результаты, которые, мы надеемся, представят нашу базу данных в честном свете (например, не всегда будут представлять TimescaleDB в положительном свете). Мы также ожидаем, что эти результаты прояснят, почему компромиссы между хранилищами, ориентированными на строки и столбцы, являются более сложными и тонкими, чем многие думают (то есть ваша модель данных и рабочие нагрузки запросов имеют большое значение).
Оценка и сравнение систем баз данных - это намного больше, чем просто сравнение результатов тестов. Например, PostgreSQL имеет множество функций (например, сложные типы данных, геопространственная поддержка через PostGIS), которые многие базы данных NoSQL даже не поддерживают. Оперативное управление (включая резервное копирование, аварийное восстановление и т. Д.) Также не учитывается тестами. С другой стороны, PostgreSQL хуже сжимает данные, и это тоже необходимо учитывать при любой справедливой оценке. Наша цель в будущем будет заключаться в предоставлении более целостной оценки системы более широкому сообществу (что также позволяет нам избавиться от нашего научного зуда).
Следите за обновлениями, чтобы узнать больше о тестах и оценках в ближайшее время.
3. Сообщество PostgreSQL активно
Одна из самых важных вещей, которые мы вынесли из посещения PGConf пару недель назад, - это активность сообщества. Хотя PostgreSQL существует уже более 20 лет, проект все еще довольно активен и кажется, что он созревает (выпуск версии 10 запланирован на конец этого года). Как Amazon объявила на той же конференции, все 3 самых быстрорастущих продукта AWS связаны с PostgreSQL: Redshift, RDS и Aurora.
Члены сообщества PostgreSQL также могут помочь друг другу. Когда некоторые спрашивали о других расширениях / функциях PostgreSQL, другие члены сообщества были достаточно любезны, чтобы вмешаться (например, этот очень подробный ответ от ozgune, технический директор Citus Data, или это предложение от X86BSD на ZFS как вариант сжатия ).
Фактически, довольно много людей уже пытаются хранить данные временных рядов в PostgreSQL:
Выглядит красиво. Мне пришлось несколько раз откатить мою собственную схему PostgreSQL и пользовательские функции для данных таймсерий, и если это устраняет необходимость в этом, я впечатлен. (Через Dangeranger)
Я исследовал ту же тему (база данных таймсерий на основе PG) для проекта данных биржевых тиков, определенно хотел бы попробовать timescaledb. (Через wsxiaoys)
(Если это вы, попробуйте TimescaleDB и позвольте нам сделать за вас тяжелую работу.)
4. Управление схемой может раздражать
Для многих случаев использования удобно просто добавить некоторые данные в базу данных временных рядов, не прыгая через обруч для определения схем и управления ими. Это мнение хорошо отражено в следующем комментарии:
Мне очень нравится Postgresql (и я развертываю его все время), и я не фанат nosql, это просто означает, что вам не нужно заранее должным образом анализировать структуру базы данных, но с временными рядами это другое дело. Данные, которые вы обычно отправляете в общие базы данных временных рядов, обычно очень непредсказуемы. В настоящее время меня не волнует, какие данные будут отправлены в Prometheus или Influx. Это включает в себя, помимо прочего, статистику ZFS нашего хранилища, загрузку системы, сетевой трафик, VMWare, nginx / haproxy, использование приложений и ошибки ... Я знаю, что когда мне это понадобится, у меня это будет в наличии, и я могу попытайтесь сопоставить данные в любой момент в будущем. В TimescaleDB, похоже, мне пришлось бы заранее создавать таблицы, соответствующие всей этой статистике, что сделало бы это абсолютной головной болью. (Через koffiezet)
Мы понимаем эти опасения. Тем не менее, большинство баз данных (включая многие, которые утверждают, что они «не содержат схемы») на самом деле имеют какой-то тип внутренней схемы. Столбцы часто не могут смешивать типы данных, например, целые числа не могут внезапно сохранять строковые значения. Базовые типы данных необходимы по уважительным причинам, например, для возможности выполнять агрегирование целых чисел или определять предикаты для меток. По аналогичным причинам базе данных требуется некоторая структура для приема данных для вычислений, например, средняя загрузка ЦП в кластере серверов.
Комментарий действительно говорит (как мы его видим), так это то, что схема должна быть неявной из структуры полученных данных и что схема должна иметь возможность расширяться для размещения дополнительных столбцов в будущем. Другими словами, иногда вы просто хотите передать данные временного ряда в хранилище, не беспокоясь об управлении схемой.
Несмотря на то, что мы уже поддерживаем полуструктурированные данные через собственные типы данных JSON и JSONB PostgreSQL, мы планируем изучить интерфейсы HTTP, которые дадут возможность автоматически определять структурированную схему и управлять ею.
(Честно говоря, раньше это не входило в число приоритетных в нашей дорожной карте, но теперь, благодаря вашим отзывам, мы уже работаем над этим.)
5. Вам действительно нужно было создать «еще одну базу данных»?
Это мы слышали много раз раньше и снова видели в нашем посте в HN:
В моей последней компании мы выполняли десятки миллиардов сенсорных событий в день в Cassandra, и я благодарю бога, что наша команда инженеров была достаточно умна, чтобы потратить рабочую силу на продукт вместо того, чтобы писать еще одну базу данных (через jjirsa)
Больше возможностей ослабляет таланты и сдерживает инновации - люди тратят время на написание новых инструментов, вместо того, чтобы продвигать передовые достижения.
Но во всяком случае, сжигают не мои деньги, так что я не теряю из-за этого сон. Я просто буду сидеть здесь и хихикать, пока люди говорят о масштабировании Postgres, и все, что я слышу в моей голове, это единственная точка отказа, мастера и вакуум для предотвращения циклического перехода в рабочие процессы с высокой скоростью записи (via jjirsa)
В аннотации мы согласны с автором: в большинстве случаев нет необходимости изобретать велосипед. (И это одна из причин, почему мы решили разрабатывать PostgreSQL, а не создавать совершенно новую СУБД с нуля).
Мы также считаем, что такие группы баз данных, как наша, должны сосредоточиться на улучшении современного состояния баз данных, чтобы такие продуктовые группы, как он, могли сосредоточиться на продукте.
Сомнение и переосмысление существующего положения вещей - вот как происходят инновации, особенно в индустрии баз данных. Cassandra, PostgreSQL (и любая другая успешная база данных) была разработана инженерами, ставящими под сомнение их статус-кво.
6. Вы не можете сделать всех счастливыми
Невозможно сделать всех счастливыми, даже когда дело касается стиля письма. Попробуйте эти два противоположных комментария:
Мне понравилась эта статья, как конкурирующая компания по производству баз данных, они проделали фантастическую работу в отношении разработчиков и были подлинными! Отличная работа, пожалуйста, продолжайте в том же духе, это обязательно сделает вас победителем. (Через маркнадал)
Я действительно ненавижу этот стиль [sic] письма. Почему он должен звучать как любой другой хипстерский текст? (Через sigi45)
На самом деле, у обоих наших основателей очень разные стили письма (и они впервые начали вместе писать статьи почти 20 лет назад).
Тем, кому понравился текст, не волнуйтесь, постов в таком стиле будет больше.
А для тех, кто хотел чего-то менее хипстерского: не волнуйтесь, у нас тоже будут такие статьи. Включая технический пост, над которым наш наполовину технический директор / наполовину профессор Майк Фридман уже работает (скоро!).
Понравился этот пост? Пожалуйста, порекомендуйте и / или поделитесь.
Хотите узнать больше? Присоединяйтесь к нашему сообществу Slack, подписывайтесь на нас здесь на Medium, посетите наш GitHub и подпишитесь на рассылку сообщества ниже.
