Ten artykuł został napisany przez Andrew Morgan z MongoDB.

Od czasu do czasu biorę udział wDesign przegląddla aplikacji migrującej z relacyjnej bazy danych do MongoDB, gdzie klient udostępnia diagram architektoniczny pokazujący warstwę pamięci podręcznej (zazwyczaj Redis) siedzącą między serwerem aplikacji a MongoDB.

Lubię utrzymywać architekturę tak prostą, jak to możliwe – w końcu każda warstwa niesie ze sobą własną złożoność i koszty zarządzania – więc zapytam, dlaczego warstwa pamięci podręcznej istnieje.

Jeszcze nie skończyłem przeglądu projektu bez zalecania usunięcia poziomu pamięci podręcznej.

Tak więc, aby odpowiedzieć na pytanie w tytule tego artykułu - kiedy powinieneś używać pamięci podręcznej z MongoDB? - odpowiedź prawdopodobnie nigdy. Ten artykuł próbuje wyjaśnić, dlaczego, ale jeśli dotrzesz do końca i nadal uważasz, że twoja aplikacja go potrzebuje, to chciałbym z tobą omówić twoją aplikację.

Dlaczego wymyślono pamięci podręcznej, takie jak Memcached & Redis, i dlaczego rozwijają się?

Warstwy pamięci podręcznej zostały wprowadzone, ponieważ były zbyt powolne, aby aplikacje mogły odczytywać wymagane dane bezpośrednio z bazy danych relacyjnych.

Czy to oznacza, że nie ma inteligentnych deweloperów pracujących na Oracle, DB2, Postgres, MySQL itp.? Dlaczego ci deweloperzy nie mogli szybko tworzyć relacyjnych baz danych?

Problem polega na tym, że aplikacja rzadko musi odczytywać tylko jeden rekord z normalizowanej relacyjnej bazy danych. Zamiast tego zazwyczaj musi wykonać wiele połączeń w wielu tabelach, aby utworzyć jeden obiekt biznesowy. Te połączenia są drogie (są powolne i zużywają wiele zasobów). Z tego powodu aplikacja nie chce ponosić tych kosztów za każdym razem, gdy czyta ten sam obiekt biznesowy.

Istnieje również kwestia dystrybucji danych. Większość relacyjnych baz danych została zaprojektowana 50 lat temu, kiedy firma uruchomiła bazę danych i dowolne aplikacje w jednym centrum danych. Szybko do dziś, kiedy przedsiębiorstwa i klienci są rozproszeni na całym świecie, z każdym, kto chce pracować z tymi samymi danymi.

Dostawcy RDBMS próbowali opracować różne rozwiązania do pracy wokół tego, ale są one dalekie od optymalnego.

Należy zauważyć, że Redis i Memcached są szeroko stosowane do obsługi sesji dla aplikacji internetowych, w których wytrwałość nie jest wymogiem. W takim przypadku pamięć podręczna jest jedynym magazynem danych (czyli nie warstwą pamięci podręcznej między aplikacją a MongoDB).

Więc co jest nie tak z posiadaniem caching tier?

Wprowadzenie warstwy pamięci podręcznej jest często świetnym rozwiązaniem, gdy baza danych nie może zapewnić wydajności i opóźnienia, których potrzebuje Twoja aplikacja.

Jednak ten dodatkowy poziom danych wiąże się z kosztami, a oczywistymi są licencje na oprogramowanie i sprzęt wymagane do świadczenia usługi pamięci podręcznej.

Mniej oczywiste jest dodatkowe obciążenie dla programistów. Jest to nowy język zapytań (i ewentualnie język programowania) do opanowania. Co się dzieje, gdy dane w RDBMS się zmieniają?

Tak więc poziom pamięci podręcznej musi zapłacić swoją drogę, dostarczając namacalnych korzyści z bezpośredniego dostępu aplikacji do bazy danych.

Czym się różni od MongoDB?

oMongoDB document model.

W MongoDB chcemy, aby Twoje dane były przechowywane w sposób, który umożliwia szybkie zaspokajanie najczęstszych zapytań Twojej aplikacji (lub tych z najtrudniejszymi SLA). MongoDB odzwierciedla strukturę obiektów, pozwalając jednemu rekordowi (dokumentowi) zawierać obiekty osadzone.

W wielu przypadkach obiekt biznesowy wymagany przez aplikację zostanie skopiowany do pojedynczego dokumentu MongoDB. W innych przypadkach może wymagać wielu dokumentów, które można odebrać za pomocą pojedynczego, indeksowanego wyszukiwania.

MongoDB ma własną wewnętrzną pamięć podręczną LRU (najpóźniej używana), więc jeśli Twój dokument został niedawno dostępny, prawdopodobnie jest już w pamięci.

