Я разрабатываю систему с MongoDb (64-разрядная версия) для обработки большого количества пользователей (около 100 000), и каждый пользователь будет иметь большие объемы данных (около 1 миллиона записей).
Какова лучшая стратегия дизайна?
Дамп всех записей в одной коллекции
У вас есть коллекция для каждого пользователя
Имейте базу данных для каждого пользователя.
Большое спасибо,
Итак, вы смотрите где-то в области 100 миллиардов записей (1 миллион записей * 100 000 пользователей).
Предпочтительным способом обработки больших объемов данных является создание осколочного кластера, который разбивает данные на несколько серверов, которые представлены как единый логический блок через клиент-монго.
Поэтому ответ на ваш вопрос помещает все ваши записи в одну осколковую коллекцию.
Количество требуемых осколков и конфигурация кластера связано с размером данных и другими факторами, такими как количество и распределение чтения и записи. Ответы на эти вопросы, вероятно, очень специфичны для вашей уникальной ситуации, поэтому я не буду пытаться их угадать.
Я бы, вероятно, начал, решив, сколько у вас есть времени и машины, чтобы настроить и протестировать систему на кластере этих многих машин. Исходя из этого, вы можете решить, нужно ли вам больше или меньше осколков в кластере
Итак, вы ищете 100 000 000 подробных записей в целом для пользователей 100K?
Многие люди, похоже, не понимают, что MongoDB хорош в горизонтальном масштабировании. Горизонтальное масштабирование обычно классифицируется как масштабирование огромных отдельных коллекций данных на многих (многих) серверах в огромном кластере.
Итак, если вы используете единую коллекцию для общих данных (т.е. одну коллекцию под названием user и одну называемую detail), вы соответствуете основной цели и сборки MongoDBs.
MongoDB, как уже упоминалось, не так хорош для масштабирования по вертикали во многих коллекциях. Он имеет предел nssize, и даже если исходные коллекции 12K оцениваются в действительности из-за размера индекса, вы можете иметь всего лишь 5K коллекций в своей базе данных.
Таким образом, сбор для каждого пользователя вообще невозможен. Он будет использовать MongoDB против своих основных принципов.
Наличие базы данных для каждого пользователя связано с теми же проблемами, может быть и больше, с наличием уникальных коллекций для каждого пользователя.
Я никогда не сталкивался с тем, что кто-то не смог масштабировать MongoDB до миллиардов или даже близко к 100 миллиардам (или, возможно, за его пределами) на оптимизированной настройке, однако я не понимаю, почему это невозможно; ведь Facebook способен сделать MySQL масштаб в 100 миллиардов долларов на одного пользователя (через 32K + осколки) для них, и концепция очертания сходна между двумя базами данных.
Итак, теория и возможность сделать это есть. Речь идет о выборе правильной схемы и концепции осколков и ключа (и разделителей, сети и т.д. И т.д. И т.д.).
Если бы вы были свидетелями проблем, вы могли бы пойти на разделение коллекций архивов или удаленных элементов вдали от основной коллекции, но я думаю, что это слишком много, но вы хотите убедиться, что MongoDB знает, где каждый сегмент вашего огромного набора данных находится в любой заданный момент времени на ведущем устройстве и гарантировать, что эти данные всегда горячие, таким образом, запросы, которые не выполняют глобальный и рассеянный OP, должны быть довольно быстрыми.
О коллекции для каждого пользователя:
По умолчанию конфигурация MongoDB ограничена 12 000 коллекциями. Вы можете увеличить его размер с помощью - nssize, но это не будет неограниченным. И вам нужно подсчитать индекс в этом 12k. (проверьте концепцию пространства имен на документации mongo).
О базе данных для каждого пользователя:
Для модельной точки зрения это очень любопытно. Для технических ограничений нет ограничений на монго, но вы, вероятно, имеете ограничение с файловым дескриптором (ограничение от вашей ОС/настроек).
Так как @Rohit говорит, два последних не очень хороши. Возможно, вам стоит больше рассказать о вашем случае. Возможно, вы можете разрезать пользователей в разные коллекции (например: по одному для каждой первой буквы имени и т.д. Или для каждой службы компании...). И, конечно, используйте осколки.
Изменить: возможно, MongoDb - не лучшая база данных для вашего использования.