В памяти накопитель движок не быстрее проводного тигра - PullRequest
Новая
       15

В памяти накопитель движок не быстрее проводного тигра

0 голосов
/ 05 июля 2018

Я выполняю запрос, который возвращает много данных. Он ищет 916 документов, каждый из которых имеет большое поле данных (около 5 МБ). Запрос выглядит так: 

db.collection.find(
{'name': somename, 'currency': mycurrency, 
'valuation_date': {'$in': [list_of_250_datetime_datetime]}
}.{'data_column: is set to true or false in the below test results}).limit(x)

Я пытался оптимизировать запрос и обнаружил, что большую часть времени тратится на загрузку (или передачу) такого большого элемента данных, а не на поиск его в базе данных объемом 5 ГБ. Поэтому я предполагаю, что запрос должным образом оптимизирован и индексы используются правильно, что также подтверждается профилировщиком.

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

В памяти механизма хранения: 

================ Starting test using mongodb://localhost:27018/ ================
Looking up 100 values excluding data column...
++++++++++ Query completed in 0.0130000114441 seconds ++++++++++ 
Looking up 100 values, full json with data...
++++++++++ Query completed in 2.85100007057 seconds ++++++++++ 
Looking up all values, excluding data column...
++++++++++ Query completed in 0.0999999046326 seconds for 916 items ++++++++++ 
Looking up all values, full json with data...
++++++++++ Query completed in 29.2250001431 seconds for 916 items ++++++++++

Проводной тигр: 

================ Starting test using mongodb://localhost:27017/ ================
Looking up 100 values excluding mdo column...
++++++++++ Query completed in 0.0120000839233 seconds ++++++++++ 
Looking up 100 values, full json with data...
++++++++++ Query completed in 2.97799992561 seconds ++++++++++ 
Looking up all values, excluding data column...
++++++++++ Query completed in 0.0700001716614 seconds for 916 items ++++++++++ 
Looking up all values, full json with data...
++++++++++ Query completed in 23.8389999866 seconds for 916 items ++++++++++

Ответы [ 2 ]

0 голосов
/ 05 июля 2018

Насколько мне известно, WiredTiger сохраняет данные на диске для индекса, user_data, реплики и т. Д., В то время как механизм хранения в памяти хорош с меньшим количеством операций disk-io, поскольку он не сохраняет никаких данных на диске. Также прочитайте это

Механизм хранения в памяти требует, чтобы все его данные (включая оплог если mongod является частью набора реплик и т. д.) вписывается в указанный Параметр командной строки --inMemorySizeGB или параметр storage.inMemory.engineConfig.inMemorySizeGB. См. Использование памяти.

Итак, если размер данных, к которым вы обращаетесь, слишком велик, это в конечном итоге займет больше времени, чем WiredTiger.

0 голосов
/ 05 июля 2018

Это не быстрее, потому что MongoDB с WT кэширует данные в памяти в любом случае, у вас достаточно ОЗУ для данных, которые вы запрашиваете, чтобы поместиться в кэш, так что нет никакого штрафа (кроме, конечно, первого доступа) при чтении с диска , Если бы вы начали с холодного кэша, вы бы увидели значительную разницу между WT и оперативной памятью, но не после того, как данные были доступны и загружены в кеш.

Моим непосредственным подозрением будет сеть, и если это 5MiB на каждый из 916 документов, что будет означать, что вы получаете (916 * 5 * 8)/23.84 = 1.537Gb/s или для первого примера (916 * 5 * 8)/29.23 = 1.254Gb/s - версии с 100 значениями находятся в аналогичных диапазонах. Вы не упомянули, является ли это Windows или Linux, или что-то еще об окружающей среде, кроме того, что это использует localhost, так сложно комментировать, что может ускорить процесс, но я подозреваю, что это передача данных, которая Ваше узкое место на данный момент.

...