Nauka MongoDB wymaga dużo precyzyjnego myślenia. Niewiele uwagi poświęca się często w przypadku istotnych przedsięwzięć, które w przeciwnym razie mogłyby zagrozić wydajności bazy danych w trybie produkcyjnym.
MongoDB to system DBMS NoSQL, który dosłownie ma inny wzorzec niż bazy danych SQL, szczególnie pod względem bezpieczeństwa i struktury. Chociaż niektóre zintegrowane funkcje zwiększają jego wydajność i sprawiają, że jest to jedna z najlepszych w ostatnich czasach, niektóre z nich w konsekwencji stwarzają potencjalne zagrożenia, które mogą zrujnować jego wydajność, jeśli nie zostaną wzięte pod uwagę.
W ostatnim „najgorszym przypadku” próbowałem wysłać zapytanie do kolekcji z dokumentami, które miały duże tablice, a odzyskanie wyników zajęło mi wieki. Postanowiłem napisać tego bloga, ponieważ wiedziałem, że jeśli ktoś doświadcza tych samych problemów, ten blog będzie bardzo pomocny.
Kluczowe kwestie dotyczące MongoDB w produkcji
- Bezpieczeństwo i uwierzytelnianie.
- Indeksowanie dokumentów
- Korzystanie ze schematu w swoich kolekcjach
- Kolekcja ograniczona
- Rozmiar dokumentu
- Rozmiar tablicy dla osadzonych dokumentów
- Etapy potoku agregacji
- Kolejność kluczy w obiekcie mieszającym
- „undefined” i „null” w MongoDB
- Operacja zapisu
Bezpieczeństwo i uwierzytelnianie MongoDB
Dane różnią się na wiele sposobów i oczywiście będziesz musiał zachować poufność niektórych informacji. Domyślnie instalacje MongoDB nie ustawiają wymogu uwierzytelnienia jako konieczności, ale to nie daje możliwości korzystania z niego, zwłaszcza gdy w grę wchodzą poufne dane, takie jak dokumentacja finansowa i medyczna. Na rozwojowej stacji roboczej nie jest to wielka sprawa, ale ze względu na zaangażowanie wielu użytkowników w trybie produkcyjnym, dobrą praktyką jest ustawianie certyfikatów uwierzytelniających. Najpopularniejszą i najłatwiejszą w użyciu metodą jest domyślna nazwa użytkownika i hasło MongoDB.
Dane są zapisywane w plikach, do których można uzyskać dostęp za pomocą narzędzi innych firm, co więcej, jeśli nie są one zaszyfrowane. Dane mogą zostać zmienione bez Twojej wiedzy, jeśli jakaś anonimowa osoba uzyska dostęp do plików systemowych. Hostowanie bazy danych na serwerze dedykowanym i przypisanie jednego użytkownika, który będzie miał pełny dostęp do plików danych, pozwoli Ci zaoszczędzić.
Ochrona danych przed zewnętrznymi atakami wstrzykiwania jest również istotnym przedsięwzięciem. Niektóre operatory, takie jak $group, $whereby i operacje mapReduce, są opracowane w javascript(js), dlatego są podatne na manipulacje js. Aby uniknąć jakiegokolwiek przypadku integralności danych w rezultacie, możesz wyłączyć dowolne ustawienie JS, konfigurując parametr javascriptEnabled:false w pliku konfiguracyjnym, jeśli nie użyłeś żadnego z wymienionych operatorów. Co więcej, możesz zmniejszyć ryzyko dostępu do danych z powodu naruszeń sieci, stosując niektóre procedury wyszczególnione na liście kontrolnej bezpieczeństwa MongoDB.
Indeksowanie dokumentów
Indeksowanie polega na przypisaniu każdemu dokumentowi w kolekcji MongoDB unikalnej wartości identyfikacyjnej. Indeksowanie zapewnia zwiększenie wydajności zarówno w operacjach odczytu, jak i zapisu. Domyślnie jest włączony i zawsze należy zachować to ustawienie. Bez indeksowania baza danych musi sprawdzać wiele dokumentów od początku do końca i niestety operacja ta będzie czasochłonna w przypadku dokumentów, które są pod koniec, powodując niewielkie opóźnienie zapytania. W pewnym momencie po zakończeniu aplikacji użytkownicy mogą doświadczyć opóźnienia i mogą pomyśleć, że aplikacja faktycznie nie działa. Indeksowanie jest pomocne w operacjach sortowania i wyszukiwania zapytań, nie pomijając samej operacji wyszukiwania. Sortowanie to powszechna operacja w przypadku wielu zwracanych dokumentów. Często jest wykonywany jako ostatni etap po przefiltrowaniu dokumentów, tak aby trzeba było posortować niewielką ilość danych. Indeks w tym przypadku pomoże posortować dane w charakterze wpisu i ograniczyć zwracane dane do limitu 32 MB. Jeśli nie ma indeksowania, szanse na przekroczenie limitu 32 pamięci na łączny rozmiar zwracanych dokumentów zostaną przekroczone, a za każdym razem, gdy baza danych osiągnie ten limit, wygeneruje błąd oprócz zwrócenia pustego zestawu rekordów.
Operacja $lookup jest również obsługiwana z indeksowaniem w miejscu. Indeks wartości klucza używany jako klucz obcy jest niezbędny do przetwarzania poprzednich etapów.
Korzystanie ze schematu w swoich kolekcjach
MongoDB nie wymaga definiowania pól (kolumn), tak jak może to wymagać w przypadku baz danych SQL. Jakkolwiek nie będziesz musiał definiować pól, aby uniknąć niespójności danych i pewnych komplikacji, które mogą się pojawić, definiowanie schematu jest zawsze dobrą praktyką. Projekt schematu pozwala określić, jaki typ danych trafia do określonego pola, do którego pola należy podać wartość i ogólnie poprawia walidację danych przed wprowadzeniem lub aktualizacją, promując w ten sposób integralność i spójność danych. Projekt schematu wskaże Ci również, czy odwoływać się, czy osadzić dane. Jako początkujący możesz pomyśleć, że jedynym modelem będzie „jeden do N”, który ułatwi posiadanie wpisów w tablicy poddokumentów, ale tak nie jest.
Musisz zrozumieć relację kardynalności między dokumentami przed utworzeniem modelu. Oto niektóre z reguł, które pomogą Ci stworzyć optymalny schemat:
- Aby zmniejszyć liczbę zapytań, które będziesz musiał wykonać przed uzyskaniem dostępu do niektórych danych, a jeśli zaangażowanych jest niewiele pól lub elementów tablicy, możesz osadzić dokumenty podrzędne. Weź przykładowy model poniżej:
-
{ Name: ‘John Doh’, Age:20 Addresses:[ {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’}, {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’}, ] }
-
- W przypadku często aktualizowanych dokumentów użyj denormalizacji . Jeśli jakieś pole będzie często aktualizowane, to będzie zadanie odnalezienia wszystkich instancji, które wymagają aktualizacji. Spowoduje to powolne przetwarzanie zapytań, a zatem przytłacza nawet zalety związane z denormalizacją.
- Złożone zapytania, takie jak agregacja potoków, wymagają więcej czasu na wykonanie, gdy zaangażowanych jest wiele dokumentów podrzędnych i istnieje potrzeba oddzielnego pobrania dokumentu.
- Elementy tablicy z dużym zestawem danych obiektowych nie powinny być oczywiście osadzane ze względu na fakt, że mogą rosnąć, a w konsekwencji przekraczać rozmiar dokumentu.
Modelowanie schematu jest często określane przez wzorzec dostępu aplikacji. Więcej procedur, które mogą pomóc w projektowaniu Twojego modelu, znajdziesz na blogu 6 zasad dotyczących projektowania schematów MongoDB
Użyj ograniczonej kolekcji dla priorytetu ostatnich dokumentów
MongoDB zapewnia wiele zasobów, takich jak kolekcja z ograniczeniami. Niestety niektóre z nich nie są wykorzystywane. Ograniczona kolekcja ma stały rozmiar i jest znana z obsługi operacji o wysokiej przepustowości, które wstawiają i pobierają dokumenty na podstawie kolejności wstawiania. Po zapełnieniu miejsca stare dokumenty są usuwane, aby zrobić miejsce na nowe.
Przykład przypadku użycia kolekcji ograniczonej:
- Buforowanie często używanych danych, ponieważ sama kolekcja jest obciążona odczytem, a nie zapisem. Musisz upewnić się, że kolekcja jest zawsze wydajna.
- Informacje z dziennika dla systemów o dużej objętości. Ograniczone zbiory często nie używają indeksu, co jest korzystne, ponieważ prędkość nagrywania jest dość duża, podobnie jak zapisywanie do pliku.
Zwróć uwagę na rozmiar dokumentu MongoDB
Każdy dokument MongoDB jest ograniczony do 16 megabajtów. Jednak optymalne jest, aby dokument osiągnął lub zbliżył się do tego limitu, ponieważ spowoduje to okropne problemy z wydajnością. Sam MongoDB działa najlepiej, gdy rozmiar dokumentów wynosi kilka kilobajtów. Jeśli dokument ma wystarczająco duży rozmiar, złożone żądanie projekcji zajmie dużo czasu, a zapytanie może wygasnąć.
Zwróć uwagę na rozmiar tablicy osadzonych dokumentów
Dokumenty podrzędne można wepchnąć do pola w dokumencie, tworząc w ten sposób wartość tablicy w tym polu. Jak wspomniano wcześniej, rozmiar poddokumentów powinien być niski. Równie ważne jest, aby liczba elementów tablicy była mniejsza niż cztery cyfry. W przeciwnym razie dokument przekroczy swój rozmiar i będzie musiał zostać przeniesiony na dysk. Kolejnym problemem związanym z taką operacją jest to, że każdy dokument będzie musiał zostać ponownie zindeksowany. Poza tym każdy dokument podrzędny w równym stopniu będzie musiał zostać ponownie zindeksowany. Oznacza to, że będzie dużo zapisów indeksu, które spowalniają operacje. W przypadku dużego rozmiaru dokumentu podrzędnego raczej ważne jest, aby zachować zapisy w nowej kolekcji niż osadzić.
Etapy potoku agregacji
Oprócz normalnych operacji zapytań MongoDB, istnieje struktura agregacji używana do manipulowania i zwracania danych zgodnie z pewnymi specyfikacjami, takimi jak porządkowanie i grupowanie. MongoDB nie posiada optymalizatora zapytań, dlatego jest on potrzebny do odpowiedniego uporządkowania zapytań. Dzięki ramom agregacji upewnij się, że etapy potoku są dobrze uporządkowane. Zacznij od zmniejszenia ilości danych, z którymi masz do czynienia, używając operatora $match i ewentualnie $sort na końcu, jeśli zajdzie potrzeba sortowania. Możesz użyć narzędzi innych firm, takich jak Studio 3T, aby zoptymalizować zapytanie agregujące przed zintegrowaniem go z kodem. Narzędzie pozwala zobaczyć dane wejściowe i wyjściowe na dowolnym etapie, dzięki czemu wiesz, z czym masz do czynienia.
Używanie $limit i $sort powinno zawsze dawać te same wyniki za każdym razem, gdy zapytanie jest wykonywane. W przypadku użycia $limit zwrócone dane nie będą deterministyczne i mogą powodować problemy, które są trudne do śledzenia.
Sprawdź kolejność kluczy w obiektach haszujących
Rozważ posiadanie dwóch dużych dokumentów z przykładowymi danymi
{
FirstName: ‘John’,
LastName: ‘Doh’
}Jeśli wykonasz operację wyszukiwania z zapytaniem {FirstName:'John', LastName:'Doh'}, operacja nie pasuje do zapytania {LastName:'Doh' FirstName:'John' }. Dlatego musisz zachować kolejność par nazw i wartości w swoich dokumentach.
Unikaj „nieokreślonych” i „null” w MongoDB
MongoDB używa formatu BSON dla swoich dokumentów. W przypadku walidacji JSON „nieokreślony” nie jest obsługiwany i należy go unikać. Rozwiązaniem jest $null, ale należy go również unikać.
Rozważ operacje zapisu
Możesz ustawić MongoDB na szybkie zapisy, ale powoduje to niepowodzenie, ponieważ odpowiedź jest zwracana nawet przed zapisaniem danych. Kronikowanie powinno być włączone, aby uniknąć tego scenariusza. Dodatkowo, w przypadku awarii bazy danych, dane będą nadal dostępne i stworzą punkt kontrolny, który będzie można wykorzystać w procesie odzyskiwania. Konfigurację czasu trwania zapisów do dziennika można ustawić za pomocą parametru commitIntervalMs.
Wnioski
System baz danych powinien zapewniać integralność i spójność danych, oprócz odporności na awarie i złośliwość. Jednak, aby dojść do tych czynników, należy zrozumieć samą bazę danych i dane, które przechowuje. MongoDB sprawdzi się dobrze, jeśli weźmiemy pod uwagę powyższe czynniki. Najważniejsze, że używają schematu. Schemat umożliwia sprawdzenie poprawności danych przed wprowadzeniem lub aktualizacją oraz sposób modelowania tych danych. Modelowanie danych jest często oparte na wzorcu ułatwień dostępu aplikacji. Wszystkie te zsumowane zapewnią lepszą wydajność bazy danych.
