Trzy warstwy pamięci podręcznej pomiędzy wyborem a dyskiem

Kiedy aplikacja uruchamia instrukcję SELECT, zapytanie to prawie nigdy nie dotyka wirującego dysku ani nawet surowej pamięci flash — przechodzi przez trzy odrębne warstwy pamięci podręcznej, które po cichu określają, czy odpowiedź nadejdzie w mikrosekundach, czy w milisekundach. Zrozumienie tych warstw stanowi różnicę między platformą biznesową, która skaluje się bez wysiłku, a platformą, która ugina się pod obciążeniem w świecie rzeczywistym.

Co się stanie w momencie, gdy zapytanie SELECT opuści Twoją aplikację?

W momencie, gdy aplikacja wysyła zapytanie SELECT, wchodzi do potoku, którego większość programistów nigdy nie sprawdza. Silnik bazy danych przechwytuje żądanie przed wystąpieniem jakichkolwiek operacji we/wy, analizując kod SQL w celu uzyskania wewnętrznego planu wykonania i natychmiast sprawdzając swoją pierwszą linię obrony: pamięć podręczną wyników zapytań. Jeśli ostatnio wykonano identyczne zapytanie z identycznymi parametrami, silnik może zwrócić zestaw wyników zapisany w pamięci podręcznej bez dotykania pojedynczej strony danych. Nazywa się to czasem pamięcią podręczną zapytań lub pamięcią podręczną wyników i w przypadku obciążeń wymagających dużej liczby odczytów i małych zapisów — takich jak pulpity nawigacyjne analityczne i moduły raportowania — może całkowicie wyeliminować zdecydowaną większość odczytów dysku.

Najważniejszym spostrzeżeniem jest to, że pamięć podręczna zapytań jest bardzo wrażliwa na mutacje danych. Wszelkie INSERT, UPDATE lub DELETE w tabeli bazowej unieważniają odpowiednie wyniki w pamięci podręcznej. Z tego powodu systemy transakcyjne wymagające dużej liczby zapisów często całkowicie wyłączają pamięć podręczną zapytań i zamiast tego polegają na głębszych warstwach.

Co to jest pula buforów i dlaczego ma ona większe znaczenie, niż myślisz?

Druga warstwa pamięci podręcznej — prawdopodobnie najważniejsza w systemach produkcyjnych — to pula buforów (nazywana buforem współdzielonym w PostgreSQL, pulą buforów InnoDB w MySQL). Jest to obszar pamięci RAM używany przez silnik bazy danych do przechowywania ostatnio otwieranych stron danych. Jeśli zapytanie nie może zostać obsłużone z pamięci podręcznej wyników, przed wykonaniem odczytu dysku silnik sprawdza, czy wymagane strony danych znajdują się już w puli buforów.

Pula buforów działa na zasadzie lokalności czasowej i przestrzennej: dostęp do danych, do których ostatnio uzyskano dostęp, prawdopodobnie będzie możliwy ponownie, a dane przechowywane w pobliżu danych, do których uzyskano dostęp, prawdopodobnie wkrótce zostaną udostępnione. Administratorzy baz danych dostrajają wielkość puli buforów jako jedną z podejmowanych przez siebie decyzji konfiguracyjnych o największym wpływie. Zbyt mała pula buforów powoduje ciągłe wykluczanie stron, powodując zjawisko zwane biciem, w którym system spędza więcej czasu na zarządzaniu błędami w pamięci podręcznej niż na wykonywaniu zapytań.

Kluczowy wniosek: w przypadku większości obciążeń OLTP pula buforów o odpowiedniej wielkości oznacza, że ​​95–99% wszystkich odczytów danych jest obsługiwanych z pamięci RAM. Zbiór roboczy — podzbiór danych, którego faktycznie często dotykają zapytania — jest często znacznie mniejszy niż całkowity rozmiar bazy danych. Dopasowanie puli buforów do zestawu roboczego, a nie całego zestawu danych, to pojedyncza czynność dostrajająca zapewniająca najwyższy zwrot, jaką możesz podjąć.

W jaki sposób pamięć podręczna systemu operacyjnego wypełnia lukę między pamięcią RAM a dyskiem?

Nawet jeśli brakuje puli buforów bazy danych, zapytanie nie jest jeszcze przeznaczone do prawdziwego odczytu dysku. System operacyjny utrzymuje pamięć podręczną stron (zwaną także pamięcią podręczną systemu plików), obszar pamięci RAM zarządzanej przez jądro, który buforuje odczyty i zapisy w urządzeniach blokujących. Kiedy silnik bazy danych żąda strony, której nie ma w puli buforów, jądro systemu operacyjnego sprawdza pamięć podręczną własnej strony przed wydaniem fizycznego polecenia wejścia/wyjścia do kontrolera pamięci masowej.

Ta trzecia warstwa jest w dużej mierze niewidoczna dla twórców aplikacji, ale niezwykle ważna w systemach, w których pula buforów bazy danych jest niewystarczająca. Pamięć podręczna stron systemu operacyjnego jest współdzielona przez wszystkie procesy, więc konkuruje z serwerem aplikacji, serwerem WWW i jakimkolwiek innym oprogramowaniem działającym na tym samym hoście. Na dedykowanych serwerach baz danych konkurencja ta jest minimalna, a pamięć podręczna systemu operacyjnego zapewnia znaczący bufor drugiej szansy. Na współdzielonych hostach lub kontenerach z małymi limitami pamięci pamięć podręczna systemu operacyjnego jest często zbyt mała, aby pomóc.

Która warstwa pamięci podręcznej jest odpowiedzialna za największą wydajność w praktyce?

W rzeczywistych systemach produkcyjnych pula buforów domi

Related Posts

• Mało znane narzędzie do piaskownicy z wiersza poleceń w systemie macOS (2025)
• Kryptograficzna Odyseja DJB: Od Bohatera Kodu do Krytyka Standardów
• Koło Falkirk
• Na Synaju odkryto 1300-letnią kronikę świata