База данных MongoDb против коллекции

Ответ 1

Итак, вы смотрите где-то в области 100 миллиардов записей (1 миллион записей * 100 000 пользователей).

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

Поэтому ответ на ваш вопрос помещает все ваши записи в одну осколковую коллекцию.

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

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

Ответ 2

Итак, вы ищете 100 000 000 подробных записей в целом для пользователей 100K?

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

Итак, если вы используете единую коллекцию для общих данных (т.е. одну коллекцию под названием user и одну называемую detail), вы соответствуете основной цели и сборки MongoDBs.

MongoDB, как уже упоминалось, не так хорош для масштабирования по вертикали во многих коллекциях. Он имеет предел nssize, и даже если исходные коллекции 12K оцениваются в действительности из-за размера индекса, вы можете иметь всего лишь 5K коллекций в своей базе данных.

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

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

Я никогда не сталкивался с тем, что кто-то не смог масштабировать MongoDB до миллиардов или даже близко к 100 миллиардам (или, возможно, за его пределами) на оптимизированной настройке, однако я не понимаю, почему это невозможно; ведь Facebook способен сделать MySQL масштаб в 100 миллиардов долларов на одного пользователя (через 32K + осколки) для них, и концепция очертания сходна между двумя базами данных.

Итак, теория и возможность сделать это есть. Речь идет о выборе правильной схемы и концепции осколков и ключа (и разделителей, сети и т.д. И т.д. И т.д.).

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

Ответ 3

О коллекции для каждого пользователя:

По умолчанию конфигурация MongoDB ограничена 12 000 коллекциями. Вы можете увеличить его размер с помощью - nssize, но это не будет неограниченным. И вам нужно подсчитать индекс в этом 12k. (проверьте концепцию пространства имен на документации mongo).

О базе данных для каждого пользователя:

Для модельной точки зрения это очень любопытно. Для технических ограничений нет ограничений на монго, но вы, вероятно, имеете ограничение с файловым дескриптором (ограничение от вашей ОС/настроек).

Так как @Rohit говорит, два последних не очень хороши. Возможно, вам стоит больше рассказать о вашем случае. Возможно, вы можете разрезать пользователей в разные коллекции (например: по одному для каждой первой буквы имени и т.д. Или для каждой службы компании...). И, конечно, используйте осколки.

Изменить: возможно, MongoDb - не лучшая база данных для вашего использования.