All streams
Search
Write a publication
Pull to refresh

Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...

DocumentDB – БД от Microsoft, которая состоит из 3-х частей:

  1. PG расширение, добавляющее BSON формат (написанный, на С)

  2. CRUD API поверх него (С)

  3. Сервис трансляции Mongo Query в SQL (Rust)

Для кого это?

И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"

Классический PG

Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.

Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:

  • Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)

  • Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри

  • MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)

  • А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости

То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.

Distributed PG-like

А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?

Все 3 проблемы решаются:

  • Шардинг из коробки

  • Достаточно высокая скорость записи и чтения

  • Отсутствие проблем с коннектами

В такой ситуации DocumentDB начинает играть новыми красками.

Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).

Переезд в Linux Foundation

А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.

Итоги

Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?

P.S.

А еще приглашаю вас к обсуждению в свой паблик в телеграмме 🦾 IT-Качалка Давида Шекунца 💪

Tags:
+4
Comments2

Articles