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
źródło
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.
źródło
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.
ź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.
źródło