Pamiętaj, że MongoDB obsługujeZjednoczone, ale staramy się ustrukturyzować Twoje dane, aby zminimalizować ich wykorzystanie.

Inną wartością dodaną z warstwy pamięci podręcznej jest lokalizacja danych w rozproszonych architekturach.MongoDB replikacjama jeden węzeł główny, który obsługuje wszystkie pisma, wraz z maksymalnie 49 węzłami wtórnymi — każdy z kopią danych. Dla zapytań o najniższą opóźnienie, można umieścić węzły wtórne lokalnie w każdej z lokalizacji serwera aplikacji. MongoDB jest odpowiedzialny za utrzymanie danych w węzłach wtórnych na bieżąco z głównym, więc nie trzeba pisać i utrzymywać żadnego dodatkowego kodu synchronizacji.

O czym myśli AI?

Odpowiedzi generowane przez generującą sztuczną inteligencję są napędzane informacjami opublikowanymi przez prawdziwych ludzi, a więc powinny one reprezentować opinię publiczną na temat.

Zadałem ChatGPT 4o to pytanie:

Wyjaśnij, dlaczego użyłbym warstwy pamięci podręcznej (takiej jak Redis) zamiast, aby moja aplikacja czytała dane bezpośrednio z MongoDB.

Redis działa całkowicie w pamięci, co czyni go znacznie szybszym niż MongoDB, który opiera się na dysku I/O do odzyskiwania danych.

Wyjaśnij, dlaczego użyłbym warstwy pamięci podręcznej (takiej jak Redis) zamiast, aby moja aplikacja czytała dane bezpośrednio z MongoDB.

Redis działa całkowicie w pamięci, co czyni go znacznie szybszym niż MongoDB, który opiera się na dysku I/O do odzyskiwania danych.

Jak opisano powyżej, MongoDB ma własną pamięć podręczną, więc dokumenty, do których często uzyskujesz dostęp, będą w pamięci, a dostęp do dysku nie jest wymagany.

Częste uzyskanie dostępu do MongoDB bezpośrednio dla tych samych danych zwiększa obciążenie zapytaniami, co może spowolnić bazę danych, szczególnie w przypadku dużego ruchu do odczytu.

Częste uzyskanie dostępu do MongoDB bezpośrednio dla tych samych danych zwiększa obciążenie zapytaniami, co może spowolnić bazę danych, szczególnie w przypadku dużego ruchu do odczytu.

MongoDB jest skalowalny. Dodatkowe wtórne węzły można dodać do zestawu repliki, aby dodać dodatkową przepustowość zapytań.Sharding MongoDB(Partycjonowanie) może skalować pojemność danych lub zapisać przepustowość poziomo.

Aplikacje o wysokim współczynniku odczytu do pisania (np. aplikacje internetowe, API) korzystają ze zdolności Redis do szybkiego obsługi danych w pamięci podręcznej.

Aplikacje o wysokim współczynniku odczytu do pisania (np. aplikacje internetowe, API) korzystają ze zdolności Redis do szybkiego obsługi danych w pamięci podręcznej.

Cache bazy danych MongoDB zapewnia te same korzyści bez dodatkowego wysiłku dewelopera, aby zsynchronizować zmiany danych.

„Szybszy dostęp do często używanych danych. Redis jest idealny do przechowywania w pamięci podręcznej często dostępnych lub gorących danych (np. sesji użytkownika, konfiguracji lub szczegółów produktu).”

„Szybszy dostęp do często używanych danych. Redis jest idealny do przechowywania w pamięci podręcznej często dostępnych lub gorących danych (np. sesji użytkownika, konfiguracji lub szczegółów produktu).”

Często dostępne, gorące dane będą przechowywane w pamięci podręcznej bazy danych MongoDB.

Poprzez kopiowanie pamięci podręcznej Redis bliżej użytkowników końcowych można uniknąć wysokiego opóźnienia sieciowego podczas kwerendowania MongoDB z odległych lokalizacji.

Poprzez kopiowanie pamięci podręcznej Redis bliżej użytkowników końcowych można uniknąć wysokiego opóźnienia sieciowego podczas kwerendowania MongoDB z odległych lokalizacji.

Lokalizację danych można rozwiązać, umieszczając repliki w pobliżu witryn serwera aplikacji.

Redis ma wbudowaną funkcję Time-to-Live (TTL), która automatycznie usuwa dane w pamięci podręcznej po określonym czasie.

Redis ma wbudowaną funkcję Time-to-Live (TTL), która automatycznie usuwa dane w pamięci podręcznej po określonym czasie.

