PostgreSQL dla transakcji o dużym wolumenie i hurtowni danych

Jestem całkiem nowy w PostgreSQL, nigdy wcześniej nie przeprowadzałem dużego wdrożenia, używając go. Ale mam duże doświadczenie w rozwiązaniach dla przedsiębiorstw i chcę spróbować zastosować część tego, czego się nauczyłem, korzystając z PostgreSQL.

Mam witrynę dostosowaną do obsługi dużej liczby danych i ruchu. Infrastruktura zostanie zbudowana z wykorzystaniem Amazon (AWS) przy użyciu instancji EC2 i woluminów EBS.

Projekt powinien mieć dwie bazy danych, główną bazę danych transakcji i hurtownię danych do obsługi analiz i raportów.

Główna baza transakcyjna

będzie używany do witryny na żywo, witryna jest zbudowana z wielu węzłów w celu zwiększenia liczby jednoczesnych użytkowników. Przede wszystkim wymagamy, aby baza danych była bardzo szybka w operacjach odczytu, oczekujemy> 100 GB danych z 30% rocznym wzrostem. W tym momencie planujemy użyć dwóch serwerów EC2 ( i dodać więcej w razie potrzeby ).

moje pytanie, jaka jest zalecana konfiguracja powyższych wymagań? Ponadto, czy istnieje sposób zarządzania partycjonowaniem tabeli i woluminów? czy istnieją zalecenia dotyczące korzystania z konfiguracji AWS?

Baza danych hurtowni danych

Będzie używany głównie do przechwytywania wszystkich danych z głównej bazy danych transakcji w wymiarze czasowym. więc nawet usunięte rekordy z głównej bazy danych zostaną przechwycone w DWH. Dlatego dane będą bardzo duże, a wzrost będzie jeszcze większy. W razie potrzeby użyjemy również kilku instancji EC2 lub więcej.

Jaka jest zalecana konfiguracja w tym przypadku? będzie to wymagało szybkiej operacji zapisu z powodu ciągłego zapisu (ETL). Czy możemy budować kostki OLAP w PostgreSQL? jeśli tak, to czy ktoś próbował?

Łączenie z bazą danych

Serwery WWW będą łączyć się z główną bazą danych w celu wysyłania zapytań i zapisywania. Obecnie opracowujemy aplikację przy użyciu django, która korzysta z biblioteki natywnej do łączenia się. Czy zaleca się stosowanie tej samej podstawowej metody? czy powinniśmy skonfigurować pgpool?

Hurtownia danych (ETL)

Jaki jest zalecany sposób budowania procesów ETL do odczytu z głównego i ładowania do hurtowni danych? Jakieś narzędzia? metodologię do naśladowania? czy PostgreSQL oferuje jakieś przydatne funkcje / narzędzia w budowaniu procesów ETL?

Usługi infrastruktury / baz danych

Prawdopodobnie powinieneś przeczytać to, aby zapoznać się z obszerną witryną, która działa na AWS z EBS. Przeszli do magazynu efemerycznego, ale musieli stworzyć pewną nadmiarowość, aby móc (ponownie) przechowywać dane.

http://blog.reddit.com/2012/01/j.01-2012-state-of-servers.html

Hurtownia danych / ETL

W przeszłości korzystałem z Pentaho. Nie bezpośrednio z postgres, ale uważam, że jest to dobre rozwiązanie zarówno dla OLAP (Mondrian), jak i ETL (Kettle)

http://www.pentaho.com/

edycja: „Edycje społeczności” można znaleźć tutaj

http://mondrian.pentaho.com/

http://kettle.pentaho.com/

Połączenie

Ci ludzie naprawdę lubią pgbouncer. /programming/1125504/django-persistent-database-connection

Nie mam z tym jednak doświadczenia. Najwyraźniej Disqus go używa.

Twoja konfiguracja przypomina tę, którą opracowałem dla uniwersytetu. Baza danych nie była ogromna, ale dość duża, około 300 GB, a największa tabela zawierała około 500 milionów rekordów. I wciąż rośnie.

W tym celu wykorzystano dwa naprawdę rozbudowane serwery (prawdziwe żelazo, nie zwirtualizowane), jeden przeznaczony do obsługi danych ze strony internetowej, a drugi wykorzystywany do obliczeń statystycznych i analiz. Dane zostały zreplikowane w obu kierunkach przy użyciu Slony. Dane OLTP były replikowane w sposób ciągły na serwerze OLAP, a niektóre schematy i pojedyncze tabele były replikowane z serwera OLAP na OLTP. W ten sposób można wykonać ciężkie obliczenia na serwerze analizy bez wpływu na serwer OLTP. Obecnie istnieje kilka alternatyw dla Slony do replikacji danych: http://www.postgresql.org/docs/9.2/static/different-replication-solutions.html

Slony był dobry i szybki dla naszej troski, ale może to być surowy nauczyciel.

Ponieważ serwer OLAP będzie rósł stabilnie, należy rozważyć zastosowanie podziału na partycje, jeśli ma to zastosowanie.

Jeśli masz taką możliwość, użyj puli połączeń. Użyłem tylko PgPool i działało bezbłędnie. PgBouncer to kolejna opcja. Oprócz zmniejszenia opóźnień inicjowania zmniejsza również uruchamianie sesji i zarządzanie sesjami. http://momjian.us/main/blogs/pgblog/2012.html#April_25_2012

Kolejną zaletą korzystania z puli połączeń jest to, że masz jeden punkt, w którym możesz łatwo przekierować swój ruch (może to oczywiście stanowić ryzyko).

Nie użyłem żadnego gotowego ETL do ładowania danych na serwer OLAP. Napisałem własny skrypt w Pythonie, ponieważ niektóre dane zostały dostarczone w ogromnych plikach tekstowych o osobliwym formacie.

Strukturę bazy danych należy dokładnie rozważyć. Korzystanie ze schematów jest dobre do gromadzenia i ułatwia obsługę obiektów. Korzystanie ze schematów może wydawać się kłopotliwe, ale wraz ze wzrostem liczby obiektów będziesz sobie wdzięczny. Wiedząc, że musisz jawnie poprzedzać obiekty ich schematem, wiesz dokładnie, na których obiektach operujesz. http://momjian.us/main/blogs/pgblog/2012.html#April_27_2012

Dla odważnych PostgreSQL XC może być ciekawą alternatywą lub po prostu zbyt dużym kostiumem http://postgres-xc.sourceforge.net/