#mongodb #collections #namespaces #schema
#mongodb #Коллекции #пространства имен #схема
Вопрос:
Вопрос: В приложении десятки тысяч пользователей (но менее 500 тыс.).
Решение: храните коллекцию каждого пользователя (10-20) в отдельном пространстве имен users (только по одному для каждого клиента), чтобы сэкономить место на диске за счет исключения из id ‘столбца’ каждого пользователя; ускорить время запроса из-за небольшого индекса пространства имен; уменьшить коэффициент блокировки (https://jira.mongodb.org/browse/SERVER-1240 ); упростить сегментирование (https://jira.mongodb.org/browse/SERVER-939 ).
Это нормально? Или, может быть, мне следует использовать одну общую коллекцию с пространствами имен?
Спасибо за ваши ответы.
Комментарии:
1. Итак, вам интересно, если у вас <500 тыс. пользователей, следует ли вам выполнять сегментирование, чтобы ускорить запросы? Можете ли вы показать свою текущую структуру документа, чтобы у нас было общее представление о том, как выглядят пользовательские документы?
Ответ №1:
Я думаю, что понимаю ваш вопрос, но поправьте меня, если я ошибаюсь. Похоже, вы хотите сохранить пользователей каждого приложения в их собственной коллекции. Это имеет несколько преимуществ и недостатков, которые вам приходится взвешивать на основе сложных решений администратора базы данных, таких как соотношение R / W, нагрузка и т.д.
Преимущества
- Как вы упомянули, обновление индексов займет меньше времени, потому что у них есть только сегмент пользователей.
- Запросы к неиндексированным полям (если таковые имеются) будут выполняться быстрее из-за меньшего количества элементов.
- Глобальная блокировка записи не будет играть такой большой роли, поскольку вы блокируете только для каждого приложения.
Недостатки
- Поскольку индексы ограничены коллекцией, у вас будет в разы больше индексов для хранения в памяти (количество приложений) (индексы не приносят никакой пользы, если вы выводите их на страницу).
- Поскольку индексы и коллекции занимают свои собственные пространства имен, и каждое пространство имен занимает около 628 байт, вам нужно беспокоиться о ограничении пространства имен по умолчанию в 16 МБ. Это ограничит количество приложений, которые вы можете иметь. например, с 2 индексами вы ограничены примерно 8000 коллекциями.
- Наконец, поскольку ваши пользователи будут находиться в разных коллекциях, вы не сможете выполнять запросы в разных приложениях. Это может быть подорвано MapReduce, но добавляет больше сложности.
В конце концов, вы можете достичь большинства этих преимуществ, обойдя недостатки, просто разделив некоторые ключи приложения. Сценарий с множеством коллекций заманчив, но я думаю, что в конечном итоге это не то, для чего оптимизирован mongo.
Комментарии:
1. Да, вы правильно понимаете. Итак, как вы думаете. Для чего оптимизирован mongo? Как мне поступить в этой ситуации?
2. Если вы можете позволить себе настроить пару сегментов (один сегмент — это, вообще говоря, набор реплик, состоящий из трех или более машин), вам следует поступить так, как я отметил в последнем абзаце, и не создавать коллекцию для каждого приложения. Сегментирование по ключу приложения было бы идеальным. Если вы убеждены, что можете сохранить всех своих пользователей и индексы в памяти, используя только один набор реплик, и не беспокоитесь об ограничении пространства имен, тогда я бы предложил поступить так, как вы указали в вопросе, и разбить приложения на коллекции.