Составные индексы в эффективности MongoDB неясны
Я ищу структуру для сохранения пользовательских данных для бота Discord. Контекст таков, что мне нужно уникальное сохранение для пользователя для каждого сервера разногласий (он же гильдия), в котором он находится. Поэтому ни идентификатор пользователя, ни идентификатор гильдии не должны быть уникальными, но я мог бы использовать их в качестве составного индекса, чтобы быстро находить пользователей в коллекции пользователей.
Верен ли мой ход мыслей до сих пор?
Мой актуальный вопрос:
Какой идентификатор должен быть первым индексом, по которому он "отсортирован"? в каждой гильдии несколько сотен или тысяч пользователей, но один пользователь входит примерно в 1-5 гильдий, в которых работает бот. Поэтому первый поиск по идентификатору гильдии несколько уменьшит объем данных для поиска по идентификатору пользователя. Но сначала поиск по идентификатору пользователя уменьшит объем данных для поиска по идентификатору гильдии. Поскольку БД в любом случае будет искать оба индекса полностью, поэтому шаг 1 будет одинаково быстрым для обоих, вторая идея с первой фильтрацией по идентификатору пользователя, а затем по идентификатору гильдии кажется мне более эффективной.
Я хотел бы знать, кажется ли мое предположение жизнеспособным, а если нет, то почему бы и нет. Или есть ли лучший способ, о котором я не думал.
Заранее спасибо!
спасибо за совет, но дело в том, что я хочу, чтобы это было отсортировано, прежде чем реализовывать его. конечно, если нет простого ответа, я просто попробую и сравню производительность позже, когда цифры будут достаточно высокими, чтобы вообще иметь значение. (сейчас у меня 60 000 пользователей), но что касается основного, я считаю, что идентификатор пользователя является самой большой нагрузкой, потому что это буквально единственное, что определяет пользователя и является уникальным почти, только я сохраняю несколько версий каждой по каждой гильдии
Дело в том, что вы хорошо знаете свои требования и знаете, как составные индексы могут быть действительно эффективными при правильном выборе. Очевидный намек - выяснить свою операцию expensive в вашем приложении и соответственно выбрать свой индекс (одиночный / составной / многоклавишный) и, если возможно, иметь в лучшем случае покрытый запрос. Рекомендую прочитать здесь: docs.mongodb.com/manual/applications/indexes
Ответы 1
Составные индексы работали нормально. Все еще недостаточно большой, чтобы увидеть разницу в их реализации, поэтому я не знаю об этом.
Прежде чем использовать предположения, всегда лучше проверить время выполнения вашего запроса, записать его, проверить объект объяснения, применить индексы, снова проверить время выполнения запроса, отметить разницу и снова проверить объект объяснения, чтобы увидеть любой примененный эффект. Более того, ваши индексы должны быть нацелены на вашу работу
majorв вашем приложении. Другими словами, вы сохраняете индексы, чтобы оптимизировать запрос, выполняющий самый длинный маршрут!