MongoDB nie jest magicznie szybszy. Jeśli przechowujesz te same dane, zorganizowane w zasadniczo ten sam sposób i uzyskujesz do nich dostęp dokładnie w ten sam sposób, to naprawdę nie powinieneś oczekiwać, że wyniki będą szalenie różne. W końcu zarówno MySQL, jak i MongoDB są na licencji GPL, więc gdyby Mongo miał w sobie jakiś magicznie lepszy kod IO, zespół MySQL mógłby po prostu włączyć go do swojej bazy kodu.
Ludzie widzą wydajność MongoDB w świecie rzeczywistym, głównie dlatego, że MongoDB umożliwia wykonywanie zapytań w inny sposób, który jest bardziej rozsądny dla obciążenia.
Rozważmy na przykład projekt, w którym w znormalizowany sposób zachowano wiele informacji o skomplikowanej jednostce. Może to z łatwością wykorzystać dziesiątki tabel w MySQL (lub dowolnej relacyjnej bazie danych) do przechowywania danych w normalnej formie, z wieloma indeksami potrzebnymi do zapewnienia relacyjnej integralności między tabelami.
Teraz rozważ ten sam projekt z magazynem dokumentów. Jeśli wszystkie te powiązane tabele są podrzędne względem tabeli głównej (i często są), możesz być w stanie zamodelować dane w taki sposób, aby cała jednostka była przechowywana w jednym dokumencie. W MongoDB możesz przechowywać to jako pojedynczy dokument w jednej kolekcji. W tym miejscu MongoDB zaczyna zapewniać najwyższą wydajność.
W MongoDB, aby pobrać całą encję, musisz wykonać:
- Jedno wyszukiwanie indeksu w kolekcji (zakładając, że jednostka jest pobierana przez identyfikator)
- Pobierz zawartość jednej strony bazy danych (rzeczywisty binarny dokument json)
Tak więc przeglądanie b-drzewa i czytanie strony binarnej. Log(n) + 1 IO. Jeśli indeksy mogą znajdować się w całości w pamięci, to 1 we/wy.
W MySQL z 20 tabelami musisz wykonać:
- Jedno wyszukiwanie indeksu w tabeli głównej (ponownie, zakładając, że jednostka jest pobierana przez identyfikator)
- W przypadku indeksu klastrowego możemy założyć, że wartości wiersza głównego znajdują się w indeksie
- Ponad 20 wyszukiwań zakresów (miejmy nadzieję w indeksie) dla wartości pk jednostki
- Prawdopodobnie nie są to indeksy klastrowe, więc te same ponad 20 wyszukiwań danych, gdy ustalimy, jakie są odpowiednie wiersze podrzędne.
Tak więc suma dla mysql, nawet zakładając, że wszystkie indeksy znajdują się w pamięci (co jest trudniejsze, ponieważ jest ich 20 razy więcej) to około 20 wyszukiwań zakresów.
Te wyszukiwania zakresów prawdopodobnie składają się z losowych operacji we/wy — różne tabele z pewnością będą znajdować się w różnych miejscach na dysku i możliwe jest, że różne wiersze w tym samym zakresie w tej samej tabeli dla encji mogą nie być ciągłe (w zależności od tego, jak encja została zaktualizowane itp).
Tak więc w tym przykładzie ostateczna liczba wynosi około 20 razy więcej IO z MySQL na dostęp logiczny w porównaniu z MongoDB.
W ten sposób MongoDB może zwiększyć wydajność w niektórych przypadkach użycia .
