Вы тоже можете это сделать, но я думаю, вам придется учитывать периодический рост базы данных для любого случая. Во время расширения базы данных данных файлы будут медленными/невосприимчивыми. (Может быть настройка, так что это происходит в фоновом режиме - я забываю).
Смежный вопрос - MongoDB performance with growing data structure, в частности, «Перетяжка Factor»
С первым подходом, существует верхний предел количество сайтов, которые вы можете хранить налагаемые максимальным числом коллекций. Вы можете делать вычисления на основе http://docs.mongodb.org/manual/reference/limits/.
Во втором подходе, в то время как коллекция # не имеет значения, но рост базы данных - это то, что вы захотите рассмотреть.
Один из подходов состоит в том, чтобы инициализировать его пустыми данными, поэтому до расширения требуется больше времени.
Например.
{
website: name,
responses: [{
time: Jan 1, 2013, 0:1, ...
},
{
time: Jan 1, 2013, 0:2, ...
}
... and so for each minute/interval you expect.
]
}
Недостатком является то, что для инициализации может потребоваться больше времени, но вам придется беспокоиться об этом позже.
В любом случае, это стоимость, которую вам придется заплатить. Вопрос только в том, когда? Теперь? или позже?
Рассмотрим чтение их usecases, в частности - http://docs.mongodb.org/manual/use-cases/hierarchical-aggregation/
спасибо. Я буду использовать первое решение (каждый веб-сайт - сборник). когда коллекции достигают ограничения, я могу иметь другую базу данных. и если мои # сайты растут (я думаю, что это занимает год или два), я рассматриваю возможность использования Cassandra и Hadoop. –