Запрос mgo возвращает EOF для больших наборов данных

Я хочу выполнить запрос, который возвращает некоторые данные с моего сервера MongoDB, но когда количество данных становится большим, я получаю ошибку «EOF» из запроса c.Find().All().

В основном у меня есть:

activeData := []DataEntry{}
activeDataQuery := bson.M{"data.active": true}
err := sigdb.Find(activeDataQuery).All(&activeData)

Это отлично работает для небольшого теста с примерно 50 000 элементов, но когда я пробую свой полный набор данных, который содержит более миллиона элементов, он возвращает «EOF», хотя там есть данные для запроса.

Что может быть причиной этого? Я запускаю как программу Go, так и сервер MongoDB на своем ноутбуке с Ubuntu 14.04, используя Go 1.3.

Изменить: после дальнейших испытаний я также получаю: «запись tcp 127.0.0.1:27017: сломанная труба» из того же запроса.


person Lars    schedule 05.03.2015    source источник


Ответы (1)


Метод All загрузит все соответствующие данные в память, что является очень плохим способом обработки большие наборы данных. Если повезет, вы получите такие тайм-ауты до завершения метода, и в худшем случае машина выйдет из строя из-за нехватки памяти.

Для любого нетривиального набора данных вместо этого используйте обычную итерацию с Iter и Методы Next.

person Gustavo Niemeyer    schedule 05.03.2015
comment
Это сработало, но произойдет ли это, если сам запрос очень большой? Я хотел бы использовать $nin для выполнения запроса, исключающего большое количество данных. Проблема в том, что если я это сделаю, в поле $nin будут сотни тысяч элементов, что вызовет тот же сбой. - person Lars; 08.03.2015
comment
Запрос с сотнями тысяч элементов в списке исключений также очень плох для любой базы данных. Я бы рассмотрел, в чем проблема, какие структуры данных задействованы, какие изменения и как часто, а затем организовал бы более реалистичное решение. - person Gustavo Niemeyer; 09.03.2015
comment
На самом деле, даже с несколькими строками возникает такая ошибка: github.com/go-mgo/ mgo/issues/473 - person Inanc Gumus; 01.08.2017