«Яндекс.Облако» запустила систему управления базами данных MongoDB с автоматическим обслуживанием и обновлением Статьи редакции
«Яндекс» стал первым официальным партнером разработчика MongoDB в России.
14 ноября платформа «Яндекс.Облако» представила сервис Managed Service for MongoDB, рассказали vc.ru в компании. Сервис разворачивает готовую к эксплуатации базу данных на основе СУБД MongoDB, управляет ею и обновляет.
Среди применений сервиса — решение задач обработки и хранения данных в сфере машинного обучения, кэширования, работа с очередями в приложениях и бэкенде.
По словам представителей «Яндекс.Облака», Managed Service for MongoDB стал первым в России управляемым сервисом с автоматизированным обслуживанием и обновлением, который работает на актуальной версии MongoDB 4.2.
Предыдущими версиями MongoDB как управляемых сервисов можно было пользоваться в «Облаке», на других платформах или через прямое обращение к разработчику MongoDB.
Также «Яндекс.Облако» утверждает, что в качестве партнера MongoDB будет предоставлять клиентам техподдержку по работе нового сервиса.
Обьясните пожалуйста в чем прикол NoSQL. В частности Монго? Ведь однажды вступив на путь собственного интерфейса работы с базой ты лавинообразно множишь потенциальный обьем говнокода и головняка выборок из базы получая взамен что?
Согласен со всем выше и не люблю NoSQL, но у монги есть свои плюсы например:
- Нужно хранить данные которые не однородны (либо заводить много колонок в реляхе, либо просто хранить json)
- Быстрое добавление новых колонок, не нужно делать никаких миграций таблиц, становиться особенно больно когда таблицы очень большие, делать в реляхе на проде это сущий ад, из-за того что бд для этого нужно взять эксклюзивный лок на таблицу, тоже самое и с удалением колонок
- Вы получаете от кого-то json который нужно сразу хранить и быстро по нему искать
- WiredTiger очень хорошо жмет json
- Шардирование из коробки
Почти все что вы перечислили делает постгрес, включая хранение и работу с json и шардирование из коробки. Хаотичное хранение хаотичного json действительно так ли нужно? В постгрес так же можно добавлять/удалять колонки прям на проде, не надо ничего мигрировать, насколько мне известно, если только у вас не эксклюзивный кейс какой-то.
вы пробовали шардировать пг? а монгу? попробуйте просто и сравните. вопросы сами собой отпадут)
Нет, не пробовал, честно скажу. В обратку вопрос: а вы?
мы в проектах используем и то и другое. монга развернута в кластере, подключение пустых шардов и дальнейший автоматически перелив данных в пустой шард - это очень удобно. подключил шард, монга сама часть данных перелила на него. с пг мне очень сложно представить, как без головной боли размазать таблицу горизонтально на несколько тачек. максимум что делаем в пг - это разбиваем одну большую таблицу на много мелких (исторические данные, разбитые по месяцам. один месяц = одна таблица). всё. я абсолютно не отрицаю, что в пг такого сделать нельзя. конечно можно. но с монгой это делается в разы проще)
Понял. Спасибо.
Какое коробочное шардирование ПГ из коробки?
Да есть JSONB, для хранения неструктурных данных, другой вопрос зачем вам вообще реляционная БД есть у вас только не структурированные данные?
Я не спец в кишках постгреса, но кажется для того чтобы добавить новую колонку в бд нужно полностью заблокировать любое чтение/запись в данную таблицу, поправьте если ошибаюсь. Пробовал добавлять колонку на прод базу в которой 500млн записей, очень больно.
У меня 500 рпс - нормальная нагрузка (реклама). Добавляется и удаляется колонка мгновенно, причем из стороннего IDE.
Json часто бывает удобно хранить то, что идет массивом и не требует постоянного доступа, например список товаров из прайс листа, список товаров в заказе. Ну кейсов много использования.
По шардингу.
https://postgrespro.ru/docs/postgresql/9.6/postgres-fdw
Если у вас 500rps и миграция делается за секунды, значит таблица не большая, у меня был кейс с 2 TB базой ПГ и там даже если вообще все остановить добавление колонки шло больше получаса)
FDW это не шардинг - это наколеночное решение которое позволяет притянуть табличку из другой БД в свою. Можно начать с того что при таком подходе невозможно решардирование, а закончить тем что нужно почти ручками создавать каждый FDW, насколько я знаю нет никакого автоматического решения (типа зашить в конфиг).
Ближе к шардингу ПГ это Citus, но это стороннее решение, к тому же все клевые фишки типа решардинга только в платной версии, так что коробочным его не назовешь
Странные вещи вы говорите про таблицы. У меня 0.9ТБ таблица есть, я как раз недавно переделывал ее, ни разу не возникло такой проблемы.
Насчет шардинга я понял. Тут я не буду спорить, поскольку не работал с этим.
Все зависит от величины таблицы, наличия индексов, необходимости дефолтных значений в колонках и тд, моя мысль в том что в ПГ это не бесплатно
В том, что это не бесплатно и она довольно своеобразная тут нет никаких сомнений. Чего только стоит раздувание pg_attribute на временных таблицах на размерз 2-3 размеров таблиц.
У меня ваш сайт с AdBlock вот так выглядит:
Спасибо.
Комментарий недоступен
Okay, boomer.
?
Не обращайте внимания, попугай залетел.
Быстрый старт. Я для своих пет проектов выбираю монгу. Удобно.
Или для хранения данных какого-то сервиса отдельного.
В чем быстрота? Точнее преимущество в скорости развертки и старта перед другими базами? Тот же инсталл, те же либы в коде, те же настройки.
Не надо думать над схемой базы данных.
Что придумал,то и залил. Мои пет проекты не дорастают до проблем масштабирования
если в частности, то как минимум наличие шардирования из коробки, она отлично подходит для хранения данных которые постоянно накапливаются и по которым не нужно строить джойны (операции, логи, действия, т.е. те самые пресловутые "документы" в монговской терминологии). ну и объем говнокода скорее связан с неправильным выбором технологии для решения задачи, а не конкретно с самой технологией. выстрелить себе в ноги можно из любой субд и языка.
Комментарий недоступен
А задержки такое взаимодействие не создаёт, стучаться из Америки/Европы в Россию к БД?
Комментарий недоступен