Temat: PostreSQL - problem z indexami

Krzysztof Magosa:

[...]

Na chwilę obecną CPU - postgres zarzyna 2 cory w 100%, a na pozostałych 2 corach pracuje aplikacja, która wrzuca dane do tej bazy. Docelowo z pewnością wyniosę aplikację na osobną maszynę, bo walczy z bazą o CPU.

Serwer www nie powinien walczyć z bazą o cpu. Zależy jeszcze
co tam konkretnie się dzieje...

Nie powinien, ale walczył, bo nie było go gdzie przenieść...
Ale odpaliłem właśnie 2 dodatkowe maszynki, gdzie przerzuciłem aplikację, więc serwer odpocznie.
Aktualnie postgres wykorzystuje 3 core z 4, więc pojawił się nieduży zapas CPU.
Niestety z tego co widzę, teraz I/O będzie stanowić wąskie gardło, którego na chwilę obecną nie poszerzę.

Cache może trochę pomóc, ale raczej przy odczycie. No i jak się
inserty skończą, będzie lepiej.

[...]

W rekordach są pola TEXT, które postgres i tak wywala na zewnątrz.

Nie. varchar(10) od text - z tymi samymi danymi różni się tym,
że baza musi sprawdzić długość dla varchara. Jak rekord nie
mieści się w stronie - wtedy coś trzeba trzymać gdzieś obok.
Inne bazy trzymają rekord na kilku stronach. PG ma mniej
wydajne rozwiązanie - i delikatnie mówiąc - gołym okiem widać
różnicę.

W planach mam przebudowanie struktury, by oddzielić ciężkie rzadko używane dane od reszty lekkich kolumn. Co do monitoringu - mam porobione wykresy itd.

Na szybko - zrobiłbym tak, żeby te pola text były na końcu. Wtedy
dostęp do małych pól będzie relatywnie szybki. Przenoszenie do
nowej tabeli ma sens, jeżeli uda się rozbić te pola - jak to jest
fragment strony / cały plik / czy tam inne coś - nie ma sensu.
Zastanowiłbym się tylko, czy nie trzymać tego w inny sposób.
W sensie jakiś nosql zorientowany na dokumenty.

Jaka replikacja jest stosowana i jak zachowuje się przy takim obciążeniu?

Aktualnie nie ma replikacji i całość pracuje na 1 serwerze.

Ja tam nie wiem, ale lepiej śpię jak jest replikacja. Z drugiej strony jak system nie jest krytyczny - nie ma się co napinać.

Cały czas rozważam uruchomienie replikacji żeby zapisywać do jednej bazy, a na pozostałych mieć szybki odczyt.

Czy ja wiem... Skoro 1/3 ruchu to selekty, które w dodatku
wykonują się błyskawicznie? Chyba lepiej zwalczyć problem
z insertami. Tu można się zastanowić nad partycjonowaniem.
Chyba Daniel pisał o tym. Nie jest to, co w Oracle, ale - jest.
Partycjonowanie poprawi administrację, zwłaszcza dużymi
tabelami. Co, przy takim przyroście ma sens.

To jest do przemyślenia, ale na chwilę obecną wydaje się zbyt czasochłonne.

Tak coś mi się wydaje, że zaryzykowałbym z hadoopem,
zamiast PG...

Gdyby architektura aplikacji była przygotowywana od początku do tego co robi teraz, to pewnie to wszystko wyglądałoby inaczej, ale nie ma szans na tak drastyczne zmiany.

