наилучший возможный дизайн схемы для базы данных анализа журнала в mongodb

Question

я должен хранить следующие данные в mongodb uid, gender ,country, city, date_of_visit, url_of_visit

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

в другой коллекции, которую я хотел бы хранить uid, date_of_visit, url_of_visit

Я хочу знать, что лучше хранить uid, date_of_visit and url_of_visit. В моей памяти есть две вещи ..

    (a) { uid: 100, date: xxxxxxxxxxxxxxx, url: abc.php }
        { uid: 100, date: xxxxxx, url: ref.php }
        { uid: 200, date: xxxxxxxxx, url: ref.php } 

    (b) { uid:100, visit:[{date:xxxxxxx, url:abc.php},
                          {date:xxxx, url:def.php},
                          {.........................}]}

я хочу иметь следующую дату индекса: 1, uid: 1, url: 1 ... проблема с подходом (a) заключается в том, что каждая строка вставляется в базу данных со стороны базы данных, и размер индекса будет расти, и наступит точка, когда размер индекса не помещается в ОЗУ

проблема с подходом (b) заключается в том, что в какой-то момент каждый документ превысит ограничение в 16 МБ, и этот подход потерпит неудачу в этот раз.

Пожалуйста, предложите мне, какой должен быть лучший дизайн схемы для этого сценария. я также хотел бы запрос, который включает uid, gender, country, date_of_visit, url_of_visit

Answer 1

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

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

Что-то вроде:

{ uid:100, date:xxxxxxx, event:[{time:xxxxxxx, url:abc.php},
                                {time:xxxx, url:def.php},
                                {.........................}]}

Answer 2

Ваш второй подход заставит вас извлекать огромное количество данных из встроенного документа, которые не могут быть отфильтрованы Mongo. Другими словами, если у вас есть миллион документов, хранящихся в поле «событие» для конкретного пользователя, то при извлечении этих встроенных документов с точечной нотацией будет возвращен весь документ, включая родительский. Там нет, как вы можете отфильтровать результаты.

Я бы порекомендовал первый подход, который облегчает извлечение данных и работу с ними.

Answer 3

Я думаю, что второй подход лучше, чем один, потому что он соответствует идее группировки похожих данных вместе.При превышении 16М документа вы можете достичь этого предела, но он должен быть очень активным пользователем.:)

Также вы можете извлечь некоторые данные в другую коллекцию и сделать ссылку, используя ObjectId или DBRef.Подробнее http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef