Разработка
Евгений Делюкин
2891

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

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

В закладки

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

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

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

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

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

{ "author_name": "Евгений Делюкин", "author_type": "editor", "tags": ["\u044f\u043d\u0434\u0435\u043a\u0441","\u043d\u043e\u0432\u043e\u0441\u0442\u044c","\u043d\u043e\u0432\u043e\u0441\u0442\u0438"], "comments": 26, "likes": 12, "favorites": 12, "is_advertisement": false, "subsite_label": "dev", "id": 92579, "is_wide": true, "is_ugc": false, "date": "Thu, 14 Nov 2019 12:31:30 +0300", "is_special": false }
Объявление на vc.ru Отключить рекламу
Маркетинг
Три онлайн-игры, № 1 по вовлечению в нише и увеличение продаж в кризис: кейс «Улыбка радуги»
Как мы сделали проект № 1 по вовлеченности в нише, провели три масштабные игры ВКонтакте, привели аудиторию в…
0
26 комментариев Накачай стартап
Популярные
По порядку
Написать комментарий...
2

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

Ответить
0

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

Ответить
3

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

Ответить
1

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

Ответить
0

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

Ответить
2

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

Ответить
0

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

Ответить
–1

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

Ответить
0

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

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

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

Ответить
0

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

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

Ответить
0

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

Спасибо.

Ответить
1

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

Например есть треки gps с каждого такси, которые логирутся каждые 10 секунд. Задача - уметь по запросу смотреть треки водилы в окрестности какого-то времени.  В монге - ты можешь просто делать append к gps трекам водилы. В postgres придется каждый раз создавать новый row с id водителя. Т.е. для данной задачи все премущества pg , как реляционной бд, по сути не используются. И выгрузить треки водилы будет удобнее в монге, чем делать каждый раз where в pg.

Ответить
–1

Okay, boomer.

Ответить
0

?

Ответить
2

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

Ответить

Тайный микроскоп

Ivan
0

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

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

Ответить
0

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

Ответить

Тайный микроскоп

Ivan
4

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

Ответить
0

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

Ответить
2

Круто, что яндекс добавялет все больше баз - потому что по ценам выходит дешевле чем AWS / DO. Единственная проблема - что (видимо из-за РКН) часть европейских серваков не может достучаться до этих баз - и нужно прокидывать прокси.

Ответить
0

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

Ответить
1

честно говоря не замерял - но там в пределах сотни ms. Для нас не критично - потому что это инфа которую мы парсим из интернета - и даже если будет задержка в несколько минут - ничего страшного.

А все юзеры стучатся на европейский сервак (который не забанен РКН) и у него прямой доступ к яндексу без прокси. Конечно если бы база тоже в европе была - то было бы побыстрее на 50ms. Но переплачивать за это в ~2 раза пока не готовы.

Ответить

Комментарии

null