GoldenLine
Zaloguj się
Michał Płonka

Michał Płonka Programista PHP

Temat: PostgreSQL i duża baza danych

Witam,
tworzę system, który będzie "bombardowany" dużą liczbą danych. Może przedstawię poglądową strukturę (nazwy poglądowe):

produkty: 1x bigint, 1x character varying, 2x tsvector, 1x timestamp
produkty_kategorie: 1x bigint, 1x int, 1x smallint
zakupy: 1x serial, 2x bigint, 2x smallint, 1x numeric, 1x timestamp

Z moich obliczeń wynika, że dziennie do tabeli produkty będzie trafiało ok. 590 000 rekordów, co rocznie daje prawie 220 000 000. Każdemu produktowi odpowiadają średnio 4 rekordy w tabeli produkty_kategorie oraz 3 rekordy w tabeli zakupy. Nawet jeżeli moje obliczenia są zbyt optymistyczne (niech będzie 50% wyliczanych wartości) to i tak baza danych wydaje się być (dla mnie) gigantyczna.

Generalnie baza będzie zasilana praktycznie non stop danymi (24h/dobę INSERTY do wspomnianych tabel). Wyszukiwanie będzie odbywało się tylko i wyłącznie po obu polach tsvector z tabeli produkty wraz z polem timestamp z tabeli zakupy. Raz wyszukana informacja zostanie zapisana w tabeli raportów aby następne takie samo żądanie nie wymagało zliczania wszystkiego od nowa (taki swoisty cache).

Pytanie zasadnicze: czy PostgreSQL da w tym przypadku radę? Czy macie jakieś doświadczenie przy podobnych liczbach rekordów? Jak to wszystko może działać? Na co zwrócić uwagę?

Z góry wielkie dzięki za odpowiedź,
Michał
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Dzień Dobry,

Oczywiście Postgres da sobie radę, nawet z wiele większymi bazami.

Bardziej bym się martwił wydajnością serwera, niż bazy. Zdaje mi się, że będzie wymagany cluster lub spread.

pozdrawiam,
Link do wypowiedziLink
Wojciech Bublik

Wojciech Bublik Przedsiębiorca w
branży IT

Temat: PostgreSQL i duża baza danych

Witam,

Też sądze, że Postgres sobie z tym poradzi:)
Warto zwrócić uwagę, aby aplikacja nie wykonywała zbędnych updatów na tak dużych tabelach, po to aby unikać potrzeby robienia na nich Vacuum full oraz warto zastanowić się nad spartycjonowaniem tych tabel.
Ułatwi to zarządzanie danymi i indeksami oraz powinno przyspiszyc wyszukiwanie np o tsvector jeśli podasz do selecta dodatkowe warunki, wg których są tworzone partycje.
http://www.postgresql.org/docs/8.3/interactive/ddl-par...
http://www.postgresql.org/docs/8.3/interactive/ddl-inh...

Myślę, że optymalnie byłoby spartycjonować tabele tak, aby każda zajmowała po kilkanaście GB.

Kolejna sprawa to postgresql.conf... Nie zapomnij o tuningu parametrów takich jak: effective_cache_size, work_mem, shared_buffers:) oraz jeśli baza danych jest "bombardowana" insertami to na pewno trzeba będzie zwiększyć checkpoint_segments np do 8.

Pozdrawiam
Wojtek
Link do wypowiedziLink
Olsza Olszewski

Olsza Olszewski
Informatyk-Programis
ta

Temat: PostgreSQL i duża baza danych

Witam,
zgadzam się z kolegami, baza postgreSQL spokojnie da rade, najważniejsze by serwer był wydajny a po drugie by pozakładać indeksy i jak już kolega wspomniał, by nie robić za dużo update
Link do wypowiedziLink
Adam Woźniak

Adam Woźniak software architect
and developer

Temat: PostgreSQL i duża baza danych

Łukasz Olszewski:
[..] by nie robić za dużo update

Z ciekawości spytam:
A to jest jakiś trik minimalizujący ilość operacji UPDATE?
Link do wypowiedziLink
Michał Płonka

Michał Płonka Programista PHP

Temat: PostgreSQL i duża baza danych

