Как лучше "хвост -f" большая коллекция в монго через метеор?

У меня есть коллекция в базе данных mongo, которая добавляет некоторую информацию о типах ведения журнала. Я пытаюсь найти наиболее эффективный/простой метод для "tail -f", который в приложении meteor - по мере добавления нового документа в коллекцию он должен быть отправлен клиенту, который должен добавить его в конец текущего набора документов в коллекции.

Клиент не будет отправлен и не будет содержать все документы в коллекции, вероятно, только последние ~ 100 или около того.

Теперь, с точки зрения Монголя, я не вижу способа сказать "последние N документов в коллекции", так что нам вообще не нужно было бы применять какой-либо вид. Кажется, что лучший доступный вариант - это естественный сорт, а затем лимитный вызов, что-то вроде того, что указано в файле mongo на $natural

db.collection.find().sort( { $natural: -1 } )

Итак, на стороне сервера AFAICT способ опубликования этой коллекции "Метеор последних 100 документов" будет выглядеть примерно так:

Meteor.publish('logmessages', function () {
  return LogMessages.find({}, { sort: { $natural: -1 }, limit: 100 });
});

Теперь, с точки зрения "хвост -f", это похоже на правильный эффект отправки "последних 100 документов" на сервер, но делает это в неправильном порядке (самый новый документ будет в начале Коллекция Метеор, а не в конце).

На стороне клиента это означает, что нужно (к сожалению) обратить вспять коллекцию. Теперь я не вижу обратного() в документах Meteor Collection и сортировки по $natural: 1 не работает на клиенте (что кажется разумным, поскольку нет реального монгольского контекста). В некоторых случаях сообщения будут иметь отметки времени в документах, и клиент может сортировать их, чтобы вернуть "естественный порядок", но это похоже на хакерство.

В любом случае, похоже, что я, скорее всего, пропустил гораздо более простой способ, чтобы "последние 100 документов, вставленных в коллекцию", опубликованные из монго через метеор.:)

Спасибо!

EDIT - похоже, если я изменю коллекцию в Mongo на ограниченную коллекцию, тогда сервер сможет создать верный курсор для эффективного (и быстро) получать уведомления о новых документах, добавленных в коллекцию. Однако мне не ясно, если/как заставить сервер сделать это через коллекцию Meteor.

Альтернатива, которая кажется немного менее эффективной, но не требует перехода на ограниченную коллекцию (AFAICT), использует Smart Collections, которая делает хвостовое оперение так, чтобы в меньшей степени это событие, управляемое событиями, а не опрос, и поскольку все операции в исходной коллекции будут вставками, похоже, что это все равно будет довольно эффективно. К сожалению, AFAICT у меня все еще остались проблемы с сортировкой, так как я не вижу, как определить сборку на стороне сервера как "последние 100 вставленных документов".: (

Если есть способ создания коллекции в Mongo как запрос другого ( "материализованный вид" ), возможно, я мог бы создать "коллекционный вид" в журнале "last-100" в Mongo, а затем Meteor уметь просто публиковать/подписывать всю псевдосборку?

Ответ 1

Для данных с вставкой $natural вы должны получать те же результаты, что и индексирование по метке времени и сортировке, чтобы была хорошая идея. Реверс несчастлив; Я думаю, у вас есть пара вариантов:

используйте $natural и сделайте обратную ссылку
добавить метку времени, по-прежнему использовать $natural
добавить временную метку, индекс по времени, сортировать

'# 1' - для 100 элементов выполнение обратной клиентской стороны не должно быть проблемой даже для мобильных устройств, и это отключит его от сервера. Вы можете использовать .fetch() для преобразования в массив, а затем отменить его для поддержания порядка без использования временных меток. Однако вы будете играть в обычном массиве; не более приятные функции мини-монго, поэтому сначала делайте фильтрацию перед реверсом.

'# 2' - Это интересно, потому что вам не нужно использовать индекс, но вы все равно можете использовать временную метку на клиенте для сортировки записей. Это дает вам преимущество пребывания в мини-манго.

'# 3' - Затраты пространства на db, но его наиболее прямолинейный

Если вам не нужны возможности mini-mongo (или удобны для фильтрации массива), то лучше всего # 1.

К сожалению, у MongoDB нет представлений, поэтому вы не можете использовать идею представления журнала-last-100 (хотя это было бы неплохой функцией).

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