😳 А еще есть serverless и edge базы данных...
Дважды переписывал пост, потому что его сложно сформулировать, поэтому оставлю "пробежку по верхам":
i. Где разворачиваем: - Self-hosted – арендовали сервер, сами развернули и поддерживаем БД, платим за железо.
- Vendor-hosted – арендовали базу у какого-нибудь сервиса и он сам занимается поддержкой инстансов и железа.
ii. За что платим в Vendor-hosted - "Classic" БД – платим за инстанс / железо
- Serverless БД – платим за вычисления + объем хранимых данных
iii. Vendor-hosted Serverless Обычно, предполагает специальные БД, разделеные на 3 части: слой хранения данных, слой вычислений и координатор.
Когда вы делаете запрос, координатор создает функцию для его вычисления, которая из разных частей слоя хранения данных отдает вам результат.
YDB, Cockroach, PlanetScale, Neon (serveless PostgreSQL) Преимуществом vendor-hosted serverless БД называют "бесконечное масштабирование" (место на дисках в этом случае, может быть, на порядок дешевле, потому что наши данные лежат в перемешку с чужими) + уменьшение костов, поскольку мы платим только за вычисления и небольшую денежку за хранимые данные.
И если масштабирование правда классная фича, то вот прайсинг за вычисления – более опасная история, потому что "вычисления" это в том числе сколько БД прочитала строчек, а значит, если у вас поиск не по индексу, вы заплатите за каждую прочитанную строчку, что из 10 центов может превратиться в 5000$ (эх, не могу найти ссылку на статью, но вы нагуглите кучу таких историй).
iv. Edge Тут больше про брендинг: Edge DB должны давать возможность Edge functions, запускающихся рядом с клиентами, ходить в самый ближайший к ним инстанс БД, а значит основная их фишка – геораспределенность.
По факту, подойдет любая БД, которая умеет в распредление, но в идеале она должна поддерживать мастер-мастер репликацию, длительные зажержки в репликации и резолвинг конфликтов.
ScyllaDB, CouchDB, Cassandra Единственная БД, которую сейчас можно найти под тэгом "edge database" это Turso – распредленный SQLite. НО самое смешное, что она при этом master-slave (то есть все запросы на write маршрутизируются на master реплику) причем чуть ли не с serializable транзакциями, а это как-то нехрена не "Edge"...
По ощущениям, это тоже самое, что сделать реплику PostgreSQL для чтения в регионе пользователей, при этом оставив все фишки и плюшки постгресса. Надо еще почитать / попробовать.
v. Когда что использовать: - Self-hosted всегда дешевле, поэтому если у нас средний+ проект, есть DevOps, умеющий в БД и желание сократить издержки, то можно переходить на Self-hosted.
- Vendor-hosted снимает огрооомное количество гемороя, поэтому, если у нас маленький-средний проект или мы готовы платить вендору, то используем Vendor-hosted
А вот использовать ли вам Classic / Serverless / "Edge" зависит чисто от ваших задач и команды и я буду разбирать каждого отдельного представителя с рассуждениями о задачах, для которых это могло бы подойти.
Серебрянной пули опять нет, если брать среднее по больнице, мой совет: "научитесь в classic vendor-hosted" – и будет вам счастье.
Всем мощной прокачки 💪
i. Где разворачиваем: - Self-hosted – арендовали сервер, сами развернули и поддерживаем БД, платим за железо.
- Vendor-hosted – арендовали базу у какого-нибудь сервиса и он сам занимается поддержкой инстансов и железа.
ii. За что платим в Vendor-hosted - "Classic" БД – платим за инстанс / железо
- Serverless БД – платим за вычисления + объем хранимых данных
iii. Vendor-hosted Serverless Обычно, предполагает специальные БД, разделеные на 3 части: слой хранения данных, слой вычислений и координатор.
Когда вы делаете запрос, координатор создает функцию для его вычисления, которая из разных частей слоя хранения данных отдает вам результат.
YDB, Cockroach, PlanetScale, Neon (serveless PostgreSQL) Преимуществом vendor-hosted serverless БД называют "бесконечное масштабирование" (место на дисках в этом случае, может быть, на порядок дешевле, потому что наши данные лежат в перемешку с чужими) + уменьшение костов, поскольку мы платим только за вычисления и небольшую денежку за хранимые данные.
И если масштабирование правда классная фича, то вот прайсинг за вычисления – более опасная история, потому что "вычисления" это в том числе сколько БД прочитала строчек, а значит, если у вас поиск не по индексу, вы заплатите за каждую прочитанную строчку, что из 10 центов может превратиться в 5000$ (эх, не могу найти ссылку на статью, но вы нагуглите кучу таких историй).
iv. Edge Тут больше про брендинг: Edge DB должны давать возможность Edge functions, запускающихся рядом с клиентами, ходить в самый ближайший к ним инстанс БД, а значит основная их фишка – геораспределенность.
По факту, подойдет любая БД, которая умеет в распредление, но в идеале она должна поддерживать мастер-мастер репликацию, длительные зажержки в репликации и резолвинг конфликтов.
ScyllaDB, CouchDB, Cassandra Единственная БД, которую сейчас можно найти под тэгом "edge database" это Turso – распредленный SQLite. НО самое смешное, что она при этом master-slave (то есть все запросы на write маршрутизируются на master реплику) причем чуть ли не с serializable транзакциями, а это как-то нехрена не "Edge"...
По ощущениям, это тоже самое, что сделать реплику PostgreSQL для чтения в регионе пользователей, при этом оставив все фишки и плюшки постгресса. Надо еще почитать / попробовать.
v. Когда что использовать: - Self-hosted всегда дешевле, поэтому если у нас средний+ проект, есть DevOps, умеющий в БД и желание сократить издержки, то можно переходить на Self-hosted.
- Vendor-hosted снимает огрооомное количество гемороя, поэтому, если у нас маленький-средний проект или мы готовы платить вендору, то используем Vendor-hosted
А вот использовать ли вам Classic / Serverless / "Edge" зависит чисто от ваших задач и команды и я буду разбирать каждого отдельного представителя с рассуждениями о задачах, для которых это могло бы подойти.
Серебрянной пули опять нет, если брать среднее по больнице, мой совет: "научитесь в classic vendor-hosted" – и будет вам счастье.
Всем мощной прокачки 💪
Комментарии: 8
I
🦾
Блин, я кстати очень верю в ydb и, надеюсь, что она повторит успех ClickHouse (для меня это одно из топовых решений наравне с PostgreSQL)
Мне дико нравится их схема шардирования, load-balancing-а, а также то, что они интегрировали очереди и сразу добавили туда CDC (каждый раз, когда мне нужно получать изменения от PostgreSQL, приходится вертеть танцы с бубном, а тут все из коробки), ну и наличие встроенного UI – топ
+ это первый раз, когда настолько просто и понятно объяснили принцип работы с дисками, проще объяснение я находил только у Kafka
Но да, отсутствие полноценной документации пока не дает возможности предложить ее к использованию
Мне дико нравится их схема шардирования, load-balancing-а, а также то, что они интегрировали очереди и сразу добавили туда CDC (каждый раз, когда мне нужно получать изменения от PostgreSQL, приходится вертеть танцы с бубном, а тут все из коробки), ну и наличие встроенного UI – топ
+ это первый раз, когда настолько просто и понятно объяснили принцип работы с дисками, проще объяснение я находил только у Kafka
Но да, отсутствие полноценной документации пока не дает возможности предложить ее к использованию
I
Мне дико нравится их схема шардирования, load-balancing-а, а также то, что они интегрировали очереди и сразу добавили туда CDC (каждый раз, когда мне нужно получать изменения от PostgreSQL, приходится вертеть танцы с бубном, а тут все из коробки), ну и наличие встроенного UI – топ
Так CockroachDB из коробки предоставляет тоже самое и диалект поверх pg за исключением некоторых особенностей)
Так CockroachDB из коробки предоставляет тоже самое и диалект поверх pg за исключением некоторых особенностей)
🦾
Конечно, возможно, это просто "пугалка", но у меня сразу отпало желание изучать возможности CDC кокроуча, когда прочитал вот это
Если они позволяют себе давать "демку" функционала, а полноценный закрывать под лицензию это путь в Оракл-like (что для меня фи)
Если они позволяют себе давать "демку" функционала, а полноценный закрывать под лицензию это путь в Оракл-like (что для меня фи)
🦾
I
Да, это минус, в бесплатной версии CDC ограничен, в serverless, dedicated и self-hosted лицензии всё полноценно работает.
Лицензия у всех таких продуктов сейчас модная BSL, чтобы всё было через их облака, либо очень конские расценки, например, у того же, cockroach цена за 1 vcpu считается, и базовый кластер там выходит больше $20к. С другой стороны, это и предназначено для enterprise, которые платят по $20к за pulsar.
Лицензия у всех таких продуктов сейчас модная BSL, чтобы всё было через их облака, либо очень конские расценки, например, у того же, cockroach цена за 1 vcpu считается, и базовый кластер там выходит больше $20к. С другой стороны, это и предназначено для enterprise, которые платят по $20к за pulsar.
🦾
Ну вот предоставим кейс: нам нужно построить систему с огромным кол-вом инсерта + хранением исторических данных за год, а далее их денормализовывать, чтобы показывать пользователям (например, система телеметрии или парсер из кучи источников) при этом сервис наш не то чтобы очень много зарабатывает и может зарабатывать (короче, резать косты важно)
Что я сделал бы среднестатистически: развернул бы на нескольких тачках Kafka (а поскольку это часто больно, я бы попробовал RedPanda), писал бы туда события, читал в других процессах и переписывал в PostgreSQL (условно, это наша основная база бизнес-логики, если нужно было бы что-то типа OLAP, тогда ClickHouse)
Если же YDB окажется достойной технологией, то можно и события в нее писать и читать их из ее же топиков и денормализованные данные обратно складывать (причем с умеренной денормализацией, потому что YDB поддерживает как вторичные индексы, так и JOIN), соответственно, она может стать даже основной базой для бизнес-логики
Никакого вендор лока (даже если начать с Yandex.Cloud, дальше можно уйти на self-hosted и ничего не потерять), поддержка всего одной системы, уменьшение стоимости, масштабируемость и скорость
Короче, я наверное сам для себя этим текстом хотел понять, почему YDB мне концептуально больше нравится, чем Кокроач, хоть он и тоже хорош)
Что я сделал бы среднестатистически: развернул бы на нескольких тачках Kafka (а поскольку это часто больно, я бы попробовал RedPanda), писал бы туда события, читал в других процессах и переписывал в PostgreSQL (условно, это наша основная база бизнес-логики, если нужно было бы что-то типа OLAP, тогда ClickHouse)
Если же YDB окажется достойной технологией, то можно и события в нее писать и читать их из ее же топиков и денормализованные данные обратно складывать (причем с умеренной денормализацией, потому что YDB поддерживает как вторичные индексы, так и JOIN), соответственно, она может стать даже основной базой для бизнес-логики
Никакого вендор лока (даже если начать с Yandex.Cloud, дальше можно уйти на self-hosted и ничего не потерять), поддержка всего одной системы, уменьшение стоимости, масштабируемость и скорость
Короче, я наверное сам для себя этим текстом хотел понять, почему YDB мне концептуально больше нравится, чем Кокроач, хоть он и тоже хорош)
🦾
Я сейчас кстати понял, что у нас как раз сейчас похожая система)
Но YDB я бы пока не стал использовать:
1. У нас сейчас не такой большой объём данных, поэтому PostgreSQL и RMQ справятся ещё год-два без излишнего тюнинга (мы не занимаемся долго исторические данные и данные мы можем показывать хоть с задержкой на час)
2. Кор команде проекта меньше полугода
3. Найти новых достойных разрабов на ноде, которые знаю PostgreSQL - дико тяжело, найти на YDB будет невозможно, придется учить с нуля
4. Нет времени на эксперименты, надо запускаться
Наверное, я буду готов взять в полноценный продакшен только (1) если очень прижмёт по масштабируемости и без экспериментов будет некуда, (2) когда в вакансиях начнут писать "Знание YDB", а это годик другой, в зависимости от агрессивности маркетинга Яндекса, (3) устоится кор команда и будет готова контрибьютить в драйвер для ноды
Но YDB я бы пока не стал использовать:
1. У нас сейчас не такой большой объём данных, поэтому PostgreSQL и RMQ справятся ещё год-два без излишнего тюнинга (мы не занимаемся долго исторические данные и данные мы можем показывать хоть с задержкой на час)
2. Кор команде проекта меньше полугода
3. Найти новых достойных разрабов на ноде, которые знаю PostgreSQL - дико тяжело, найти на YDB будет невозможно, придется учить с нуля
4. Нет времени на эксперименты, надо запускаться
Наверное, я буду готов взять в полноценный продакшен только (1) если очень прижмёт по масштабируемости и без экспериментов будет некуда, (2) когда в вакансиях начнут писать "Знание YDB", а это годик другой, в зависимости от агрессивности маркетинга Яндекса, (3) устоится кор команда и будет готова контрибьютить в драйвер для ноды