Baza danych 100 terabajtów na PostgreSQL bez dzielenia

Czy realistyczne jest skonfigurowanie bazy danych 100 TB (właściwie około 90 TB) na PostgreSQL bez dzielenia danych między wieloma węzłami? Czy są jakieś historie sukcesu / przykłady podobnych konfiguracji?

database postgresql

— voidlizard
źródło

Wyobrażam sobie, że to zależy od twojego obciążenia pracą. Jak dystrybuowane są dane i w jaki sposób będą one wyszukiwane? Jakiego czasu reakcji potrzebujesz?

— Frank Farmer

Cóż, profil obciążenia można opisać jako częste wstawki (około 50 K na sekundę w szczycie), stosunkowo rzadko wybiera (zakres wierszy według użytkownika i znacznika czasu). Dane mogą być łatwo dzielone / dzielone na partycje przez użytkownika i datę / znacznik czasu

Odpowiedzi:

50 000 zapisów na sekundę, które trzeba wchłonąć, to zwykle więcej niż wyzwanie. Nawet w syntetycznych testach porównawczych z dość prostymi wstawkami limity PostgreSQL mają tendencję do maksymalizacji około około 10 K / s - i tam nie ma nawet tak dużej bestii pod względem wielkości bazy danych.

Również system I / O dla tego pojedynczego węzła PostgreSQL będzie interesujący, nawet w przypadku RAID 10 i przy założeniu, że wstawki 50K będą równe tylko 50K IOPS (co prawdopodobnie jest złe, ale zależy to od schematu bazy danych i wskaźników ), będziesz potrzebować około stu dysków w połączeniu z bardzo dobrą macierzą, która oszczędza Ci kupowania kilkuset dysków w celu terminowej obsługi zapisów.

Jeśli dzielenie na fragmenty jest łatwe i oczekujesz tak dużego obciążenia zapisu, wybierz dzielenie na fragmenty. Skalowanie zapisów może być bardzo trudne.

— pfo
źródło

Zgodzić się. Jest to domena systemu typu ExaData. To smutne, że uzyskanie 50 tys. IOPS jest obecnie dość trywialne w przypadku dysków SSD - otoh, będą one drogie. Spodziewałbym się tutaj większego 7-cyfrowego budżetu na sprzęt, w tym średniej i wysokiej klasy SAN.

— TomTom

Tak, ExaData jest opcją, jeśli chcesz przejść do „pionowo zintegrowanego stosu rozwiązań”, co prawdopodobnie nie jest takie złe, biorąc pod uwagę wymagania.

— pfo

Tak. Istnieją poważne zalety czegoś takiego, zarówno 100 TB, jak i 50.000 Iops naprawdę nie krzyczą „tanie”. Exadata robi co - 1 milion IOPS przy pełnym załadowaniu SSD?

— TomTom

Dodając do tych komentarzy, myślę, że biorąc pod uwagę budżet wymagany do uzyskania takiej ilości danych przy tej liczbie wstawek, kusiłoby mnie do korzystania z płatnego silnika SQL, będzie to niewielki procent całkowitego budżetu, a ty Będę miał znacznie lepsze wsparcie.

— Chopper3

W pełni się zgadzam. W momencie, gdy Twój budżet na SAN osiągnie kilkaset tysięcy, zmienia się wiele wycen.

— TomTom

Jest realistyczny i będzie działał. Wydajność w większym stopniu zależy od ilości pamięci RAM. Im większa pamięć RAM, tym większa pamięć podręczna i tym dłużej PostgreSQL może buforować dane przed rozładowaniem na dysk.

PostgreSQL zapisuje dane w pamięci podręcznej i od czasu do czasu odciąża pamięć podręczną. Dlatego 50 000 WSTAWEK na sekundę nie zostanie przetłumaczonych na 50 000 IOPS. Będzie o wiele mniej, ponieważ gromadzi rekordy razem i zapisuje je wszystkie jednocześnie.

Tak duża baza danych nie stanowi problemu, jeśli większość pracy to INSERT. PostgreSQL będzie musiał zmieniać indeksy tu i tam, ale to naprawdę łatwe zadanie. Jeśli miałeś dużo WYBORÓW w bazie danych tego rozmiaru, naprawdę musisz odłamać.

Kiedyś pracowałem na Oracle DB (Oracle 10g) z 400 TB na serwerze 16 GB, tylko jedna instancja. Obciążenie bazy danych było również podstawowymi WSTAWKAMI, więc kilka WYBORÓW dziennie i miliony WSTAWEK każdego dnia. Wydajność nie była problemem.

— ThoriumBR
źródło

Przy 100 TB masz kilka ważnych wyzwań. To, czy zadziała dla Ciebie, zależy od tego, jak chcesz rozwiązać te problemy.

Potrzebujesz wystarczających sposobów na pochłonięcie obciążenia zapisu. To zależy od obciążenia zapisu. Ale przy wystarczająco niesamowitej przestrzeni dyskowej można to rozwiązać. Prędkość jest tutaj dużym problemem. Podobnie należy dokładnie sprawdzić dostęp do odczytu.
Większość baz danych nie składa się z kilku małych tabel, ale często ma jedną lub dwie naprawdę duże, które mogą mieć do połowy wielkości db. PostgreSQL ma twardy limit 32 TB na tabelę. Po tym typie tid zabraknie liczników stron. Można to rozwiązać za pomocą niestandardowej kompilacji PostgreSQL lub partycjonowania tabeli, ale jest to poważne wyzwanie, którym należy się zająć na początku.
PostgreSQL ma rzeczywiste ograniczenia dotyczące ilości pamięci RAM, którą może wykorzystać do różnych zadań. Tak więc posiadanie większej ilości pamięci RAM może, ale nie musi, pomóc ci w pewnym stopniu.
Kopie zapasowe .... Kopie zapasowe są interesujące w tej skali. Baza danych 60 TB, o której wiem, musiała użyć kopii zapasowych migawki fs, a następnie sfałszować kopie zapasowe dla barmana do archiwizacji wal. Te fałszywe kopie zapasowe były serwerami proxy dla kopii zapasowych migawek fs. Jak powiedziałem „Nie są to fałszywe kopie zapasowe. Są to alternatywne kopie zapasowe!”

Są ludzie z bazami danych zbliżającymi się do tego zakresu. Spotkałem przynajmniej jedną osobę, która pracowała dla banku w Holandii, który miał bazę danych PostgreSQL o pojemności 60 TB. Jednak tak naprawdę tak naprawdę zależy od obciążenia pracą i sam rozmiar nie stanowi problemu.

— Chris Travers
źródło