пропозиції роботи
konto usunięte
Temat: MySQL vs PostgreSQL
Łukasz Dudek:
Michał Z.:
Tak, jest bufor, ale... lepiej go nie używać. :) shared buffers najlepiej trzymać na niskim poziomie. Chodzi o to, że tam są te same dane, co system trzyma w swoich buforach dyskowych. Czyli tracimy ram, ale to nie problem. Jest gorszy. Jak przychodzi flush - dane są przewalane "w tę i we wtę" - i to jest masakra. Ostatnio jak poprawili checki jest lepiej, ale to dalej zły pomysł. Inna odpowiedź jest taka: system operacyjny radzi sobie z buforowaniem danych bardzo dobrze - po co wynajdować to koło drugi raz? A no po to, żeby zrobić cluster... Ale to inna bajka.
shared_buffers ustawia się pod konkretną sytuacje raz daje się daje dużo a raz mało . Po za tym jako jest coś takiego jak effective_cache_size.
Tak to mniej - więcej wygląda.
Bufory postgresa działają jakoś tak:
Zapytanie chce dane - sprawdza w buforach, jak nie ma - żądanie trafia do systemu. Tam sprawdzany jest bufor systemowy, jak tam nie ma - idzie zapytanie do sprzętu. Zmiany. PG zmienia dane w swoich buforach. Jak w buforach nie ma miejsca dane trafiają do bufora systemu. PG co jakiś czas robi tzw. checka. Czyli wymusza spójność tego co jest w ramie z tym co jest w tabelach na dysku. Robi to, żeby wiedzieć od kiedy ma odtwarzać z logów transakcyjnych w przypadku padu.
No w każdym razie - jak jest duży bufor i masa zmian w nim. Wtedy wszystkie muszą zostać wypchnięte do systemu i dalej do sprzętu. Chodzi o to, że system robi to lepiej. Jak zrobi się mały bufor to dane będą latały w obie strony między buforami. Tyle, że to nie jest problem, bo procesor w bazach danych raczej się nie przemęcza. RAM za to jest bardzo potrzebny. Można optymalizować, ale są obszary, które bardziej potrzebują optymalizacji.
Podsumowując. Warto podać sensowny "effective cache size" - tak, żeby baza wybierała dobre plany wykonania zapytań. Bufory warto zostawić na niskim poziomie, chyba, że procesor ma z tym problem...
Acha. Poprzednie wersje PG robiły checka - dość nachalnie. Było tak, że baza rzucała wszystko i przerzucała dane. Teraz w logach oznacza, że proces synchronizacji się zaczął a potem, że się skończył. W sensie baza może spokojnie sobie zrzucać dane. Z punktu widzenia odtwarzania po padzie - ważne jest od kiedy ma zacząć. Sam proces może trwać, zwłaszcza jeżeli jest kosztowny.
Ale racja postgres ma baardzo ubogie możliwość zarządzania pamięcią, Przyładowo w ASE można wydzielac do osobnych cache tabele/indeksy/tabelspaceOj, tak.
Rozwiązania - np. pgBouncer, pgPool. Udostępniają interfejs jak "normalny" PG, ale np. pierwszy używa ePoola. Z tego wynika, że problemy są dwa - pierwszy jest taki, że nie jest to do końca zgodne ze standardowym rozwiązaniem - np. statystyki używają pidów. Drugi problem to to, że epool użyje max jednego rdzenia.
O jakich statystykach mówisz ?
Bardziej bolesnym skutkiem procesowości postgresa to brak triggeró asynchronicznych, oraz partycjonowania zapytań.
Wszędzie, gdzie jest pid. Jak mam ustalić który z programistów właśnie zabija bazę testową... Czasem lepiej mieć wszystko w garści. Czasem końcówek jest masa i ciężko się zorientować co się dzieje. Pół biedy - jak mogę sprawdzić, bo połączenie żyje. Wsteczne ustalenie co się stało - jest bardziej skomplikowane.
Najlepszego w Nowym Roku.
