Схема mongodb для эффективной фильтрации и подкачки - PullRequest
Новая
       18

Схема mongodb для эффективной фильтрации и подкачки

0 голосов
/ 02 апреля 2020

Я создаю приложение, которое позволит нескольким пользователям создавать посты. Эти сообщения могут иметь разные параметры, поэтому я использую базу данных № 1025 * и планирую использовать MongoDB. Эти сообщения с соответствующими настройками конфиденциальности могут быть видны всем пользователям моего приложения. Поэтому, если 1000 пользователей создадут 10000 сообщений, у меня будет огромное количество сообщений (10000000). Так что мне нужно разбить его на страницы. Чтобы добиться этого, я проверил последний сохраненный подход ObjectId для продвижения вперед на каждой странице, а также подход с накоплением. Любой из них хорошо бы подошел, предпочитая подход с наложением. Однако мне также необходимо поддерживать фильтрацию этих сообщений.

Каждый пост будет иметь две категории 

{
  postName: "name",
  categoryA: "aVal",
  categoryB: "bVal"
}

Теперь categoryA может иметь одно из трех значений. categoryB может иметь одно из 8 значений. Это приложение будет поддерживать фильтрацию по любой из этих категорий или по обеим одновременно. Итак, главный вопрос, который у меня есть, - это эффективный дизайн схемы. Существует ли подход схемы, который также может помочь эффективно фильтровать структуру такого типа?

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

В настоящее время подход с последним сохранением ObjectId кажется лучше, чем приведенный выше. Мне придется индексировать обе категории для получения более быстрых результатов. Однако при таком подходе у меня есть одна проблема: что если на первой странице я получу ObjectId, который «старше». Тогда все «младшие» посты могут быть пропущены 

curosr = db.find().limit(3);
last_seen -> from curosr iteration
db.find({ "_id": { "$gt": last_seen } }).limit(3);

Гарантируется ли, что постов не будет "lt" last_seen? Если нет, то несколько сообщений никогда не будут показаны, верно?

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

Кроме того, как побочный вопрос, как я бы go о масштабировании такой схемы? Какова будет стратегия шардинга? (в случае, если мне когда-нибудь придется осколять базу данных)

...