Błędy
Prędkość
Nawet jeśli nie mówimy o indeksie wielokluczowym, oto co się dzieje. Trwa ogromne skanowanie tabeli. Tak więc mongoDB iteruje po dokumentach, próbuje znaleźć pole do indeksowania, ocenia to pole (do null jeśli nie istnieje w bieżącym dokumencie) i zapisuje swoje wyniki w nie mniej niż 6 plikach, ponieważ mówimy o 6 indeksach. Obliczenie:200.000.000 / 86400 * 5 mówi nam, że mongoDB robi to dla około 460 dokumentów na sekundę lub potrzebuje tylko 2,2 milisekundy na dokument . Nie nazwałbym tego powolnym. Może to potrwać długo, ale nie jest wolne.
{background:true}
Użycie tego parametru nie zablokować cię z baz danych. Wręcz przeciwnie, co jest jasno określone w dokumentacji, zarówno na stronie Sekcja tworzenia indeksu oraz w sekcji samouczka na temat tworzenia indeksów w tle . Istnieje jednak zdanie, które łatwo można błędnie zinterpretować:
Oznacza to, że nie możesz wykonywać operacji, które dotyczą wszystkich baz danych i wymagają blokady odczytu lub zapisu.
Sposoby poprawy (w przyszłości)
Klaster podzielony
Użyj udostępnionego klastra z fragmentami zestawu replik. Jest łatwy w konfiguracji i ma wiele zalet poza poprawioną wydajnością. Jednym z nich jest łatwa skalowalność, dodanie fragmentu (a tym samym dodanie przestrzeni i mocy obliczeniowej do klastra) jest bardzo łatwo. Kopie zapasowe mają mniejszy wpływ na aplikację. Nie ma już pojedynczego punktu awarii (gdy zostanie to zrobione prawidłowo, dotyczy to nawet przestojów w skali całego centrum danych).
Użyj innego systemu plików
Przepraszamy, uruchamianie aplikacji zależnej od wydajności we/wy dysku na Windows Server nie ma dla mnie sensu – w ogóle. ExtFS4 lub XFS są od 25% do 40% szybsze niż NTFS lub ReFS, w zależności od optymalizacji. To sprawia, że prawdziwe różnica w aplikacjach, które są tak zależne od dysku we/wy, jak Twój przypadek użycia. Mówimy o kilku dniach (nawet nie biorąc pod uwagę wydajniejszego mapowania pamięci i zmniejszonego zużycia pamięci przez system operacyjny w systemach Linux).
{background:true}
Chociaż tak naprawdę nie poprawia to wydajności (w rzeczywistości budowanie indeksów w tle trwa dłużej niż na pierwszym planie z oczywistych powodów), aplikacja pozostaje dostępna w czasie, w którym budowany jest indeks. Więc w zależności od Twoich potrzeb, może to być realna opcja.
Uwaga boczna :to zły pomysł™ , aby skalować w pionie podczas korzystania z mongoDB, ponieważ został on wyraźnie zaprojektowany do skalowania w poziomie. Dotyczy to szczególnie dużych kolekcji, takich jak Twoja, ponieważ przetwarzanie równoległe znacznie poprawiłoby wydajność Twojej aplikacji.
