Почему MongoDB очень медленно извлекает документы?

Question

[atis //]

Всем привет.

Такая штука. Монго выполняет запрос очень быстро но вот обход данных foreach -ем занимает очень много времени. Измеряю время функцией microtime()
Результат вывода функции

microtime(true)
// 1464330248.2163
$MongoCollection = (new \MongoClient())->selectCollection('db', 'coll');
$MongoCursor     = $MongoCollection->find($where, $fields)->sort($sort)->limit(50)->skip($this->offset);
// 1464330248.2165

foreach($MongoCursor as $doc) {

}

// 1464330253.6667

Как видно на примере цикл длится аж три секунды. Это даже в том случае если в цикле ничего не происходит.
Иcпользую MongoDB v3.2.6

Answer 1

[lega]

Монго выполняет запрос очень быстро но вот обход данных foreach -ем занимает очень много времени.

1) Запрос выполняется в момент когда вы начали тащить данные, а команда find просто готовит запрос.
2) Запрос работает медленно потому что у вас нет нужного индекса, и монга тут не причем, любая БД без индексов тормозит, т.к. сканируются и сортируются все данные в момент запроса.

Comments

[atis //]

Я добавил индексы. Например - db.createIndex({"price": 1, "price": -1}) и все равно медленно

[lega]

atis //: поэтому я и написал что нужно добавить _нужный_ индекс, а не просто индекс.
Индекс строиться под запросы.

Дайте ваш полный запрос, фильтр (условие), сортировка, skip и limit

[atis //]

lega: db.items.find({"name": {$regex: userInput}, "price" : {$gte: 0}}, {"_id":0, "name":1, "price":1}).sort({"price": -1}).limit(50).skip(0)

[lega]

atis //: ok, проблема в $regex, не используйте его на больших коллекциях. Под него индекс не строится, и происходит полный перебор.
Если нужен поиск по тексту то используйте текстовый индекс. Если нужен поиск каких-то ключевых слов, то можно сделать массив (с индексом) для этого.

[atis //]

lega: а если sphinx юзать?

[lega]

atis //: sphinxsearch ещё лучше, но нужна интеграция

Answer 2

[spotifi]

Ну для начала посмотри
https://docs.mongodb.com/manual/reference/method/d...

Во вторых - а зачем тебе курсоры? Они всегда были тормозным местом во всех СУБД по сравнению с прямыми запросами.

Их применение оправдано при хитрой-сложной обработке на сервере - чего в данном случае не наблюдается.

Comments

[atis //]

И как в таком случае тянуть данные?

[spotifi]

atis //:
Для начала почитать официальную документацию

php.net/manual/ru/class.mongocursor.php

Там предлагается 2 метода.
Почему ты выбрал второй?

Просто потому что тебе он понятен?

Курсорный метод позволяет получать данные с сервера частями, но для случая обычного вебприложения в этом смысла нет. Этот метод должен использоваться только если данных в ответе (в результате find() ) слишком много.

[atis //]

И первый и второй вариант имею точно такой же вариант как в моем примере!

[spotifi]

atis //:
второй - как у вас.
первый - нет.
и к первому есть замечания про те редкие случае, когда нельзя использовать первый - внимательно прочитайте.

[atis //]

spotifi: Простой перебор массива из 2-го варианта
foreach run 1464335383.7088
foreach end 1464335386.0473

Ипростой вызов функции iterator_to_array()
iterator run 1464335386.0473
iterator end 1464335388.3665

[spotifi]

atis //: обновляйся. не может этого быть.
см. внимательно план запроса - может в нем затык.

[atis //]

spotifi: В БД 4М товаров, кстати

[atis //]

atis //: И весит БД 6 ГБ. Это одна цельная база! Без шардов

[spotifi]

atis //: насмешил. у меня несколько миллиардов сущностей в БД. Без шардов. все летает.
изучай план запроса и индексы.

БД локально или по доступна только по сети?

[atis //]

spotifi: локально

[spotifi]

atis //: для современны баз данных и современных компьютеров 6 Г и 4 М - это смешные цифры. Это даже меньше объема оперативной памяти в типичном сервере.

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

[atis //]

spotifi: а как посмотреть можно?

[spotifi]

atis //:
В Windows - диспетчер задач.
В *nix - losst.ru/ispolzovanie-operativnoj-pamyati-linux

[spotifi]

atis //: как посмотреть план запроса - первая ссылка в самом первом моем ответе.

[atis //]

spotifi: монга ест 12 гигабайт

[atis //]

spotifi: Я заметил что если убрать сортировку то запрос отрабатывает за 0.3000 милисекунд

[spotifi]

atis //: без сортировки limit/offset не будет работать как надо. ибо без сортировки не гарантируется последовательность выборки данных.

в одном запросе получишь 1, 3, 5, 2, 5 при limit/offset от первого до пятого элемента.
в следующем запросе получишь 14, 2, 1, 22, 15 при limit/offset от шестого до десятого элемента.

[spotifi]

atis //:
если без sort летает, то это индексы для сортировки нужны. 100%.

[atis //]

spotifi: но я добавил индексы для сортировки

[spotifi]

atis //: или индексация не завершена или не то добавил.
изучай план запроса - самая первая моя ссылка про explain.

[atis //]

spotifi: хорошо. спасибо