MongoDB не е магически по-бърз. Ако съхранявате едни и същи данни, организирани по принцип по същия начин, и осъществявате достъп до тях по абсолютно същия начин, тогава наистина не бива да очаквате резултатите ви да бъдат изключително различни. В крайна сметка и MySQL, и MongoDB са GPL, така че ако Mongo имаше някакъв магически по-добър IO код в него, тогава екипът на MySQL би могъл просто да го включи в своята кодова база.
Хората виждат реалната производителност на MongoDB до голяма степен, защото MongoDB ви позволява да правите заявки по различен начин, който е по-чувствителен към вашето работно натоварване.
Например, помислете за дизайн, който запазва много информация за сложен обект по нормализиран начин. Това може лесно да използва десетки таблици в MySQL (или всякакъв релационен db), за да съхранява данните в нормална форма, с много индекси, необходими за осигуряване на релационна цялост между таблиците.
Сега помислете за същия дизайн с магазин за документи. Ако всички тези свързани таблици са подчинени на основната таблица (а често са), тогава може да сте в състояние да моделирате данните така, че целият обект да се съхранява в един документ. В MongoDB можете да съхранявате това като един документ, в една колекция. Тук MongoDB започва да дава възможност за превъзходна производителност.
В MongoDB, за да извлечете целия обект, трябва да изпълните:
- Едно търсене в индекса на колекцията (ако приемем, че обектът е извлечен по идентификатор)
- Извличане на съдържанието на една страница на базата данни (действителният двоичен json документ)
Така че търсене в b-дърво и четене на двоична страница. Log(n) + 1 IOs. Ако индексите могат да се намират изцяло в паметта, тогава 1 IO.
В MySQL с 20 таблици трябва да изпълните:
- Едно търсене на индекс в основната таблица (отново, ако приемем, че обектът е извлечен от идентификатор)
- С клъстериран индекс можем да приемем, че стойностите за основния ред са в индекса
- 20+ търсения на диапазон (надявам се в индекс) за pk стойността на обекта
- Това вероятно не са клъстерирани индекси, така че същите 20+ търсения на данни, след като разберем кои са подходящите дъщерни редове.
Така че общата сума за mysql, дори ако приемем, че всички индекси са в паметта (което е по-трудно, тъй като има 20 пъти повече от тях) е около 20 търсения на диапазон.
Тези търсения на диапазон вероятно се състоят от произволно IO - различни таблици определено ще се намират на различни места на диска и е възможно различни редове в същия диапазон в една и съща таблица за обект да не са съседни (в зависимост от това как обектът е бил актуализирани и др.).
Така че за този пример крайният резултат е около 20 пъти повече IO с MySQL на логически достъп, в сравнение с MongoDB.
Ето как MongoDB може да повиши производителността в някои случаи на употреба .
