Как выбрать список внутренних свойств документов Mongo?

Question

[deadkrolik]

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

{
 name: "Вася",
 photos: [
  {name: "Я в Нигерии", date: 2012-02-14},
  {name: "Я в Бутане", date: 2012-03-15},
 ]
},
{
 name: "Петя",
 photos: [
  {name: "Я неудачник", date: 2012-02-29},
 ]
}

Как можно сделать такой запрос, что бы оно вытаскивало все фотки пользователей, в порядке убывания даты фотографирования. То есть сначала будет «Я в Бутане», потом «Я неудачник» и в конце «Я в Нигерии».

Answer 1

[gaelpa]

Предположу, что без кода на клиенте, это можно сделать либо через Map/Reduce (а он вроде блокирующий), либо Aggregation Framework, который здесь уже упоминался, но будет только в 2.2.
Буду приятно удивлен, если можно проще.

Comments

[deadkrolik]

Про aggregation я и писал, мне это показалось клевым, после непонятного map/reduce. Может вы сможете на примере показать как хотя бы подступиться через map/reduce к этой штуке. Это нужно сейчас, подождать новую версию никак не получится.

[gaelpa]

Если речь идет о сайте и «живом поиске», то, в меру моего понимания эффективности Map/Reduce, его лучше не использовать. Однако, можно использовать Multikeys и минимальную клиентскую обработку, для получения нужного результата.

db.coll.ensureIndex({'photos.date':-1},{'sparse':1})
db.coll.find({},{'photos'}).sort({'photos.date':-1}).limit(10)

Это даст результат, который клиентом не сложно смерджить в сортированный список фоток. Для «первой страницы» — вполне.

[gaelpa]

Если элементы массива photos сортированы естественным образом (по моменту регистрации, а не вручную указаны), то к предыдущему стоит изменить

find({},{'photos'})

на

find({},{'photos':{$slice:-10}})

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

[deadkrolik]

Ну по сути надо сделать нормальную постраничку «Последние фотки пользователей». Причем это не обязательно будут фотки. Блогозаписи, метки, видео. Формат хранения — вот такой. С MySQL все просто, сделали count(*) от джойна таблиц и выбрали сколько надо и откуда надо. Хочется сделать максимально прозрачный подход к формированию таких списков. И как мне кажется map/reduce он именно для этого и создан (для порядка назову цифры: пользователей — около 200 тыс, фотки есть у тысячи).

Если делать именно через sort по дате, то в первом документе могут оказаться фотки, которые должны идти последними в списке. То есть на клиенте обработать несколько тысяч фоток для построения списка это нереально. Сервер по идее с этим должен лучше справляться?

Есть конечно вариант построения некого промежуточного звена. Но тогда вообще теряется смысл монго как документ-ориентированного хранилища.

[gaelpa]

С постраничкой на монге без AF можно сделать только выносом контента из-под пользователей.
Для этого есть 3 варианта: вынести в-принципе (максимум оставив id-ссылки), выносить «триггером» в приложении и выносить по крону через итеративный M/R.
Первый вариант очень дорогой по переделке, третий даст задержку между обновлениями, зато не вмешивается в код.

[deadkrolik]

Спасибо за ответы.

Answer 2

[1nd1go]

Я с монгой знаком поверхностно, но может быть можно писать фотки в другую коллекцию со ссылкой на объекты из первой коллекции. Тогда вы можете просто положить фотки в виде

{
  date : "12-10-2012",
  description : "Я в Гондурасе",
  owner : "1234"
}

И наложить соответствующие индексы и там правильно сортировать.

Вообще, на сколько я помню: монга — это чтобы быстро пописать. Так что данные там лучше хранить в более простом виде, чтобы читать было потом их проще…

Comments

[gaelpa]

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