Słyszałem, że wydajność nieczeregowanej relacyjnej bazy danych, takiej jak MySQL lub PostgreSQL, „psuje się” powyżej 10 TB.
Podejrzewam, że takie ograniczenia istnieją, ponieważ nie wymyśliłby Netezza, Greenplum, Vertica itp., Ale chciałbym zapytać, czy ktoś tu ma odniesienie do jakiegokolwiek dokumentu badawczego lub formalnych studiów przypadku, w których limity te są określone ilościowo.
Odpowiedzi:
Nie ma prostej odpowiedzi na twoje pytanie, ale oto kilka rzeczy do przemyślenia.
Po pierwsze, skala nie jest jedyną rzeczą, o którą należy się martwić. To, co robisz ze swoimi danymi, to. Jeśli masz 500 tabel 30 TB danych i wykonujesz prosty OLTP z bardzo małą liczbą raportów, nie sądzę, że będziesz miał zbyt wiele problemów. Tam są bazy danych 32 TB na PostgreSQL. Jednak w tym samym czasie wydajność nieco się obniży, ponieważ musi uderzać we wszystko dyskiem. Podobnie, jeśli masz 50 TB, jeśli dane, ale masz zwykle hit około 100 GB, możesz zbudować serwer z wystarczającą ilością pamięci RAM, aby zachować tę część db w pamięci i jesteś złoty.
Z drugiej strony, jeśli próbujesz usunąć tryb (najczęstszą wartość) z 1 TB danych, nie ma znaczenia, jakiego systemu używasz, będzie to bolesne z lub bez shardingu. (Edycja: Odłamki mogą w rzeczywistości pogorszyć ten problem ).
Główne problemy, na które natkniesz się z dużymi bazami danych na MySQL i PostgreSQL, polegają na tym, że żadne z nich nie obsługuje równoległości wewnątrz kwerendy. Innymi słowy, zapytanie jest uruchamiane jako pojedynczy blok przez jeden wątek i nie można go podzielić na części i uruchamiać osobno. Jest to najczęściej problem przy uruchamianiu dużych zapytań analitycznych na dużych ilościach danych. To tutaj Postgres-XC i Zielona Śliwka przybywają na ratunek, ponieważ oddzielają magazyn od egzekucji i mogą to zrobić na poziomie koordynatora. Zauważ, że Postgres-XC i Zielona Śliwka zasadniczo używają shardingu wewnętrznie, ale koordynatorzy egzekwują całą spójność na całym świecie.
Dzięki równoległości wewnątrz kwerendy można rozdzielić zapytanie, pozwolić, aby różne procesory / dyskowe kanały we / wy uruchamiały jego części, i zgłaszać z powrotem fragmenty zestawu wyników, które należy złożyć i przekazać z powrotem do aplikacji. Ponownie jest to zwykle najbardziej przydatne w przypadku obciążeń analitycznych, a nie przetwarzania transakcji.
Po drugie, niektóre systemy, takie jak Vertica lub Greenplum, przechowują kolumny informacji razem. Utrudnia to korzystanie z systemu z perspektywy OLTP i zmniejsza wydajność, ale drastycznie zwiększa wydajność w przypadku dużych obciążeń analitycznych. Jest to więc kompromis związany z obciążeniem.
Tak więc odpowiedź jest taka, że po osiągnięciu rozmiaru powyżej 1-2 TB może pojawić się szereg kompromisów między systemami i obciążeniami. Znowu dotyczy to baz danych, wielkości zestawów roboczych itp. Jednak w tym momencie naprawdę musisz korzystać z systemów płatków śniegu, tj. Unikalnych i dostosowanych do obciążenia.
Oznacza to oczywiście, że limity nie są na ogół kwantyfikowalne.
Edycja : Pracowałem teraz z bazą danych 9 TB, która obsługuje połączenie obsługi decyzji i obciążeń związanych z przetwarzaniem transakcyjnym w PostgreSQL. Największym wyzwaniem jest to, że jeśli masz pytania, które uderzają w duże części zestawu danych, będziesz musiał chwilę poczekać na odpowiedź.
Jednak przy zwróceniu szczególnej uwagi na podstawy (w tym indeksy, próżnię automatyczną, sposób działania na niskim poziomie itp.) Oraz wystarczające zasoby obliczeniowe, są one w pełni możliwe do zarządzania (i szacuję, że można je zarządzać również w zakresie 30 TB w Pg).
Edycja2 : Po przejściu do 100 TB, co będzie działać, będzie zależeć od twojego zestawu danych. Pracuję teraz nad jednym, który nie będzie skalowany do tego zakresu, ponieważ najpierw osiągnie limit 32 TB na tabelę w PostgreSQL.