{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Oszcz\u0119dzamy kilka groszy przy du\u017cych ilo\u015bciach w PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kontynuuj\u0105c temat zapisu du\u017cych strumieni danych, poruszony w poprzednim artykule na temat partycjonowania<\/a><\/noindex>, w tym przyjrzymy si\u0119 sposobom, dzi\u0119ki kt\u00f3rym mo\u017cna zmniejszy\u0107 \u201efizyczny\u201d rozmiar przechowywanych<\/b> w PostgreSQL oraz ich wp\u0142yw na wydajno\u015b\u0107 serwera.<\/p>\n

B\u0119dzie mowa o ustawieniach TOAST i wyr\u00f3wnaniu danych<\/b>. \u201e\u015arednio\u201d te metody pozwol\u0105 zaoszcz\u0119dzi\u0107 niewiele zasob\u00f3w, ale \u2014 ca\u0142kowicie bez modyfikacji kodu aplikacji.<\/p>\n

\"Oszcz\u0119dzamy
\nJednak nasze do\u015bwiadczenia okaza\u0142y si\u0119 do\u015b\u0107 owocne w tym zakresie, poniewa\u017c przechowalnia prawie ka\u017cdego monitoringu z natury jest w du\u017cej cz\u0119\u015bci append-only<\/b> z punktu widzenia zapisywanych danych. A je\u015bli chcesz wiedzie\u0107, jak mo\u017cna nauczy\u0107 baz\u0119 pisa\u0107 na dysk z pr\u0119dko\u015bci\u0105 200MB\/s<\/b> znacznie mniejsz\u0105 \u2014 zapraszam pod tekst.
\n<\/a><\/noindex><\/p>\n

Ma\u0142e sekrety du\u017cych danych<\/h2>\n

\nW profilu dzia\u0142ania naszej us\u0142ugi<\/a><\/noindex>, regularnie wp\u0142ywaj\u0105 do nas z log\u00f3w pakiety tekstowe<\/b>.<\/p>\n

A poniewa\u017c kompleks SBiS<\/a><\/noindex>, kt\u00f3rych bazy danych monitorujemy, to produkt wielokomponentowy o z\u0142o\u017conych strukturach danych, to i zapytania w celu osi\u0105gni\u0119cia maksymalnej wydajno\u015bci<\/b> okazuj\u0105 si\u0119 ca\u0142kiem \u201ewielotomowe\u201d z z\u0142o\u017con\u0105 logik\u0105 algorytmiczn\u0105<\/a><\/noindex>. Dlatego obj\u0119to\u015b\u0107 ka\u017cdego pojedynczego wyst\u0105pienia zapytania lub planu wykonania w nap\u0142ywaj\u0105cych do nas logach okazuje si\u0119 \u201e\u015brednio\u201d wystarczaj\u0105co du\u017ca.<\/p>\n

Przyjrzyjmy si\u0119 strukturze jednej z tabel, do kt\u00f3rej zapisujemy \u201esurowe\u201d dane \u2014 czyli oryginalny tekst z zapisu logu:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- klucz sekcji\n    date\n, data -- najwa\u017cniejsze\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nTypowa taka tabelka (ju\u017c partycjonowana, oczywi\u015bcie, dlatego to jest wz\u00f3r sekcji), gdzie najwa\u017cniejszy jest tekst. Czasami do\u015b\u0107 obszerna.<\/p>\n
Przypomnijmy, \u017ce \u201efizyczny\u201d rozmiar jednego rekordu w PG nie mo\u017ce zajmowa\u0107 wi\u0119cej ni\u017c jedna strona danych, ale \u201elogiczny\u201d rozmiar \u2014 to zupe\u0142nie inna sprawa. Aby zapisa\u0107 w polu obszerne warto\u015bci (varchar\/text\/bytea) u\u017cywana jest technologia TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL u\u017cywa sta\u0142ego rozmiaru strony (zwykle 8 KB) i nie pozwala na zajmowanie przez krotki kilku stron. Dlatego bezpo\u015brednie przechowywanie bardzo du\u017cych warto\u015bci p\u00f3l jest niemo\u017cliwe. Aby przezwyci\u0119\u017cy\u0107 to ograniczenie, du\u017ce warto\u015bci p\u00f3l s\u0105 kompresowane i\/lub dzielone na kilka fizycznych wierszy. Dzieje si\u0119 to niespostrzegalnie dla u\u017cytkownika i ma niewielki wp\u0142yw na wi\u0119kszo\u015b\u0107 kodu serwera. Metoda ta znana jest jako TOAST ...<\/p><\/blockquote>\n
\nW rzeczywisto\u015bci dla ka\u017cdej tabeli z \"potencjalnie du\u017cymi\" polami automatycznie tworzona jest partneruj\u0105ca tabela z \"krojeniem\"<\/a><\/noindex> ka\u017cdego \"du\u017cego\" rekordu w segmentach po 2KB:<\/p>\n
TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nOznacza to, \u017ce je\u015bli musimy zapisa\u0107 wiersz z \"du\u017c\u0105\" warto\u015bci\u0105 data<\/code>, to rzeczywisty zapis nast\u0105pi nie tylko w g\u0142\u00f3wnej tabeli i jej kluczu g\u0142\u00f3wnym, ale r\u00f3wnie\u017c w TOAST i jej kluczu g\u0142\u00f3wnym<\/b>.<\/p>\n
Zmniejszamy wp\u0142yw TOAST<\/h4>\n
\nAle wi\u0119kszo\u015b\u0107 naszych zapis\u00f3w jest wci\u0105\u017c nie tak wielka, powinny si\u0119 zmie\u015bci\u0107 w 8KB<\/b> \u2014 jak tu zaoszcz\u0119dzi\u0107?..<\/p>\n
Tutaj z pomoc\u0105 przychodzi atrybut STORAGE<\/code><\/a><\/noindex> w kolumnie tabeli:<\/p>\n
\n