Dzięki za odpowiedzi. UPDATEów praktycznie nie będzie wcale, a jeśli już będą to na innych tabelach, w których będzie zdecydowanie mniej danych. Przyznam, że nieco mnie uspokoiliście. Obawiałem się, że po prostu baza danych się zapcha i będzie 2012. Tak czy siak dzięki jeszcze raz za wypowiedzi.
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Przepraszam, ale muszę zapytać ;)
Co jest produktem?
Czegoś tu nie rozumiem - no, chyba, że firma sprzedaje dobra szybko zbywalne i trzeba pamiętać każde opakowanie jogurtu... ;) Podsumowując - całkiem być może, że problem da się rozwiązać prościej / efektywniej, ale takie postawienie sprawy kieruje na zły tor.
Dlaczego zły? Przy maszynie 64 bitowej ponumerowanie wierszy to nie problem. Z ogólnego opisu wynika, że nie będzie sekwencyjnych odczytów, więc indeksowanie odgrywa rolę pierwszoplanową i ram nie powinien być problemem. Znaczy, jak ktoś decyduje się na przetwarzanie dużych ilości danych to zwykle liczy się z dużymi wydatkami... I ram nie jest tu głównym wydatkiem.
Jeżeli przetwarzanie ma być bardziej "hurtowniane" warto pomyśleć o innych rozwiązaniach... Postgres trzyma dane w wierszach, dla hurtowni lepiej trzymać je kolumnowo.

--
Michał Zaborowski
Link do wypowiedziLink
Michał Płonka

Michał Płonka Programista PHP

Temat: PostgreSQL i duża baza danych

Michał Z.:
Przepraszam, ale muszę zapytać ;)
Co jest produktem?
Nie mogę powiedzieć za wiele. Generalnie produkt to w tym przypadku coś, co będzie importowane ze źródła zewnętrznego. Częstotliwość powstawania nowych produktów jest dość duża. Więcej wolę nie mówić, zobowiązałem się do dotrzymania tajemnicy.
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Postgres i duże bazy danych ładnie grają. Podzielam opinię przedmówców: odpowiedni tuning ustawień postgres.conf, dobrze przemyślana struktura bazy i powinno być dobrze. Przy większych ilościach i szybkościach faktycznie warto pomyśleć nad klastrem.

Wiele tu też zależy od tego czy będziesz miał mało, ale ciężkich
userów dopiętych do serwera, czy też licznych a lekkich... Może też się trafić i wielu i ciężkich :)

Sam serwer i jego skalowalność - na początku system będzie zapewne śmigać ładnie na domyślnej konfiguracji, co może być zwodnicze później. Jeśli budżet pozwala, to sugerowałbym sprzętowo celować w coś co będzie dobrze skalowalne i dodanie pamięci czy rdzeni nie będzie dużym problemem.

