Захват неизвестного документа, добавленного во время большого поиска в Mongodb

Question

Мне было интересно Spring Mongo API для find загружает все в List. Если результат поиска содержит миллиард записей, не повлияет ли это на память? Может ли кто-то предложить лучший способ достичь этого, не загружая все это в память. Использование лимита может помочь, но тогда есть недостаток, что он не знает, вставлен ли новый документ в коллекцию. Ну, find by limit будет иметь тот же эффект, если коллекция изменит после чтения X of billion записей.

Так два вопроса:

• Повышение производительности не загружая все в памяти
• Как бы вы решить эту не-известный документ добавлен в процессе обработки?

код из API

List<T> result = new ArrayList<T>(); 

while (cursor.hasNext()) { 
    DBObject object = cursor.next(); 
    result.add(objectCallback.doWith(object)); 
} 

Answer 1

Повышение производительности не загружая все в памяти

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

В MongoDB сервер возвращает результаты запроса в cursor batches, что не может превышать 16 МБ (maximum BSON document size как у MongoDB 3.0 .. и на самом деле обычно 1 МБ для первой партии и 4 МБ для последующих партий). Вы можете создать больший результат, продолжая перебирать курсор в коде приложения, но реализация - ваш выбор.

Как бы вы разрешили этот неопубликованный документ, добавленный во время обработки?

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

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