MongoDB Nesting или Splitting Best Practices

Question

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

Приложение предназначено для ведения журнала, поэтому я беру журнал доступа к Apache и получаю от него много вещей, как список всех вызываемых страниц, освещенный всего IP-адреса и т. Д. И это делается через минуту.

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

Когда я запускаю запрос, я фильтрую только для отображения IP-адресов, я теряю производительность баз данных, если я группирую каждую минуту в один документ, или я трачу его, если я разбиваю каждый список на собственный документ?

Answer 1

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

Ваши комментарии могут быть сохранены в виде массива поддокументами:

# Example post document with comment subdocuments 
{ 
    title: 'How to Mongo!' 
    content: 'So I want to talk about MongoDB.', 
    comments: [ 
     { 
      author: 'Renold', 
      content: 'This post, it's amazing.' 
     }, 
     ... 
    ] 
} 

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

# Example post document with "ForeignKeys" to comment documents 
{ 
    _id: ObjectId("50c21579c5f2c80000000000"), 
    title: 'How to Mongo!', 
    content: 'So I want to talk about MongoDB.', 
    comments: [ 
     ObjectId("50c21579c5f2c80000000001"), 
     ObjectId("50c21579c5f2c80000000002"), 
     ... 
    ] 
} 

# Example comment document with a "ForeignKey" to a post document 
{ 
    _id: ObjectId("50c21579c5f2c80000000001"), 
    post_id: ObjectId("50c21579c5f2c80000000000"), 
    title: 'Renold', 
    content: 'This post, it's amazing.' 
} 

Это похоже на то, как вы храните «ForeignKeys» в реляционной базе данных. Нормализация ваших документов, подобных этому, упрощает запросы к комментариям и сообщениям. Кроме того, поскольку вы разрываете свои документы, каждый документ занимает меньше памяти. Компромисс, однако, заключается в том, что вам нужно поддерживать ссылки ObjectId всякий раз, когда есть какие-либо изменения в любом документе (например, когда вы вставляете/обновляете/удаляете комментарий или сообщение). И поскольку в Mongo нет крючков событий, вам нужно выполняйте все это техническое обслуживание в своем приложении.

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

# Example user document with address subdocument 
{ 
    ObjectId("50c21579c5f2c800000000421"), 
    name: 'Howard', 
    password: 'naughtysecret', 
    address: { 
     state: 'FL', 
     city: 'Gainesville', 
     zip: 32608 
    } 
}