Комментарии 6
Почему просто взять и не попробовать использовать YDB? Там есть очередь, есть таблицы, есть транзакции, есть транзакции очередь-таблица, есть гарантии и есть механизмы дедупликации. И все это одна БД, а не зоопарк. И это явно работает быстрее и надежнее чем Kafka + VM
Это хороший вопрос! Постараюсь ответить по пунктам:
1. У больших продуктов всегда надо рассматривать исторический контекст, т.е. когда и что начиналось, какие инструменты были доступны и т.д.
2. С другой стороны даже при наличии интересных решений в текущий момент встает вопрос миграции. Миграции это очень дорого, не всегда есть смысл вообще это делать.
3. Мой опыт показывает, что нельзя сказать что одно быстрее другого, пока под своим профилем нагрузки на своей конфигурации железа не произведешь замеры. Для примера, сейчас мы делаем свою собственную бд оптимизированную под логи, интересно в таком ключе тоже сравнивать.
4. Если зоопарк переехал в одну бд это не значит, что стало все лучше работать или проще обслуживать. Вообще моя практика показывает, что небольшими кусочками управлять проще, и сами по себе они работают стабильнее. Более того, за годы эксплуатации нарабатывается опыт команды, набиваются шишки - с новым решением путь начинается с начала.
5. Ну и последнее, переход на YDB это по сути вендор-лок. Текущая реализация очень гибкая, ее можно развивать в любом направлении, итеративно.
Я с интересом слежу за развитием YDB, решение действительно очень крутое.
Я правильно понимаю, что вы предлагаете хранить в YDB вообще все виды данных: логи, трейсы и метрки?
Вот эта фраза " И это явно работает быстрее и надежнее чем Kafka + VM" - на основе чего вы сделали данный ввод? Видимо располагаете бенчмарком? Можете показать?
@polRk можете дать ответ на вопросы выше?
Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны