«Яндекс.Облако» запустила систему управления базами данных MongoDB с автоматическим обслуживанием и обновлением Статьи редакции

«Яндекс» стал первым официальным партнером разработчика MongoDB в России.

14 ноября платформа «Яндекс.Облако» представила сервис Managed Service for MongoDB, рассказали vc.ru в компании. Сервис разворачивает готовую к эксплуатации базу данных на основе СУБД MongoDB, управляет ею и обновляет.

Среди применений сервиса — решение задач обработки и хранения данных в сфере машинного обучения, кэширования, работа с очередями в приложениях и бэкенде.

По словам представителей «Яндекс.Облака», Managed Service for MongoDB стал первым в России управляемым сервисом с автоматизированным обслуживанием и обновлением, который работает на актуальной версии MongoDB 4.2.

Предыдущими версиями MongoDB как управляемых сервисов можно было пользоваться в «Облаке», на других платформах или через прямое обращение к разработчику MongoDB.

Также «Яндекс.Облако» утверждает, что в качестве партнера MongoDB будет предоставлять клиентам техподдержку по работе нового сервиса.

0
26 комментариев
Написать комментарий...
Иван Колыхалов

Обьясните пожалуйста в чем прикол NoSQL. В частности Монго? Ведь однажды вступив на путь собственного интерфейса работы с базой ты лавинообразно множишь потенциальный обьем говнокода и головняка выборок из базы получая взамен что?

Ответить
Развернуть ветку
kav

Согласен со всем выше и не люблю NoSQL,  но у монги есть свои плюсы например:
- Нужно хранить данные которые не однородны (либо заводить много колонок в реляхе, либо просто хранить json)
- Быстрое добавление новых колонок, не нужно делать никаких миграций таблиц, становиться особенно больно когда таблицы очень большие, делать в реляхе на проде это сущий ад, из-за того что  бд для этого нужно взять эксклюзивный лок на таблицу, тоже самое и с удалением колонок
- Вы получаете от кого-то json который нужно сразу хранить и быстро по нему искать
- WiredTiger очень хорошо жмет json
- Шардирование из коробки

Ответить
Развернуть ветку
Иван Колыхалов

Почти все что вы перечислили делает постгрес, включая хранение и работу с json и шардирование из коробки. Хаотичное хранение хаотичного json действительно так ли нужно? В постгрес так же можно добавлять/удалять колонки прям на проде, не надо ничего мигрировать, насколько мне известно, если только у вас не эксклюзивный кейс какой-то. 

Ответить
Развернуть ветку
Artem B.

вы пробовали шардировать пг? а монгу? попробуйте просто и сравните. вопросы сами собой отпадут)

Ответить
Развернуть ветку
Иван Колыхалов

Нет, не пробовал, честно скажу. В обратку вопрос: а вы?

Ответить
Развернуть ветку
Artem B.

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

Ответить
Развернуть ветку
Иван Колыхалов

Понял. Спасибо.

Ответить
Развернуть ветку
kav

Какое коробочное шардирование ПГ из коробки?
Да есть JSONB, для хранения неструктурных данных, другой вопрос зачем вам вообще реляционная БД есть у вас только не структурированные данные?
Я не спец в кишках постгреса, но кажется для того чтобы добавить новую колонку в бд нужно полностью заблокировать любое чтение/запись в данную таблицу, поправьте если ошибаюсь. Пробовал добавлять колонку на прод базу в которой 500млн записей, очень больно.

Ответить
Развернуть ветку
Иван Колыхалов

У меня 500 рпс - нормальная нагрузка (реклама). Добавляется и удаляется колонка мгновенно, причем из стороннего IDE.

Json часто бывает удобно хранить то, что идет массивом и не требует постоянного доступа, например список товаров из прайс листа, список товаров в заказе. Ну кейсов много использования.

По шардингу.
https://postgrespro.ru/docs/postgresql/9.6/postgres-fdw

Ответить
Развернуть ветку
kav

Если у вас 500rps и миграция делается за секунды, значит таблица не большая, у меня был кейс с 2 TB базой ПГ и там даже если вообще все остановить добавление колонки шло больше получаса)

FDW это не шардинг - это наколеночное решение которое позволяет притянуть табличку из другой БД в свою. Можно начать с того что при таком подходе невозможно решардирование, а закончить тем что нужно почти ручками создавать каждый FDW, насколько я знаю нет никакого автоматического решения (типа зашить в конфиг).
Ближе к шардингу ПГ это Citus, но это стороннее решение, к тому же все клевые фишки типа решардинга только в платной версии, так что коробочным его не назовешь

Ответить
Развернуть ветку
Иван Колыхалов

Странные вещи вы говорите про таблицы. У меня 0.9ТБ таблица есть, я как раз недавно переделывал ее, ни разу не возникло такой проблемы.

Насчет шардинга я понял. Тут я не буду спорить, поскольку не работал с этим.

Ответить
Развернуть ветку
kav

Все зависит от величины таблицы, наличия индексов, необходимости дефолтных значений в колонках и тд, моя мысль в том что в ПГ это не бесплатно

Ответить
Развернуть ветку
Иван Колыхалов

В том, что это не бесплатно и она довольно своеобразная тут нет никаких сомнений. Чего только стоит раздувание pg_attribute на временных таблицах на размерз 2-3 размеров таблиц.

Ответить
Развернуть ветку
Алексис Второй

У меня ваш сайт с AdBlock вот так выглядит:

Ответить
Развернуть ветку
Иван Колыхалов

Спасибо.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Bugara's Life

Okay, boomer.

Ответить
Развернуть ветку
Eugene Shved

?

Ответить
Развернуть ветку
Иван Колыхалов

Не обращайте внимания, попугай залетел.

Ответить
Развернуть ветку
Kelerius

Быстрый старт. Я для своих пет проектов выбираю монгу. Удобно.

Или для хранения данных какого-то сервиса отдельного.

Ответить
Развернуть ветку
Иван Колыхалов

В чем быстрота? Точнее преимущество в скорости развертки и старта перед другими базами? Тот же инсталл, те же либы в коде, те же настройки. 

Ответить
Развернуть ветку
Kelerius

Не надо думать над схемой базы данных.
Что придумал,то и залил. Мои пет проекты не дорастают до проблем масштабирования

Ответить
Развернуть ветку
Artem B.

если в частности, то как минимум наличие шардирования из коробки, она отлично подходит для хранения данных которые постоянно накапливаются и по которым не нужно строить джойны (операции, логи, действия, т.е. те самые пресловутые "документы" в монговской терминологии). ну и объем говнокода скорее связан с неправильным выбором технологии для решения задачи, а не конкретно с самой технологией. выстрелить себе в ноги можно из любой субд и языка.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Алексис Второй

А задержки такое взаимодействие не создаёт, стучаться из Америки/Европы в Россию к БД?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
23 комментария
Раскрывать всегда