Mongo World в 2020 году будет проходить 9 и 10 июня в онлайн формате под названием «Mongo.LIVE», а участие абсолютно бесплатное. Регистрация: https://www.mongodb.com/world

Апрельские обновления:

* Stable: 4.2.6 (Apr 21)
* Bugfix: 4.0.18 (Apr 15)
* Beta: 4.4.0-rc5 (May 9)

Вероятно релиз версии 4.4.0 анонсируют на Mongo.LIVE, так что ждать осталось совсем недолго

в результате $filter будут документы с пустыми массивами, второй шаг в виде $match нужен для того чтоб очистить пайплайн от этих документов

да, оно преобразует все документы и выборка будет не эффективной

Суть: в коллекции 8.8 млн записей, 5 ГБ. В каждой записи по 15 полей, нужно производить поиск по 6 из них (по одному, по нескольким или по всем). Сервер - DigitalOcean $5 Droplet.

Создавал индексы по 6 полям отдельно, соответственно по одному любому полю поиск 80-140мс. Мульти-индекс работает, но только с опцией sparse и только с определенным кол-вом полей (от 3 до 6). Создать десятки индексов на все случаи жизни считаю костылём, надеюсь - это не не офф решение монго.

Вопрос: как сделать правильный индекс, чтобы можно было фильтровать 9 млн записей за 80-140 мс при любой выборке, будь то 1 поле или сразу 6?

Привет, хочу про архитектуру спросить. Делаю мобильное приложение знакомства, сделал с firebase базу там абонентов, но с очень урезаными возможностями делать выборки, приходиться много лишних действий делать, даже onSnapshot не помогает когда данных много. Есть колекция юзеров и есть коллекция кто кого лайкнул, чтобы повторно не предлогать лайкать. Перехожу на GraphQL, там чище выборки и подписки есть. Теперь думаю про бд, остановился на монго. Но чет не знаю как лучше архитектуру. Мож есть идеи как правильно хранить?

не вижу проблемы, чтото не устраивает в производительности на 6 отдельных индексах?

Да, если брать два поля, выборка использует один индекс, а по второму полю производит сканирование, а это занимает может занимать минуты

Возможно подойдёт wildcard index, но в остальном, задача индекса — уменьшить объём данных для поиска. Если вы ищите по всему документу, то возможно либо у вас не эффективная схема, либо вам нужен другой инструмент

если это случай dynamic attribute, то вероятно схема

attributes: [{ key: <string>, value:  <string> }, … {}]и составной индекс по attrs.key. attrs.value будет эффективнее

Коллекция users и коллекцию likes, где храниться ид кто лайкнул и ид кого лайкнули. Мне нужно выбирать для конкретного юзера кого он еще не лайкал. В монго я новичек, может с учетом специфики я изначально архитектуру не правильно делаю. А так как юзеров может быть много и лайков еще больше, то делать бы это в одном запросе

В общем случае эта задача плохо решается, так как вы хотите огромное множество всех пользователей пересечь с небольшим множеством лайкнутых. Какой-то универсальной архитектуры тут нет.

Если это не существующий сервис с миллионами пользователей, то наиболее эффективным будет собрать лайки пользователей в бакеты (https://www.mongodb.com/blog/post/building-with-patterns-the-bucket-pattern)

и дальше просто пересекать с коллекцией пользователей через $nin оператор.

Когда это перестанет работать, то можно исходя из паттернов использования сервиса попытаться найти более оптимальный способ

Почему монга, а не графовая бд ?

Спасибо почитаю про это

Графовая БД не поможет, так как количество связей для анализа всё равно будет в худшем случае равно количеству пользователей

Да тут проект больше расчитан на изучение всех используемых технологий. А с монгой сталкивался ну и подумал что неплохо подучить и научиться работать. Плюс изначально проект на firebase был, а это похожее хранение

Если лучше чтот другое использовать, подскажите что лучше будет

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

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

Зачем тогда советовать? Без указания других задач смысла никакго сравнивать нет. Графовые БД эффективнее работают со сложными цепочками отношений.

По этому лучше использовать bucket паттерн