По катом будет совсем небольшое сравнение производительности MongoDB в случаях использования $or и $in логических операций в запросах. Надеюсь, что данная заметка сэкономит кому-нибудь рабочее время.
Тесты запускались на MongoDB 2.4.9
Допустим в MongoDB есть коллекция документов. Для упрощения понимания сути — пусть это будут документы именно с двумя полями.
В коллекции будет всего 10К документов. Да, тут можно было использовать batchInsert, но не хочу усложнять понимание основной сути заметки.
Необходимо регулярно (несколько раз в секунду) делать выборку до 1000 документов. Условием выборки является набор несвязанных пар i и j.
Т.к. я с MongoDB начал работать меньше месяца назад, то первое, что пришло в голову — это запрос вот такого вида:
То, что тут данные идут по порядку — это только для примера, чтобы не забивать голову бизнес логикой. В реальности, как я выше отметил, пары i и j друг с другом никак не связаны и идут в хаотичном порядке.
Попробовав выполнить этот запрос у меня широко раскрылись глаза от неприятного удивления — запрос выполнялся больше 2-х секунд! Выше в коде видно, что индекс при этом создан.
Это было вообще неприемлемо.
Я решил убедиться, что тут не сеть тормозит, а дело именно в запросе.
Для теста сделает вот такой запрос:
Результат по объему данных тот же самый, но запрос уже начинает выполняться 0.01 секунды.
Стало понятно, что нужно искать обходной путь. И он был найден. По логике запроса напрашивалось использование $in вместо $or. Но я не смог найти как использовать $in сразу по парам значений. Если такой способ есть, то буду очень благодарен за подсказку.
Раз я не знаю как сделать $in по двум полям, то введем искусственное поле следующим образом (слепим значения i и j через подчеркивание '_'):
И тогда запрос наш становится следующим:
И «о чудо!» мы получаем наши данные всего за 0.01 секунды (а ведь все начиналось с «больше 2-х секунд»).
Погуглив немного я нашел следующее объяснение данного феномена: при запросе с конструкцией $or MongoDB якобы делает несколько запросов и потом «мёржит» результаты. Не уверен в правоте данного утверждения, но другого пока не нашел.
P.S. Вывод: не злоупотребляйте $or
P.P.S. В коде ниже видно как я замерял время. Если кто-то не в курсе, то уточню, что при вызове find() запрос не выполняется! Создается только объект MongoCursor. И только уже при запросе первого документа идет сам запрос. Поэтому отсечки времени и снимаются на первой итерации цикла получения документов.
UPD 1 dim_s посоветовал вместо композитного (а из теста выше видно, что использовался именно композитный) индекса сделать два отдельных. Сделав так скорость обработки запроса ускорилась примерно в 10 раз (до 0.2 секунды), но все равно проигрывает варианту с $in
Выкладываю то, что выдает explain:
UPD 2 Прогнал тест на свежей версии MongoDB 2.6
Действительно, исходный вариант (композитный индекс по двум полям) там работает значительно быстрее! А именно за 0.07 секунды. Но в тоже время вариант с индексом вида i_j все равно за 0.006 — 0.01 секунд (т.е. примерно раз в 10 быстрее)
Тесты запускались на MongoDB 2.4.9
Допустим в MongoDB есть коллекция документов. Для упрощения понимания сути — пусть это будут документы именно с двумя полями.
$m = new MongoClient('mongodb://mongodb01,mongodb02,mongodba/?replicaSet=pkrs'); $mdb = $m->selectDB('test'); $collection = $mdb->selectCollection('test'); $collection->drop(); $collection->ensureIndex(array('i' => 1, 'j' => 1)); for ($i = 0; $i < 100; ++$i) { for ($j = 0; $j < 100; ++$j) { $collection->insert(array('i' => $i, 'j' => $j)); } }
В коллекции будет всего 10К документов. Да, тут можно было использовать batchInsert, но не хочу усложнять понимание основной сути заметки.
Необходимо регулярно (несколько раз в секунду) делать выборку до 1000 документов. Условием выборки является набор несвязанных пар i и j.
Т.к. я с MongoDB начал работать меньше месяца назад, то первое, что пришло в голову — это запрос вот такого вида:
$orArray = array(); for ($i = 0; $i < 10; ++$i) { for ($j = 0; $j < 100; ++$j) { $orArray[] = array('i' => $i, 'j' => $j); } } $query = array('$or' => $orArray);
То, что тут данные идут по порядку — это только для примера, чтобы не забивать голову бизнес логикой. В реальности, как я выше отметил, пары i и j друг с другом никак не связаны и идут в хаотичном порядке.
Попробовав выполнить этот запрос у меня широко раскрылись глаза от неприятного удивления — запрос выполнялся больше 2-х секунд! Выше в коде видно, что индекс при этом создан.
Это было вообще неприемлемо.
Я решил убедиться, что тут не сеть тормозит, а дело именно в запросе.
Для теста сделает вот такой запрос:
$query = array('i' => array('$lt' => 10), 'j' => array('$lt' => 100));
Результат по объему данных тот же самый, но запрос уже начинает выполняться 0.01 секунды.
Стало понятно, что нужно искать обходной путь. И он был найден. По логике запроса напрашивалось использование $in вместо $or. Но я не смог найти как использовать $in сразу по парам значений. Если такой способ есть, то буду очень благодарен за подсказку.
Раз я не знаю как сделать $in по двум полям, то введем искусственное поле следующим образом (слепим значения i и j через подчеркивание '_'):
$collection->ensureIndex(array('ij' => 1)); for ($i = 0; $i < 100; ++$i) { for ($j = 0; $j < 100; ++$j) { $collection->insert(array('i' => $i, 'j' => $j, 'ij' => $i.'_'.$j)); } }
И тогда запрос наш становится следующим:
$inArray = array(); for ($i = 0; $i < 10; ++$i) { for ($j = 0; $j < 100; ++$j) { $inArray[] = $i.'_'.$j; } } $query = array('ij' => array('$in' => $inArray));
И «о чудо!» мы получаем наши данные всего за 0.01 секунды (а ведь все начиналось с «больше 2-х секунд»).
Погуглив немного я нашел следующее объяснение данного феномена: при запросе с конструкцией $or MongoDB якобы делает несколько запросов и потом «мёржит» результаты. Не уверен в правоте данного утверждения, но другого пока не нашел.
P.S. Вывод: не злоупотребляйте $or
P.P.S. В коде ниже видно как я замерял время. Если кто-то не в курсе, то уточню, что при вызове find() запрос не выполняется! Создается только объект MongoCursor. И только уже при запросе первого документа идет сам запрос. Поэтому отсечки времени и снимаются на первой итерации цикла получения документов.
P.P.P.S. Если кому-то будет интересно погонять тесты у себя, то вот весь исходник:
<?php $m = new MongoClient('mongodb://mongodb01,mongodb02,mongodba/?replicaSet=pkrs'); $mdb = $m->selectDB('test'); $collection = $mdb->selectCollection('test'); $collection->drop(); $collection->ensureIndex(array('i' => 1, 'j' => 1)); for ($i = 0; $i < 100; ++$i) { for ($j = 0; $j < 100; ++$j) { $collection->insert(array('i' => $i, 'j' => $j)); } } $orArray = array(); for ($i = 0; $i < 10; ++$i) { for ($j = 0; $j < 100; ++$j) { $orArray[] = array('i' => $i, 'j' => $j); } } $query = array('$or' => $orArray); testQuery('OR Query', $collection, $query); $query = array('i' => array('$lt' => 10), 'j' => array('$lt' => 100)); testQuery('Range Query', $collection, $query); $collection->drop(); $collection->ensureIndex(array('ij' => 1)); for ($i = 0; $i < 100; ++$i) { for ($j = 0; $j < 100; ++$j) { $collection->insert(array('i' => $i, 'j' => $j, 'ij' => $i.'_'.$j)); } } $inArray = array(); for ($i = 0; $i < 10; ++$i) { for ($j = 0; $j < 100; ++$j) { $inArray[] = $i.'_'.$j; } } $query = array('ij' => array('$in' => $inArray)); testQuery('IN Query', $collection, $query); function testQuery ($testName, $collection, $query) { $cursor = $collection->find($query); $cursor->batchSize(1000); $start = microtime(true); $first = true; foreach ($cursor as $doc) { if ($first) { $time1 = microtime(true); $first = false; } } $time2 = microtime(true); $resultFirst = $time1 - $start; $resultOther = $time2 - $time1; echo "{$testName} - First: {$resultFirst} Other: {$resultOther}<br />\n"; }
UPD 1 dim_s посоветовал вместо композитного (а из теста выше видно, что использовался именно композитный) индекса сделать два отдельных. Сделав так скорость обработки запроса ускорилась примерно в 10 раз (до 0.2 секунды), но все равно проигрывает варианту с $in
Выкладываю то, что выдает explain:
Explain ($or при композитном индексе)
/* 0 */ { "clauses" : [ { "cursor" : "BtreeCursor i_1_j_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "nscannedObjectsAllPlans" : 1, "nscannedAllPlans" : 1, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "i" : [ [ 1, 1 ] ], "j" : [ [ 1, 1 ] ] } }, { "cursor" : "BtreeCursor i_1_j_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "nscannedObjectsAllPlans" : 1, "nscannedAllPlans" : 1, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "i" : [ [ 2, 2 ] ], "j" : [ [ 2, 2 ] ] } } ], "n" : 2, "nscannedObjects" : 2, "nscanned" : 2, "nscannedObjectsAllPlans" : 2, "nscannedAllPlans" : 2, "millis" : 0, "server" : "mongodb01:27017" }
Explain ($or при двух отдельных индексах по i и j)
/* 0 */ { "clauses" : [ { "cursor" : "BtreeCursor i_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 100, "nscanned" : 100, "nscannedObjectsAllPlans" : 300, "nscannedAllPlans" : 300, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 1, "indexBounds" : { "i" : [ [ 1, 1 ] ] } }, { "cursor" : "BtreeCursor i_1", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 100, "nscanned" : 100, "nscannedObjectsAllPlans" : 300, "nscannedAllPlans" : 300, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 1, "indexBounds" : { "i" : [ [ 2, 2 ] ] } } ], "n" : 2, "nscannedObjects" : 200, "nscanned" : 200, "nscannedObjectsAllPlans" : 600, "nscannedAllPlans" : 600, "millis" : 2, "server" : "mongodb01:27017" }
Explain ($in при искусственно введенном индексе)
/* 0 */ { "cursor" : "BtreeCursor ij_1 multi", "isMultiKey" : false, "n" : 2, "nscannedObjects" : 2, "nscanned" : 3, "nscannedObjectsAllPlans" : 2, "nscannedAllPlans" : 3, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "ij" : [ [ "1_1", "1_1" ], [ "2_2", "2_2" ] ] }, "server" : "mongodb01:27017" }
UPD 2 Прогнал тест на свежей версии MongoDB 2.6
Действительно, исходный вариант (композитный индекс по двум полям) там работает значительно быстрее! А именно за 0.07 секунды. Но в тоже время вариант с индексом вида i_j все равно за 0.006 — 0.01 секунд (т.е. примерно раз в 10 быстрее)
