MongoDB *

Лутаем 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-Качалка Давида Шекунца 💪

Под пост в телеграм про наш ответ аналог Grafana пришли руководители "Лаборатории Числитель" и конкретно "Пульта", в чью систему входит платформа мониторинга и анализа "Графиня".

Дмитрий Унтила и Владимир Утратенко любезно ответили на ряд вопросов по платформе, и я хотел бы подвести краткое резюме:

• Запрос на аналог Grafana появился в момент продажи "Пульта", так как "не всем можно брать забугорный опесорс себе в контур. Потому решили делать. А название Графиня просто ради лулзов."

• Графиня писалась с полного нуля. Хотя предложение взять за основу Grafana было, но команда смогла обосновать геморрой, который на неё упадёт, если взяться за доработку, и объяснила руководству, почему лучше сделать с нуля.

• Время разработки: 3 месяца - MVP, 6 месяцев - 1 релиз.

• Технологический стек: фронтенд: TypeScript + React 18, бэкенд: TypeScript + Node.js, база данных: MongoDB, плагины: Java.

• На мое предложение сделать проект опенсорс Дмитрий Унтила пообещал подумать. Но, понятное дело, если это часть коммерческого продукта, прям сильно думать в лаборатории не будут))

• Демо-стенда в интернете пока нет, можно только записаться на показ системы через форму обратной связи.

Благодарю парней за такой актив и обратную связь, рад, что у людей есть на это время!

Добавили в панель мониторинг дополнительных метрик для пяти СУБД.

Для MongoDB отображаем количество операций с данными, открытые или доступные соединения. В OpenSearch теперь можно отслеживать задержку и скорость индексации/поиска, в ClickHouse — операции вставки и поиска.

И, наконец, в RabbitMQ выводим на графики количество созданных каналов и активных соединений, а также общее состояние сообщений. А для Kafka пропускную способность и скорость запросов.

Все данные собираем через VictoriaMetrics.

Помониторить свои базы → 

В инфраструктуре компании MongoDB, развивающей одноимённую документо-ориентированную СУБД и облачный сервис MongoDB Atlas, выявлены следы взлома.

Судя по уведомлениям администрации проекта, направленным многим клиентам компании, злоумышленники на некоторое время смогли получить доступ к части корпоративных IT-систем, на которых, среди прочего, были размещены сведения об учётных записях клиентов и контактные данные пользователей. Свидетельств, указывающих на то, что атакующие получили доступ к данным, хранимым пользователями в облачном сервисе MongoDB Atlas, на текущем этапе разбирательства инцидента не было выявлено.

Вредоносная активность была обнаружена вечером 13 декабря, после чего неавторизованный доступ извне был пресечён, а также был начат процесс разбора инцидента ИБ. В течение какого времени атакующие имели доступ к инфраструктуре, не сообщается. Также администрацией проекта не упоминается, насколько атака затронула IT-системы, связанные с разработкой СУБД MongoDB.

Пользователям облачных сервисов MongoDB рекомендуется включить двухфакторную аутентификацию для защиты данных и своих аккаунтов.

Не исключено, что полученные в ходе атаки данные могут использоваться для фишинга и целевых атак с использованием методов социального инжиниринга.

Источники: Bleeping Computer, OpenNET, X (Twitter).