Jedną z najbardziej reklamowanych cech MongoDB jest jego zdolność do bycia „bez schematu”. Oznacza to, że MongoDB nie narzuca żadnego schematu żadnym dokumentom przechowywanym w kolekcji. Zwykle MongoDB przechowuje dokumenty w formacie JSON, więc każdy dokument może przechowywać różne rodzaje schematów/struktur. Jest to korzystne na początkowych etapach opracowywania, ale na późniejszych etapach możesz chcieć wymusić walidację schematu podczas wstawiania nowych dokumentów w celu uzyskania lepszej wydajności i skalowalności. Krótko mówiąc, „Bez schematu” nie oznacza, że nie musisz projektować swojego schematu. W tym artykule omówię kilka ogólnych wskazówek dotyczących planowania schematu MongoDB.
Ustalenie najlepszego projektu schematu, który pasuje do twojej aplikacji, może czasami być nużące. Oto kilka punktów, które możesz wziąć pod uwagę podczas projektowania schematu.
Unikaj rosnących dokumentów
Jeśli twój schemat pozwala na tworzenie dokumentów, których rozmiar stale rośnie, powinieneś podjąć kroki, aby tego uniknąć, ponieważ może to prowadzić do obniżenia wydajności DB i dysku we/wy. Domyślnie MongoDB pozwala na rozmiar 16 MB na dokument. Jeśli rozmiar twojego dokumentu zwiększy się o więcej niż 16 MB na przestrzeni czasu, jest to oznaką złego projektu schematu. Czasami może to prowadzić do niepowodzenia zapytań. Aby uniknąć takiej sytuacji, możesz użyć zasobników na dokumenty lub technik wstępnej alokacji dokumentów. Jeśli Twoja aplikacja musi przechowywać dokumenty o rozmiarze większym niż 16 MB, możesz rozważyć użycie MongoDB GridFS API.
Unikaj aktualizacji całych dokumentów
Jeśli spróbujesz zaktualizować cały dokument, MongoDB przepisze cały dokument w innym miejscu pamięci. Może to drastycznie obniżyć wydajność zapisu bazy danych. Zamiast aktualizować cały dokument, możesz użyć modyfikatorów pól, aby zaktualizować tylko określone pola w dokumentach. Spowoduje to aktualizację na miejscu w pamięci, a tym samym lepszą wydajność.
Staraj się unikać łączeń na poziomie aplikacji
Jak wszyscy wiemy, MongoDB nie obsługuje złączeń na poziomie serwera. Dlatego musimy pobrać wszystkie dane z DB, a następnie wykonać łączenie na poziomie aplikacji. Jeśli pobierasz dane z wielu kolekcji i łączysz dużą ilość danych, musisz kilkakrotnie wywoływać DB, aby uzyskać wszystkie potrzebne dane. Będzie to oczywiście wymagało więcej czasu, ponieważ dotyczy sieci. Jako rozwiązanie dla tego scenariusza, jeśli aplikacja w dużym stopniu opiera się na sprzężeniach, denormalizacja schematu ma większy sens. Możesz użyć osadzonych dokumentów, aby uzyskać wszystkie wymagane dane w jednym wywołaniu zapytania.
Stosuj prawidłowe indeksowanie
Podczas wyszukiwania lub agregacji często sortuje się dane. Mimo że stosujesz się do sortowania na ostatnim etapie potoku, nadal potrzebujesz indeksu, aby pokryć sortowanie. Jeśli indeks w polu sortowania nie jest dostępny, MongoDB jest zmuszony do sortowania bez indeksu. Istnieje limit pamięci wynoszący 32 MB całkowitego rozmiaru wszystkich dokumentów, które są zaangażowane w operację sortowania. Jeśli MongoDB osiągnie ten limit, może spowodować błąd lub zwrócić pusty zestaw.
Po omówieniu dodawania indeksów ważne jest również, aby nie dodawać zbędnych indeksów. Każdy indeks, który dodasz w bazie danych, musisz zaktualizować wszystkie te indeksy podczas aktualizacji dokumentów w kolekcji. Może to obniżyć wydajność bazy danych. Ponadto każdy indeks zajmie trochę miejsca i pamięci, więc liczba indeksów może prowadzić do problemów związanych z przechowywaniem.
Jeszcze jednym sposobem na zoptymalizowanie użycia indeksu jest zastąpienie domyślnego pola _id. Jedynym celem tego pola jest zachowanie jednego unikalnego pola na dokument. Jeśli Twoje dane zawierają znacznik czasu lub dowolne pole identyfikatora, możesz zastąpić pole _id i zapisać jeden dodatkowy indeks.
Kilkadziesiąt — Zostań administratorem baz danych MongoDB — wprowadzenie MongoDB do produkcjiDowiedz się, co trzeba wiedzieć, aby wdrażać, monitorować, zarządzać i skalować MongoDB. Pobierz za darmoWspółczynnik odczytu vs zapisu
Projektowanie schematu dla dowolnej aplikacji w dużej mierze zależy od tego, czy aplikacja jest intensywnie odczytywana, czy intensywnie zapisywana. Na przykład, jeśli tworzysz pulpit nawigacyjny do wyświetlania danych szeregów czasowych, powinieneś zaprojektować schemat w taki sposób, aby zmaksymalizować przepustowość zapisu. Jeśli Twoja aplikacja jest oparta na e-commerce, większość operacji będzie polegała na operacjach odczytu, ponieważ większość użytkowników będzie przeglądać wszystkie produkty i przeglądać różne katalogi. W takich przypadkach powinieneś użyć zdenormalizowanego schematu, aby zmniejszyć liczbę wywołań DB w celu uzyskania odpowiednich danych.
Typy danych BSON
Upewnij się, że podczas projektowania schematu poprawnie zdefiniowałeś typy danych BSON dla wszystkich pól. Ponieważ kiedy zmienisz typ danych dowolnego pola, MongoDB przepisze cały dokument w nowej przestrzeni pamięci. Na przykład, jeśli spróbujesz zapisać (int)0 w miejscu (float)0.0, MongoDB przepisze cały dokument pod nowym adresem ze względu na zmianę typu danych BSON.
Wniosek
Krótko mówiąc, mądrze jest zaprojektować schemat bazy danych Mongo, ponieważ poprawi to tylko wydajność Twojej aplikacji. Począwszy od wersji 3.2, MongoDB zaczął wspierać walidację dokumentów, gdzie można określić, które pola są wymagane do wstawienia nowego dokumentu. Od wersji 3.6 MongoDB wprowadził bardziej elegancki sposób wymuszania walidacji schematu przy użyciu walidacji schematu JSON. Korzystając z tej metody walidacji, możesz wymusić sprawdzanie typu danych wraz z wymaganym sprawdzaniem pól. Możesz użyć powyższych podejść, aby sprawdzić, czy wszystkie dokumenty używają tego samego typu schematu, czy nie.
