PostgreSQL maksymalizuje wydajność SSD


19

Będę miał ogromną bazę danych PostgreSQL 9.3 z wieloma tabelami z ponad 100 milionami wpisów na tabelę. Ta baza danych będzie w zasadzie tylko do odczytu (po wypełnieniu wszystkich niezbędnych tabel i utworzeniu indeksów nie będzie więcej operacji zapisu na bazie danych) oraz dostęp dla jednego użytkownika (uruchamianie i porównywanie wielu zapytań z hosta lokalnego), ponieważ baza danych będzie używana tylko do celów badawczych. Kwerendy zawsze będą używać JOIN na liczbach całkowitych pól DB.

Prawdopodobnie kupię do tego celu dysk SSD (256-512 GB). Nie korzystałem wcześniej z dysku SSD dla bazy danych, więc jest coś, czego powinienem się bać? Czy mogę umieścić całą bazę danych na dysku SSD, czy tylko indeksy? Czy do tuningu PostgreSQL dla dysków SSD wymagana jest jakaś konkretna rada / samouczek? Zauważ, że mam dobrą stację roboczą z i7 i 32 GB pamięci RAM, więc być może możesz tam również udzielić porady.

Odpowiedzi:


16

więc jest coś, czego powinienem się bać?

Brak kopii zapasowych. Jak każde urządzenie pamięci masowej może umrzeć. Przechowuj kopie zapasowe.

Jeśli ładowanie danych zajmie wieki, po wykonaniu ładowania danych utworzę kopię zapasową bazy danych tylko do odczytu, zatrzymując ją i kopiując. W ten sposób, jeśli coś pójdzie nie tak, łatwiej będzie go później odtworzyć.

Czy mogę umieścić całą bazę danych na dysku SSD, czy tylko indeksy?

Jeśli pasuje, zapisz całą bazę danych.

Jeśli tak się nie stanie, umieść przestrzeń dyskową na dysku SSD i użyj jej do przechowywania indeksów oraz tylu tabel, do których istnieje duże zapytanie, ile zmieści się.

Czy do tuningu PostgreSQL dla dysków SSD wymagana jest jakaś konkretna rada / samouczek?

Większość zalet dysków SSD dotyczy obciążeń zapisu OLTP. Główną zaletą dla ładunków tylko do odczytu jest szybkie wyszukiwanie, a slardiere to pokrył.

Możesz chcieć ustawić effective_io_concurrency = 5lub coś w celu odzwierciedlenia faktu, że dyski SSD mogą wykonywać szybkie, mocno potokowe losowe odczyty ... ale wpływa to tylko na skanowanie indeksu bitmap, a w praktyce random_page_costjuż to uwzględnia.

W przypadku obciążenia tylko do odczytu nie robi to żadnej różnicy.

Aby uzyskać wstępne ładowanie danych, zobacz:

Zauważ, że mam dobrą stację roboczą z i7 i 32 GB pamięci RAM, więc być może możesz tam również udzielić porady.

Ustaw duży maintenance_work_memładunek danych. Użyłbym przynajmniej 8GB.

Ustaw duży work_memdla pracy zapytania. Odpowiedni rozmiar zależy nieco od złożoności zapytania. Zacznij od 500MBi idź stamtąd.

Podbij swój checkpoint_segments(masowo) do początkowego ładowania danych.

Pamiętaj, aby wyłączyć overcommit VM! (patrz podręcznik PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )


22

Jeśli chodzi o dyski SSD, główną radą jest obniżenie „random_page_cost” do 1 (równa się „seq_page_cost”) w postgresql.conf, oprócz innych ustawień zwykłych.


Być może obie wartości powinny być mniejsze niż 1,0, zgodnie z postgresql.org/docs/11/… : „Możesz podnieść lub obniżyć obie wartości razem, aby zmienić znaczenie kosztów we / wy dysku w stosunku do kosztów procesora, które są opisane przez następujące parametry ”.
Kirill Bulygin
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.