Tak... to dość częsta przypadłość. :(

Jeżeli to jest jakiś crawler, analizator stron - wtedy operowanie
na zasadzie klucz - wartość sprawdza się bardzo dobrze. Znam
poważne rozwiązania mailingowe, które odeszły od PG właśnie,
bo było za wolno. Dokładniej - jeżeli przepustowość ma większe
znaczenie niż czas odpowiedzi - rozwiązanie bazujące na wielu
węzłach będzie lepsze.

Jeżeli zmiany dotyczą pojedynczego dokumentu - można użyć, w
zasadzie dowolnego rozwiązania - np. taki redis udostępnia dane
jako json. Jak sprawy są bardziej skomplikowane neo4j. Sprawa
dalej jest skomplikowana, ale inne elementy zaczynają mieć
znaczenie. No, ale to już inna bajka.

Temat: PostreSQL - problem z indexami

Michał Z.:

Na szybko - zrobiłbym tak, żeby te pola text były na końcu. Wtedy
dostęp do małych pól będzie relatywnie szybki. Przenoszenie do

Michał, ale pola typu text są zawsze trzymane w TOAStach, więc nie ma znaczenia, czy są na początku, czy na końcu tabeli.

Temat: PostreSQL - problem z indexami

Daniel Podlejski:

Michał Z.:
Na szybko - zrobiłbym tak, żeby te pola text były na końcu. Wtedy
dostęp do małych pól będzie relatywnie szybki. Przenoszenie do

Michał, ale pola typu text są zawsze trzymane w TOAStach, więc nie ma znaczenia, czy są na początku, czy na końcu tabeli.

Założyłem tabelkę z dwiema kolumnami varchar, potem przemianowałem je na text. Statystyki pokazują zmiany w heap_blks_read | heap_blks_hit... Założyłem tabelę z dwiema kolumnami text - dalej strzały idą w heap. Dokumentacja twierdzi, że można tym sterować, nie ma nigdzie powiedziane, że text jest jakoś specjalnie traktowany. Może coś zmienili, ale od czasów, kiedy pracowaliśmy dla pewnego wydawnictwa wyglądało to tak jak napisałem... Sprawdzę jeszcze źródła, może coś więcej będę w stanie powiedzieć.

Temat: PostreSQL - problem z indexami

Masz rację - jednak nie zawsze. Zależy od długości danych i parametru storage dla kolumny.
(Co nie zmienia jednak faktu, że kolejność kolumn praktycznie nie ma znaczenia).Daniel Podlejski edytował(a) ten post dnia 23.05.12 o godzinie 19:13

Temat: PostreSQL - problem z indexami

Rzeczywiście - wiele to nie wniesie, bo baza i tak wyciągnie całą stronę...

Temat: PostreSQL - problem z indexami

Dlatego też wyniosłem ciężki content poza tą tabelkę, na której jest taki duży ruch.
Wszystkie operacje są związane z tą tabelą, ale niekoniecznie z tym contentem, więc nie ma sensu tego ciągnąć za każdym razem ;-)

Temat: PostreSQL - problem z indexami

Krzysztof Magosa:
Dlatego też wyniosłem ciężki content poza tą tabelkę, na której jest taki duży ruch.
Wszystkie operacje są związane z tą tabelą, ale niekoniecznie z tym contentem, więc nie ma sensu tego ciągnąć za każdym razem ;-)

Ma to sens, ale tylko, jeżeli wcześniejsze zapytania dotykały również tych "ciężkich danych". Jeżeli rekord nie mieści się na stronie - trzymane są na boku. W rekordzie wpisany jest namiar na te dane. Czyli, jeżeli się one nie zmieniają i ich nie wyciągamy - leżą sobie z boku, nietykane. Dlatego wydaje mi się, że prościej byłoby przejrzeć dao, czy jak to tam zostało zaprojektowane i zapewnić nietykanie tych ciężkich kolumn - jeżeli nie ma takiej potrzeby.
W szczegółach to wygląda tak, że dane, które się nie mieszczą mogą być kompresowane. Zawsze jednak są cięte - domyślnie na kawałki o wielkości 1/4 strony. I odkładane do tabeli systemowej - osobnej dla każdej tabeli, z kolumnami - identyfikator, numer kolejnego kawałka, dane. W rekordzie zostaje wskaźnik zawierający podstawowe informacje - jak identyfikator w tabeli systemowej, wielkość przed i po skompresowaniu - w sumie 20 bajtów. Więcej jest tu:
http://www.postgresql.org/docs/8.0/static/storage-toas...

Wracając do tematu... Te 20 bajtów stanowi obciążenie - jeżeli nie tykamy ciężkich danych. Można zmieniać, wtedy dodatkowe 20 bajtów na każdego tosta trzeba przepisać. Koszt w zasadzie żaden. Jak tykamy - trzeba to wszystko wydłubać, odpakować, przeprocesować, odesłać. Przeprocesowanie jest o tyle istotne, że każda sesja ma przewidzianą określoną ilość ramu na walkę z zapytaniami. Jak się nie mieści - lecimy na dysk i robi się wolno.