MongoDB używa pamięci podręcznej LRU, więc wszelkie dokumenty, które nie są już kwestionowane, zostaną usunięte z pamięci, jeśli miejsce jest potrzebne dla ostatnio kwestionowanych danych.Indeksy TTLJeśli chcesz usunąć dokumenty z bazy danych całkowicie lubAtlas Online ArchiwumJeśli chcesz przenieść je do tańszego przechowywania.

Czytanie z MongoDB wielokrotnie może być wymagające zasobów, szczególnie w przypadku złożonych zapytań, co prowadzi do zwiększenia kosztów infrastruktury.

Czytanie z MongoDB wielokrotnie może być wymagające zasobów, szczególnie w przypadku złożonych zapytań, co prowadzi do zwiększenia kosztów infrastruktury.

Schemat MongoDB powinien być zaprojektowany tak, aby ważne zapytania nie wymagały złożonych zapytań.

Redis obsługuje zaawansowane struktury danych, takie jak listy, zestawy, sortowane zestawy, hasze i strumienie, których MongoDB nie dostarcza natywnie.

Redis obsługuje zaawansowane struktury danych, takie jak listy, zestawy, sortowane zestawy, hasze i strumienie, których MongoDB nie dostarcza natywnie.

MongoDB obsługuje listy i zestawy.Hasze można reprezentować w MongoDB jako zestaw dokumentów zawierających pary wartości klucza (pary wartości klucza).Wzór atrybutów MongoDB) wZbiory serii czasu MongoDBspełniają te same potrzeby, jak strumienie Redis.

Warstwa pamięci podręcznej może służyć jako backup, jeśli MongoDB jest tymczasowo niedostępny lub pod dużym obciążeniem.

Warstwa pamięci podręcznej może służyć jako backup, jeśli MongoDB jest tymczasowo niedostępny lub pod dużym obciążeniem.

MongoDB może skalować pionowo lub poziomo, aby spełnić wszelkie wymagania dotyczące obciążenia.Skala może być zautomatyzowana przy użyciu atlasu MongoDBZestawy repliki MongoDB zapewniają tolerancję błędów zarówno dla czytania, jak i pisania.

MongoDB może zająć trochę czasu, aby obliczyć złożone zapytania (np. agregacje, połączenia) dla często żądanych wyników.

MongoDB może zająć trochę czasu, aby obliczyć złożone zapytania (np. agregacje, połączenia) dla często żądanych wyników.

Twój schemat MongoDB powinien być zaprojektowany tak, aby uniknąć potrzeby częstego uruchamiania złożonych zapytań.MongoDB z materializowaną wizją, unikając konieczności wielokrotnego wykonywania tego samego złożonego zapytania / agregacji.

Jeśli zmienię swoją prośbę na „Wyjaśnij, dlaczego nie powinienem używać warstwy pamięci podręcznej (takiej jak Redis) zamiast mieć moją aplikację czytać dane z MongoDB bezpośrednio”, ChatGPT jest szczęśliwy, aby odstraszyć mnie od dodawania warstwy pamięci podręcznej, cytując problemy, takie jak zwiększona złożoność systemu, problemy z spójnością danych, wydajność dla ciężkich obciążeń roboczych, koszty, elastyczność zapytań, konserwacja i niezawodność, małe zestawy danych (gdzie aktywny zestaw danych pasuje do pamięci podręcznej MongoDB) i raportowanie w czasie rzeczywistym.

Podsumowanie

Warstwa pamięci podręcznej może dodać wiele wartości, gdy RDBMS nie może dostarczyć wydajności zapytań wymaganych przez aplikację. Podczas korzystania z MongoDB, baza danych rekordów i funkcji pamięci podręcznej jest połączona w jednej warstwie, oszczędzając pieniądze i czas programisty.

Rozproszona pamięć podręczna może złagodzić braki w systemie RDBMS, ale MongoDB ma wbudowaną dystrybucję.

Odpowiedz na ten artykuł, jeśli nadal uważasz, że twoja aplikacja skorzysta z warstwy pamięci podręcznej między twoją aplikacją a MongoDB.

Dowiedz się więcej na temat recenzji projektu MongoDB

Design Recenzjesą szansą dla eksperta projektowania z MongoDB, aby doradzić Ci, jak najlepiej korzystać z MongoDB dla Twojej aplikacji. Recenzje koncentrują się na powodzeniu korzystania z MongoDB. Nigdy nie jest za wcześnie, aby poprosić o recenzję.

W tym artykule wyjaśniono, jak projektowanie schematu MongoDB, który pasuje do sposobu pracy aplikacji z danymi, może spełniać wymagania dotyczące wydajności bez konieczności posiadania warstwy pamięci podręcznej.

Czy Twoja aplikacja skorzysta z przeglądu?Schedule your design review.