Jeśli tak wyjdzie że będziesz serwer stawiać samemu, to dobrze rozważ stosowany system plików na dyskach oraz typ RAID`a - czasem prosta pomyłka w doborze systemu plików czy sposobie jego rozłożenia w logice dysków może być zdradliwa bo na początku tego nie widać... a potem każda zmiana boli bardziej...
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Michał Płonka:
Dzięki za odpowiedzi. UPDATEów praktycznie nie będzie wcale, a jeśli już będą to na innych tabelach, w których będzie zdecydowanie mniej danych. Przyznam, że nieco mnie uspokoiliście. Obawiałem się, że po prostu baza danych się zapcha i będzie 2012. Tak czy siak dzięki jeszcze raz za wypowiedzi.


że co będzie?
Link do wypowiedziLink
Michał Jarosz

Michał Jarosz Frontend Developer &
Team Leader

Temat: PostgreSQL i duża baza danych

Szymon G.:
Michał Płonka:
i będzie 2012.


że co będzie?


Koniec świata chyba ;)
Link do wypowiedziLink
Borys Mądrawski

Borys Mądrawski Architekt/Developer
EAI/Java

Temat: PostgreSQL i duża baza danych

Michał Z.:
Jeżeli przetwarzanie ma być bardziej "hurtowniane" warto pomyśleć o innych rozwiązaniach... Postgres trzyma dane w wierszach, dla hurtowni lepiej trzymać je kolumnowo.

--
Michał Zaborowski
Mówisz o denormalizacji z tymi kolumnami? Czy o tworzeniu kostki wielowymiarowej?

Tak czy inaczej, typowy OLTP nie nadaje się za bardzo na wydajny OLAP czy data werehouse, bo ma nieoptymalną z punktu widzenia drążenia ("czesania") organizację danych (niektóre produkty potrafią trzymać dane read-only w formie kostki), a z drugiej strony nie potrafi wykonywać w sposób bardzo wydajny wielokrotnych i skomplikowanych złożeń, co potrafi np.: Teradata, opierająca się na modelu gwieździstym, wielonodowej architekturze sprzętowej, która nie radzi sobie za to z modyfikacją danych.
Oczywiście mówię o instalacjach z dużą ilością danych, bo dla małych te problemy się aż tak bardzo nie uwidaczniają.
Na zwykły model danych można nałożyć "świat obiektów" i po nich drążyć (Bizness Objects, SAS, Pentaho BI) o ile RDBMS jest na tyle silny, a schemat danych przygotowany pod złożone zapytania.
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Michał Płonka:
Witam,
tworzę system, który będzie "bombardowany" dużą liczbą danych. Może przedstawię poglądową strukturę (nazwy poglądowe):

produkty: 1x bigint, 1x character varying, 2x tsvector, 1x timestamp
produkty_kategorie: 1x bigint, 1x int, 1x smallint
zakupy: 1x serial, 2x bigint, 2x smallint, 1x numeric, 1x timestamp

Z moich obliczeń wynika, że dziennie do tabeli produkty będzie trafiało ok. 590 000 rekordów, co rocznie daje prawie 220 000 000. Każdemu produktowi odpowiadają średnio 4 rekordy w tabeli produkty_kategorie oraz 3 rekordy w tabeli zakupy. Nawet jeżeli moje obliczenia są zbyt optymistyczne (niech będzie 50% wyliczanych wartości) to i tak baza danych wydaje się być (dla mnie) gigantyczna.

Będzie taka, powiedzmy, średnia w porywach do takiej sobie :)
Pytanie zasadnicze: czy PostgreSQL da w tym przypadku radę? Czy macie jakieś doświadczenie przy podobnych liczbach rekordów? Jak to wszystko może działać? Na co zwrócić uwagę?
>

Da radę. Może działać szybko. Może działać wolno. Gwarantuję, że `select * from produkty` oraz `select count(*) from produkty` będzie działać koszmarnie wolno.
Na te pytania się nie da odpowiedzieć, wszystko zależy od tego jak używasz bazę, jaka jest struktura, jaki masz sprzęt i konfigurację.

Zwrócić uwagę możesz na:
- partycjonowanie (http://www.postgresql.org/docs/8.4/interactive/ddl-par...
- `select count(*)` wymaga skanu sekwencyjnego na tabeli, więc będzie trzeba zrobić sensownie zliczanie co by `select count(*)` się nie odpalało.
- dyski muszą być sensowne
- ramu musi być sporo
- dump & restore będzie zajmować sporo czasu (możesz liczyć raczej godziny niż minuty)
- update istniejących danych bez wpływu na szybkość tych insertów będzie działać jeszcze wolniej (tutaj możesz liczyć to w dniach albo i tygodniach)
- zamiast varchar użyj text, będzie szybciej, przy takiej liczbie danych może zobaczysz różnicę
- maszynka musi być odpowiednia
- taka baza nieco miejsca zajmie, możesz liczyć to w granicach 100-200GB (tak gdybając sobie) więc dyski muszą być odpowiednie, bo migracja na nową maszynę może nieco zająć
- używaj jak najnowszej wersji postgresa, nowsze wersje mają fajniejsze planery
- indeksy muszą być odpowiednie (znaczy się tylko te potrzebne)
- konfiguracja musi być dobrze podkręcona

Reasumując: jak nie wiesz co z tym zrobić, nie masz doświadczenia, a robisz system, który ma działać 24/365 i biznesowo jest baaardzo ważny, to raczej weź dobrego admina i dobrego DBA (znaczy się przeważnie wystarczy DBA, z adminowaniem sprzętem i systemem da sobie radę) i niech oni to przygotują. Inaczej za kilka miesięcy będziesz szukał DBA po nocach, bo nagle system przestanie odpowiadać, baza się wyłączy (normalna rzecz w postgresie jak leci dużo transakcji i jakaś stara transakcja wisi np. 2 miesiące), albo też będzie to wszystko kosmicznie wolno działać. Potem przyjdzie DBA, powie, że OK, zrobi, ale ze względu na sprzęt i ilość danych, będzie to trwało tydzień... a przez ten czas system nie będzie działać :)
Skutki potem są takie jak np. tutaj http://it.toolbox.com/blogs/database-soup/nothing-is-m....

No i zupełnie zgadzam się z Michałem: możliwe, że potrzebujecie coś zupełnie innego niż normalna baza relacyjna.
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Michał Jarosz:
Szymon G.:
Michał Płonka:
i będzie 2012.


że co będzie?


Koniec świata chyba ;)

aaa, no tak, jakoś nie rozumiem tego młodzieżowego slangu :)
Link do wypowiedziLink
Borys Mądrawski

Borys Mądrawski Architekt/Developer
EAI/Java

Temat: PostgreSQL i duża baza danych

Michał Płonka:
Pytanie zasadnicze: czy PostgreSQL da w tym przypadku radę? Czy macie jakieś doświadczenie przy podobnych liczbach rekordów? Jak to wszystko może działać? Na co zwrócić uwagę?
Z tą liczbą rekordów PostgreSQL da sobie radę bez problemów.

Mnie bardziej martwią te nieustannie spływające inserty.
Nie można ich zbierać do tablicy roboczej i cyklicznie raz na dobę w godzinach nocnych wykonywać "insert into <tablica_docelowa> select from <tablica_robocza>; delete from <tablica_robocza>;", po uprzednim zdjęciu indexów i założeniu ich z powrotem po zakończonej operacji?
Chodzi mi o to że takie spływające nieustannie inserty będą psuć indeksy i PostgreSQL może mieć problem z ich nieustannym odbudowywaniem.
Zjawisko to dotyczy generalnie wszystkich RDBMS, ale nie jestem pewny jak PostgreSQL sobie z tym poradzi.
Link do wypowiedziLink
Wojciech Bublik

Wojciech Bublik Przedsiębiorca w
branży IT

Temat: PostgreSQL i duża baza danych

Borys M.:
Chodzi mi o to że takie spływające nieustannie inserty będą psuć indeksy i PostgreSQL może mieć problem z ich nieustannym
odbudowywaniem.

No taki problem może się zdarzyć, ale właśnie temu zapobiega partycjonowanie, ponieważ indeks jest tworzony na tabeli dziedziczącej, czyli tylko na fragmencie danych i dzięki temu ma ograniczoną wielkość:)

Następną rzeczą, o której warto pomyśleć to zmiana wartości parametru FILLFACTOR przy CREATE INDEX, który defaultowo wynosi 90%.
http://www.postgresql.org/docs/8.3/static/sql-createin...
Ustawienie go na niższą wartość zmniejsza początkowe wypełnienie drzewa btree, co opóźnia późniejsze ewentualne problemy z przepełnianiem gałęzi w przypadku wielu insertów/updatów do tabeli.Wojciech Bublik edytował(a) ten post dnia 08.12.09 o godzinie 21:15
Link do wypowiedziLink
Borys Mądrawski

Borys Mądrawski Architekt/Developer
EAI/Java

Temat: PostgreSQL i duża baza danych

Wojciech Bublik:
No taki problem może się zdarzyć, ale właśnie temu zapobiega partycjonowanie, ponieważ indeks jest tworzony na tabeli dziedziczącej, czyli tylko na fragmencie danych i dzięki temu ma ograniczoną wielkość:)
Nie jestem pewny, czy partycjonowanie poprawia łatwość uaktualniania się index'u niepartycjonującego, bo nie jestem pewny czy index też podlega partycjonowaniu.
Następną rzeczą, o której warto pomyśleć to zmiana wartości parametru FILLFACTOR przy CREATE INDEX, który defaultowo wynosi 90%.
Racja, no i można regularnie usuwać taki zapchany już index i go odbudowywać, przez jego ponowne stworzenie, a najlepiej robić to w nocy.Borys M. edytował(a) ten post dnia 08.12.09 o godzinie 21:44
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Borys M.:
Wojciech Bublik:
No taki problem może się zdarzyć, ale właśnie temu zapobiega partycjonowanie, ponieważ indeks jest tworzony na tabeli dziedziczącej, czyli tylko na fragmencie danych i dzięki temu ma ograniczoną wielkość:)
Nie jestem pewny, czy partycjonowanie poprawia łatwość uaktualniania się index'u niepartycjonującego, bo nie jestem pewny czy index też podlega partycjonowaniu.

Partycjonowanie wygląda tak, że dane zamiast w jednej tabeli trzymane są w 10 mniejszych. Przez to zamiast jednego dużego indeksu, masz 10 mniejszych.
Następną rzeczą, o której warto pomyśleć to zmiana wartości parametru FILLFACTOR przy CREATE INDEX, który defaultowo wynosi 90%.
Racja, no i można regularnie usuwać taki zapchany już index i go odbudowywać, przez jego ponowne stworzenie, a najlepiej robić to w nocy.Borys M. edytował(a) ten post dnia 08.12.09 o godzinie 21:44

Ta... niby tak... jest nawet polecenie reindex, które tworzy nowy indeks i usuwa stary, ALE całkowicie blokuje tabelę do zapisu, więc inserty czekają. Jak to trwa długo to aplikacje mogą mieć timout i część insertów znika.
Link do wypowiedziLink
Łukasz Dudek

Łukasz Dudek Database
Administrator

Temat: PostgreSQL i duża baza danych

Borys M.:
Wojciech Bublik:
No taki problem może się zdarzyć, ale właśnie temu zapobiega partycjonowanie, ponieważ indeks jest tworzony na tabeli dziedziczącej, czyli tylko na fragmencie danych i dzięki temu ma ograniczoną wielkość:)
Nie jestem pewny, czy partycjonowanie poprawia łatwość uaktualniania się index'u niepartycjonującego, bo nie jestem pewny czy index też podlega partycjonowaniu.

Partycjonowanie w postgresie ta taki mały hack wykorzystujący dziedziczenie,rule i checki. nie ma czegoś takiego jak partycjonowanie indeksu jest "partycjonowanie" tabel gdzie każde dziecko to osobna tabela a jak sobie tam indeksy pozakładasz twoja wola. W teori tabela matka jest pusta a dzieci są przeszukiwane ze względu na to co jest w warunku zapytania.
Następną rzeczą, o której warto pomyśleć to zmiana wartości parametru FILLFACTOR przy CREATE INDEX, który defaultowo wynosi 90%.
Racja, no i można regularnie usuwać taki zapchany już index i go odbudowywać, przez jego ponowne stworzenie, a najlepiej robić to w nocy.

tylko jest jeden problem z takimi zabawami reindex tabel jest blokujący, a drop index + create index concurrently powoduje zmiane oid'u czyli musisz przekompilowac wszystkie funkcje pl/pgSQl w których plan zapytania zaplątał sie ten index.

poza olapami istnieje inne rozwiązanie dla hurtowni... bazy danych o konstrukcji kolumnowej, Sybase IQ, Vertica itdŁukasz Dudek edytował(a) ten post dnia 08.12.09 o godzinie 22:18
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL i duża baza danych

Łukasz Dudek:
tylko jest jeden problem z takimi zabawami reindex tabel jest blokujący, a drop index + create index concurrently powoduje zmiane oid'u czyli musisz przekompilowac wszystkie funkcje pl/pgSQl w których plan zapytania zaplątał sie ten index.

Do tego dodajmy, że create index concurrently trwa wieki dłużej niż create index potrzebując dwa skany sekwencyjne (czy jakoś tak). Poza tym jak zrobisz poza transakcją drop index + create index, to wtedy niespodzianka: nagle wiele zapytań ma plan bez tego indeksu i można się zdziwić czemu nagle wszystko przestało działać :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

[postgresql] przeniesienie ...




Wyślij zaproszenie do
Anuluj