Мангуста Курсоры с множеством документов и загрузки

Question

Некоторое время мы использовали mongoose в Node.Js / Express, и одна из вещей, о которых мы не понимаем, это то, что происходит, когда у вас есть запрос с использованием find и у вас большой набор документов. Например, предположим, что вы хотите перебрать всех своих пользователей для выполнения фоновой обработки с низким приоритетом.

let cursor = User.find({}).cursor();
cursor.on('data',function(user) {
   // do some processing here 
});

Я понимаю, что cursor.on ('data') не блокируется. Следовательно, если у вас есть, скажем, 100 000 пользователей, вы перегружаете систему, пытаясь обработать 100 000 человек почти одновременно. Похоже, не существует «следующего» или другого метода, регулирующего нашу способность потреблять документы.

Как вы обрабатываете большие наборы результатов документа?

Answer 1

У Mongoose действительно есть метод .next() для курсоров! Ознакомьтесь с документацией Mongoose . Вот снимок раздела Пример по состоянию на этот ответ:

// There are 2 ways to use a cursor. First, as a stream:
Thing.
  find({ name: /^hello/ }).
  cursor().
  on('data', function(doc) { console.log(doc); }).
  on('end', function() { console.log('Done!'); });

// Or you can use `.next()` to manually get the next doc in the stream.
// `.next()` returns a promise, so you can use promises or callbacks.
var cursor = Thing.find({ name: /^hello/ }).cursor();
cursor.next(function(error, doc) {
  console.log(doc);
});

// Because `.next()` returns a promise, you can use co
// to easily iterate through all documents without loading them
// all into memory.
co(function*() {
  const cursor = Thing.find({ name: /^hello/ }).cursor();
  for (let doc = yield cursor.next(); doc != null; doc = yield cursor.next()) {
    console.log(doc);
  }
});

---

Учитывая вышесказанное, вполне возможно, что ваш набор данных может стать достаточно большим и трудным для работы. Для вас может быть хорошей идеей рассмотреть возможность использования конвейера агрегации MongoDB для упрощения обработки больших наборов данных. Если вы используете набор реплик, вы даже можете установить readPreference, чтобы направлять ваши большие запросы агрегирования на вторичные узлы, гарантируя, что производительность основного узла останется практически неизменной. Это переместит нагрузку с вашего сервера на менее критичные вторичные узлы базы данных.

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

Наконец, есть также опция балансировки нагрузки. У вас может быть несколько серверов приложений для обработки и балансировщик нагрузки, который примерно равномерно распределяет запросы между ними, чтобы предотвратить перегрузку любого сервера.

---

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