funkcja tabelaryczna input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Kolejnym antywzorem jest mikrodzielnie. Na przyk\u0142ad, musisz podzieli\u0107 dane i masz 5 serwer\u00f3w, a jutro b\u0119dzie 6 serwer\u00f3w. Zastanawiasz si\u0119, jak te dane przerebalansowa\u0107. Zamiast tego dzielisz je nie na 5 shard\u00f3w, a na 1 000 shard\u00f3w. A nast\u0119pnie przypisujesz ka\u017cdy z tych mikrodzielnik\u00f3w do oddzielnego serwera. I oka\u017ce si\u0119, \u017ce na jednym serwerze b\u0119dzie 200 ClickHouse, na przyk\u0142ad. Oddzielne instancje na oddzielnych portach lub oddzielne bazy danych. <\/p>\n
<\/p>\n
<\/p>\n
Ale w ClickHouse to nie jest zbyt dobre. Poniewa\u017c nawet jeden instancja ClickHouse stara si\u0119 wykorzysta\u0107 wszystkie dost\u0119pne zasoby serwera do przetwarzania jednego zapytania. Tzn. masz jaki\u015b serwer i na przyk\u0142ad 56 rdzeni procesora. Wykonujesz zapytanie, kt\u00f3re trwa jedn\u0105 sekund\u0119 i wykorzysta 56 rdzeni. A je\u015bli umie\u015bcisz tam 200 ClickHouse na jednym serwerze, to uruchomi si\u0119 10 000 w\u0105tk\u00f3w. W skr\u00f3cie, wszystko b\u0119dzie bardzo \u017ale.<\/p>\n
<\/p>\n
Innym powodem jest to, \u017ce rozk\u0142ad pracy pomi\u0119dzy te instancje b\u0119dzie nier\u00f3wnomierny. Niekt\u00f3re zako\u0144cz\u0105 wcze\u015bniej, inne p\u00f3\u017aniej. Gdyby wszystko dzia\u0142o si\u0119 w jednym instancji, to ClickHouse sam by sobie poradzi\u0142 z odpowiednim rozk\u0142adem danych pomi\u0119dzy w\u0105tki. <\/p>\n
<\/p>\n
I jeszcze jednym powodem jest to, \u017ce b\u0119dzie mi\u0119dzyprocesowa komunikacja przez TCP. Dane b\u0119d\u0105 musia\u0142y by\u0107 serializowane, deserializowane i to olbrzymia liczba mikrodzielnik\u00f3w. Po prostu b\u0119dzie to nieefektywne.<\/p>\n
<\/p>\n
<\/p>\n
Kolejnym antywzorem, cho\u0107 trudno go nazwa\u0107 antywzorem, jest du\u017ca liczba wst\u0119pnej agregacji.<\/p>\n
<\/p>\n
Og\u00f3lnie rzecz bior\u0105c, wst\u0119pna agregacja to co\u015b dobrego. Mia\u0142e\u015b miliard wierszy, zgrupowa\u0142e\u015b je i sta\u0142o si\u0119 1 000 wierszy, a teraz zapytanie wykonuje si\u0119 natychmiast. Wszystko jest wspania\u0142e. Mo\u017cna tak robi\u0107. A w tym celu nawet w ClickHouse jest specjalny typ tabeli AggregatingMergeTree, kt\u00f3ry wykonuje inkrementaln\u0105 agregacj\u0119 podczas wstawiania danych. <\/p>\n
<\/p>\n
S\u0105 jednak sytuacje, gdy my\u015blisz, \u017ce b\u0119dziemy agregowa\u0107 dane w ten spos\u00f3b i jeszcze tak. A w pewnym s\u0105siednim dziale, kt\u00f3rego nazwiska nie chc\u0119 podawa\u0107, u\u017cywaj\u0105 tabel SummingMergeTree do sumowania wed\u0142ug klucza g\u0142\u00f3wnego, u\u017cywaj\u0105c jako klucza g\u0142\u00f3wnego oko\u0142o 20 r\u00f3\u017cnych kolumn. Dla ostro\u017cno\u015bci zmieni\u0142em nazwy niekt\u00f3rych kolumn, ale wygl\u0105da to mniej wi\u0119cej tak.<\/p>\n
<\/p>\n
<\/p>\n
I pojawiaj\u0105 si\u0119 pewne problemy. Po pierwsze, obj\u0119to\u015b\u0107 danych nie zmniejsza si\u0119 zbytnio. Na przyk\u0142ad zmniejsza si\u0119 trzykrotnie. Trzykrotne zmniejszenie to by\u0142aby dobra cena, by pozwoli\u0107 sobie na nieograniczone mo\u017cliwo\u015bci analityki, kt\u00f3re pojawiaj\u0105 si\u0119, gdy dane nie s\u0105 agregowane. Je\u015bli dane s\u0105 agregowane, to zamiast analityki otrzymujesz jedynie marn\u0105 statystyk\u0119. <\/p>\n
<\/p>\n
Co szczeg\u00f3lnie irytuje? To, \u017ce ludzie z s\u0105siedniego dzia\u0142u przychodz\u0105 i czasami prosz\u0105 o dodanie jeszcze jednej kolumny do klucza g\u0142\u00f3wnego. Tzn. tak agregowali\u015bmy dane, a teraz chcemy troch\u0119 wi\u0119cej. Ale w ClickHouse nie ma mo\u017cliwo\u015bci zmiany klucza g\u0142\u00f3wnego. Dlatego trzeba pisa\u0107 jakie\u015b skrypty w C++. A ja nie lubi\u0119 skrypt\u00f3w, nawet je\u015bli s\u0105 w C++.<\/p>\n
<\/p>\n
Je\u015bli spojrzysz, do czego stworzono ClickHouse, to nieagregowane dane to dok\u0142adnie ten scenariusz, dla kt\u00f3rego zosta\u0142 stworzony. Je\u015bli u\u017cywasz ClickHouse do nieagregowanych danych, to robisz wszystko dobrze. Je\u015bli agregujesz, to to czasami mo\u017cna wybaczy\u0107. <\/p>\n
<\/p>\n
<\/p>\n
Jeszcze jeden interesuj\u0105cy przypadek \u2013 to zapytania w niesko\u0144czonej p\u0119tli. Czasem wchodz\u0119 na jaki\u015b serwer produkcyjny i patrz\u0119 na show processlist. I za ka\u017cdym razem odkrywam, \u017ce dzieje si\u0119 co\u015b strasznego. <\/p>\n
<\/p>\n
Na przyk\u0142ad co\u015b takiego. Od razu wida\u0107, \u017ce wszystko mog\u0142o by\u0107 wykonane w jednym zapytaniu. Wystarczy wpisa\u0107 tam url in i list\u0119.<\/p>\n
<\/p>\n
<\/p>\n
Dlaczego tak wiele zapyta\u0144 w niesko\u0144czonej p\u0119tli jest z\u0142e? Je\u015bli indeks nie jest u\u017cywany, b\u0119dzie wiele przej\u015b\u0107 przez te same dane. Ale je\u015bli indeks jest u\u017cywany, na przyk\u0142ad masz klucz g\u0142\u00f3wny wed\u0142ug ru i wpisujesz url = co\u015b tam. I my\u015blisz, \u017ce b\u0119dzie czytane punktowo z tabeli jeden url, wszystko b\u0119dzie w porz\u0105dku. Ale w rzeczywisto\u015bci nie. Poniewa\u017c ClickHouse robi to wszystko w paczkach. <\/p>\n
<\/p>\n
Kiedy potrzebuje odczyta\u0107 jaki\u015b zakres danych, odczytuje troch\u0119 wi\u0119cej, poniewa\u017c indeks w ClickHouse jest rozrzedzony. Ten indeks nie pozwala znale\u017a\u0107 w tabeli jednej pojedynczej linii, tylko jaki\u015b zakres. Dane s\u0105 kompresowane w blokach. Aby odczyta\u0107 jedn\u0105 lini\u0119, trzeba wzi\u0105\u0107 ca\u0142y blok i go rozpakowa\u0107. A je\u015bli wykonujesz wiele zapyta\u0144, b\u0119dziesz mia\u0142 wiele powt\u00f3rze\u0144 takich i mn\u00f3stwo pracy b\u0119dzie wykonywane raz po raz.<\/p>\n
<\/p>\n
<\/p>\n
Jako bonus mo\u017cna zauwa\u017cy\u0107, \u017ce w ClickHouse nie warto si\u0119 ba\u0107 przesy\u0142ania nawet megabajt\u00f3w, a nawet setek megabajt\u00f3w do sekcji IN. Pami\u0119tam z naszej praktyki, \u017ce je\u015bli w MySQL przesy\u0142amy mn\u00f3stwo warto\u015bci do sekcji IN, na przyk\u0142ad przesy\u0142amy tam 100 megabajt\u00f3w jakich\u015b liczb, to MySQL zu\u017cywa 10 gigabajt\u00f3w pami\u0119ci i nic wi\u0119cej si\u0119 nie dzieje, wszystko dzia\u0142a s\u0142abo. <\/p>\n
<\/p>\n
A drug\u0105 rzecz\u0105 jest to, \u017ce w ClickHouse, je\u015bli twoje zapytania wykorzystuj\u0105 indeks, to zawsze nie jest wolniejsze ni\u017c pe\u0142ne skanowanie, tzn. je\u015bli trzeba odczyta\u0107 prawie ca\u0142\u0105 tabel\u0119, b\u0119dzie to robi\u0142o sekwencyjnie i odczyta ca\u0142\u0105 tabel\u0119. W og\u00f3lnym uj\u0119ciu samo si\u0119 ogarnie.<\/p>\n
<\/p>\n
Jednak pojawiaj\u0105 si\u0119 pewne trudno\u015bci. Na przyk\u0142ad to, \u017ce IN z podzapytaniem nie wykorzystuje indeksu. Ale to nasz problem i musimy to naprawi\u0107. Nic fundamentalnego tutaj nie ma. B\u0119dziemy to naprawia\u0107. <\/p>\n
<\/p>\n
I jeszcze jedna ciekawa rzecz \u2013 to, \u017ce je\u015bli masz bardzo d\u0142ugie zapytanie i rozproszon\u0105 obr\u00f3bk\u0119 zapyta\u0144, to to bardzo d\u0142ugie zapytanie b\u0119dzie wysy\u0142ane do ka\u017cdego serwera bez kompresji. Na przyk\u0142ad, 100 megabajt\u00f3w i 500 serwer\u00f3w. I odpowiednio, przez sie\u0107 zostanie przes\u0142ane 50 gigabajt\u00f3w. Zostanie przes\u0142ane, a potem wszystko zostanie pomy\u015blnie wykonane.<\/p>\n
<\/p>\n
* ju\u017c u\u017cywa; wszystko naprawione, jak obiecano.<\/p>\n
<\/p>\n
<\/p>\n
I do\u015b\u0107 cz\u0119stym przypadkiem jest, gdy zapytania przychodz\u0105 z API. Na przyk\u0142ad, stworzy\u0142e\u015b jaki\u015b sw\u00f3j serwis. I je\u015bli tw\u00f3j serwis jest komu\u015b potrzebny, otworzy\u0142e\u015b API i dos\u0142ownie po dw\u00f3ch dniach widzisz, \u017ce dzieje si\u0119 co\u015b dziwnego. Wszystko jest przeci\u0105\u017cone i przychodz\u0105 jakie\u015b okropne zapytania, kt\u00f3re nigdy nie powinny by\u0142y si\u0119 pojawi\u0107. <\/p>\n
<\/p>\n
I rozwi\u0105zanie jest jedno. Je\u015bli otworzy\u0142e\u015b API, to b\u0119dziesz musia\u0142 wprowadzi\u0107 ograniczenia. Na przyk\u0142ad, wprowadzi\u0107 jakie\u015b kwoty. Innych normalnych opcji nie ma. W przeciwnym razie od razu napisz\u0105 skrypt i b\u0119d\u0105 problemy. <\/p>\n
<\/p>\n
W ClickHouse istnieje specjalna funkcja - to jest liczenie kwot. Mo\u017cna przekaza\u0107 w\u0142asny klucz kwoty, na przyk\u0142ad wewn\u0119trzny identyfikator u\u017cytkownika. Kwoty b\u0119d\u0105 liczone niezale\u017cnie dla ka\u017cdego z nich. <\/p>\n
<\/p>\n
<\/p>\n
Teraz jeszcze jedna interesuj\u0105ca rzecz. To replikacja na nap\u0119dzie r\u0119cznym. <\/p>\n
<\/p>\n
Znam wiele przypadk\u00f3w, kiedy, mimo \u017ce ClickHouse ma wbudowan\u0105 obs\u0142ug\u0119 replikacji, ludzie replikuj\u0105 ClickHouse r\u0119cznie.<\/p>\n
<\/p>\n
Jaki jest zasadniczy pomys\u0142? Macie pipeline do przetwarzania danych, kt\u00f3ry dzia\u0142a niezale\u017cnie, na przyk\u0142ad w r\u00f3\u017cnych centrach danych. Zapisujecie te same dane w ten sam spos\u00f3b do ClickHouse. Prawda jest taka, \u017ce praktyka pokazuje, i\u017c dane i tak b\u0119d\u0105 si\u0119 r\u00f3\u017cni\u0107 z powodu jakich\u015b specyficznych cech w waszym kodzie. Mam nadziej\u0119, \u017ce w waszym przypadku tak nie b\u0119dzie. <\/p>\n
<\/p>\n
I od czasu do czasu i tak b\u0119dziecie musieli zsynchronizowa\u0107 r\u0119cznie. Na przyk\u0142ad raz w miesi\u0105cu administratorzy wykonuj\u0105 rsync.<\/p>\n
<\/p>\n
W rzeczywisto\u015bci znacznie \u0142atwiej jest u\u017cy\u0107 wbudowanej replikacji ClickHouse. Ale mog\u0105 pojawi\u0107 si\u0119 pewne przeciwwskazania, poniewa\u017c do tego trzeba korzysta\u0107 z ZooKeeper. Nic z\u0142ego nie powiem o ZooKeeper, generalnie system dzia\u0142a, ale bywa, \u017ce ludzie go nie u\u017cywaj\u0105 z powodu fobii przed Java, poniewa\u017c ClickHouse to bardzo dobra system napisana w C++, z kt\u00f3rego mo\u017cna korzysta\u0107 bez problem\u00f3w. A ZooKeeper jest na Javie. I jako\u015b nie chce si\u0119 nawet na to patrze\u0107, wi\u0119c wtedy mo\u017cna u\u017cy\u0107 replikacji na nap\u0119dzie r\u0119cznym. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse to praktyczny system. Uwzgl\u0119dnia twoje potrzeby. Je\u015bli masz replikacj\u0119 na nap\u0119dzie r\u0119cznym, mo\u017cesz stworzy\u0107 tabel\u0119 rozproszon\u0105, kt\u00f3ra patrzy na twoje r\u0119czne repliki i automatycznie wykonuje failover mi\u0119dzy nimi. Istnieje nawet specjalna opcja, kt\u00f3ra pozwala unikn\u0105\u0107 fluktuacji, nawet je\u015bli twoje repliki systematycznie si\u0119 r\u00f3\u017cni\u0105.<\/p>\n
<\/p>\n
<\/p>\n
Mog\u0105 wyst\u0105pi\u0107 problemy, je\u015bli u\u017cywasz prymitywnych silnik\u00f3w tabel. ClickHouse to taka konstrukcja, kt\u00f3ra ma wiele r\u00f3\u017cnych silnik\u00f3w tabel. Do wszystkich powa\u017cnych przypadk\u00f3w, jak napisano w dokumentacji, u\u017cywaj tabel z rodziny MergeTree. A wszystkie inne - to tak, do wyj\u0105tkowych przypadk\u00f3w lub do test\u00f3w.<\/p>\n
<\/p>\n
W tabeli MergeTree nie jest konieczne, aby mie\u0107 jak\u0105\u015b dat\u0119 i czas. W ka\u017cdym razie mo\u017cesz z tego skorzysta\u0107. Je\u015bli nie ma daty i czasu, wpisz, \u017ce domy\u015blnie to rok 2000. To b\u0119dzie dzia\u0142a\u0107 i nie b\u0119dzie wymaga\u0107 zasob\u00f3w. <\/p>\n
<\/p>\n
W nowej wersji serwera mo\u017cna nawet okre\u015bli\u0107, \u017ce chcesz mie\u0107 niestandardowe partycjonowanie bez klucza partycji. To b\u0119dzie to samo. <\/p>\n
<\/p>\n
<\/p>\n
Z drugiej strony, mo\u017cna u\u017cywa\u0107 prymitywnych silnik\u00f3w tabel. Na przyk\u0142ad, za\u0142aduj dane raz i zobacz, pokr\u0119\u0107 i usu\u0144 je. Mo\u017cesz u\u017cywa\u0107 Log.<\/p>\n
<\/p>\n
Lub przechowywanie ma\u0142ych obj\u0119to\u015bci do przetwarzania po\u015bredniego \u2013 to StripeLog lub TinyLog.<\/p>\n
<\/p>\n
Mo\u017cna u\u017cywa\u0107 pami\u0119ci, je\u015bli obj\u0119to\u015b\u0107 danych jest ma\u0142a i po prostu co\u015b pokr\u0119\u0107 w pami\u0119ci operacyjnej. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse nie za bardzo lubi dane z nadmiern\u0105 normalizacj\u0105. <\/p>\n
<\/p>\n
Oto typowy przyk\u0142ad. To ogromna liczba URLi. W\u0142o\u017cy\u0142e\u015b je do s\u0105siedniej tabeli. A potem zdecydowa\u0142e\u015b si\u0119 na JOIN, ale to nie zadzia\u0142a, poniewa\u017c ClickHouse obs\u0142uguje tylko Hash JOIN. Je\u015bli brakuje pami\u0119ci operacyjnej dla du\u017cej ilo\u015bci danych, kt\u00f3re trzeba po\u0142\u0105czy\u0107, to JOIN nie b\u0119dzie mo\u017cliwy. <\/p>\n
<\/p>\n
Je\u015bli dane maj\u0105 du\u017c\u0105 kardynalno\u015b\u0107, to nie przejmuj si\u0119, przechowuj je w denormalizowanej formie, URL-e bezpo\u015brednio w g\u0142\u00f3wnej tabeli. <\/p>\n
<\/p>\n
* A teraz w ClickHouse jest r\u00f3wnie\u017c merge join, kt\u00f3ry dzia\u0142a w sytuacjach, gdy dane po\u015brednie nie mieszcz\u0105 si\u0119 w pami\u0119ci operacyjnej. Jednak jest to nieefektywne i zalecenie pozostaje w mocy.<\/p>\n
<\/p>\n
<\/p>\n
Jeszcze kilka przyk\u0142ad\u00f3w, ale ju\u017c mam w\u0105tpliwo\u015bci, czy s\u0105 one antywzorcowe. <\/p>\n
<\/p>\n
ClickHouse ma jeden znany minus. Nie obs\u0142uguje aktualizacji. W pewnym sensie to nawet dobrze. Je\u015bli masz jakie\u015b wa\u017cne dane, na przyk\u0142ad ksi\u0119gowo\u015b\u0107, nikt ich nie wy\u015ble, poniewa\u017c nie ma aktualizacji.<\/p>\n
<\/p>\n
* Od d\u0142u\u017cszego czasu dodano obs\u0142ug\u0119 aktualizacji i usuwania w trybie wsadowym.<\/p>\n
<\/p>\n
S\u0105 jednak pewne specjalne sposoby, kt\u00f3re pozwalaj\u0105 na aktualizacje jakby w tle. Na przyk\u0142ad, tabele typu ReplaceMergeTree. Dokonuj\u0105 aktualizacji podczas t\u0142a \u0142\u0105cz\u0105cego. Mo\u017cesz to wymusi\u0107 za pomoc\u0105 optymalizacji tabeli. Ale nie r\u00f3b tego za cz\u0119sto, poniewa\u017c b\u0119dzie to pe\u0142ne przepisanie partycji. <\/p>\n
<\/p>\n
Rozproszone JOIN w ClickHouse r\u00f3wnie\u017c s\u0105 \u017ale obs\u0142ugiwane przez planner zapyta\u0144. <\/p>\n
<\/p>\n
\u0179le, ale czasem w porz\u0105dku.<\/p>\n
<\/p>\n
U\u017cywanie ClickHouse tylko po to, aby odczyta\u0107 dane z powrotem za pomoc\u0105 select.<\/p>\n
<\/p>\n
Nie poleca\u0142bym u\u017cywania ClickHouse do rozbudowanych oblicze\u0144. Ale to nie do ko\u0144ca prawda, poniewa\u017c ju\u017c odchodzimy od tej rekomendacji. Ostatnio dodali\u015bmy mo\u017cliwo\u015b\u0107 stosowania modeli uczenia maszynowego w ClickHouse \u2013 Catboost. To mnie martwi, bo my\u015bl\u0119 sobie: \u201eJaki straszny widok. Ile\u017c to cykli na bajt!\u201d. Bardzo mi \u017cal wydawa\u0107 cykle na bajty. <\/p>\n
<\/p>\n
<\/p>\n
Ale nie b\u00f3jcie si\u0119, instalujcie ClickHouse, wszystko b\u0119dzie dobrze. W razie czego, mamy spo\u0142eczno\u015b\u0107. A tak przy okazji, spo\u0142eczno\u015b\u0107 to wy. I je\u015bli macie jakie\u015b problemy, mo\u017cecie przynajmniej zajrze\u0107 na nasz czat, i mam nadziej\u0119, \u017ce wam pomog\u0105. <\/p>\n
<\/p>\n
Pytania<\/p>\n
<\/p>\n
Dzi\u0119kuj\u0119 za prezentacj\u0119! Gdzie mog\u0119 zg\u0142osi\u0107 awari\u0119 ClickHouse?<\/em><\/p>\n<\/p>\n
Mo\u017cecie zg\u0142asza\u0107 to do mnie osobi\u015bcie ju\u017c teraz. <\/p>\n
<\/p>\n
Niedawno zacz\u0105\u0142em u\u017cywa\u0107 ClickHouse. Od razu pad\u0142 interfejs cli.<\/em><\/p>\n<\/p>\n
Mia\u0142e\u015b szcz\u0119\u015bcie. <\/p>\n
<\/p>\n
Chwil\u0119 p\u00f3\u017aniej r\u00f3wnie\u017c zniszczy\u0142em serwer ma\u0142ym selectem.<\/em><\/p>\n<\/p>\n
Masz talent. <\/p>\n
<\/p>\n
Zg\u0142osi\u0142em b\u0142\u0105d na GitHubie, ale go zignorowano.<\/em> <\/p>\n<\/p>\n
Zobaczymy. <\/p>\n
<\/p>\n
Aleksiej oszuka\u0142 mnie, \u017ceby zaci\u0105gn\u0105\u0107 na prezentacj\u0119, obiecuj\u0105c opowiedzie\u0107, jak kompresujecie dane wewn\u0119trznie.<\/em><\/p>\n<\/p>\n
Bardzo prosto. <\/p>\n
<\/p>\n
To zrozumia\u0142em ju\u017c wczoraj. Potrzebuj\u0119 wi\u0119cej konkret\u00f3w.<\/em> <\/p>\n<\/p>\n
Nie ma tam \u017cadnych strasznych sztuczek. To po prostu kompresja po blokach. Domy\u015blnie u\u017cywa si\u0119 LZ4, ale mo\u017cna w\u0142\u0105czy\u0107 ZSTD*. Bloki maj\u0105 od 64 kilobajt\u00f3w do 1 megabajta.<\/p>\n
<\/p>\n
* istnieje r\u00f3wnie\u017c wsparcie dla wyspecjalizowanych kodek\u00f3w kompresji, kt\u00f3re mo\u017cna u\u017cywa\u0107 w \u0142a\u0144cuchu z innymi algorytmami.<\/p>\n
<\/p>\n
W blokach s\u0105 po prostu surowe dane?<\/em><\/p>\n<\/p>\n
Nie do ko\u0144ca surowe. S\u0105 tam tablice. Je\u015bli macie kolumn\u0119 liczbow\u0105, to liczby s\u0105 u\u0142o\u017cone kolejno w tablicy. <\/p>\n
<\/p>\n
Rozumiem.<\/em> <\/p>\n<\/p>\n
Aleksiej, przyk\u0142ad, kt\u00f3ry mia\u0142e\u015b z uniqExact nad adresami IP, to znaczy, \u017ce uniqExact jest wolniejszy dla ci\u0105g\u00f3w ni\u017c dla liczb itd. A co je\u015bli zastosujemy sztuczk\u0119 i przekonwertujemy w momencie odczytu? To znaczy, wydaje mi si\u0119, \u017ce m\u00f3wili\u015bcie, \u017ce na dysku to nie r\u00f3\u017cni si\u0119 zbytnio. Je\u015bli b\u0119dziemy czyta\u0107 z dysku ci\u0105gi, konwertowa\u0107, to wtedy nasze agregaty b\u0119d\u0105 szybsze, czy nie? A mo\u017ce jednak nieznacznie zyskamy? Wydaje mi si\u0119, \u017ce testowali\u015bcie to, ale jako\u015b nie zaznaczyli\u015bcie w benchmarkach.<\/em> <\/p>\n<\/p>\n
My\u015bl\u0119, \u017ce b\u0119dzie to wolniejsze ni\u017c bez kasty. W takim przypadku trzeba sparsowa\u0107 adres IP z ci\u0105gu. Oczywi\u015bcie, w ClickHouse r\u00f3wnie\u017c mamy zoptymalizowane parsowanie adres\u00f3w IP. Bardzo si\u0119 starali\u015bmy, ale macie tam liczby zapisane w formie dziesi\u0119ciotysi\u0119cznej. Bardzo niewygodne. Z drugiej strony funkcja uniqExact b\u0119dzie dzia\u0142a\u0107 na ci\u0105gach wolniej nie tylko dlatego, \u017ce to ci\u0105gi, ale tak\u017ce dlatego, \u017ce wybierana jest inna specjalizacja algorytmu. Ci\u0105gi po prostu s\u0105 przetwarzane inaczej.<\/p>\n
<\/p>\n
A co, je\u015bli we\u017amiemy bardziej prymitywny typ danych? Na przyk\u0142ad, zapisali\u015bmy user id, kt\u00f3ry mamy w, zapisali\u015bmy go jako ci\u0105g, a potem go skastowali\u015bmy, czy b\u0119dzie to lepsze, czy nie?<\/em><\/p>\n<\/p>\n
W\u0105tpi\u0119. My\u015bl\u0119, \u017ce b\u0119dzie nawet gorzej, poniewa\u017c parsowanie liczb to powa\u017cny problem. Wydaje mi si\u0119, \u017ce ten kolega mia\u0142 nawet prezentacj\u0119 na temat trudno\u015bci w parsowaniu liczb w formie dziesi\u0119ciotysicznej, a mo\u017ce i nie. <\/p>\n
<\/p>\n
Alieksei, bardzo dzi\u0119kuj\u0119 za prezentacj\u0119! I jeszcze raz dzi\u0119kuj\u0119 za ClickHouse! Mam pytanie dotycz\u0105ce plan\u00f3w. Czy jest planowana funkcja aktualizacji s\u0142ownik\u00f3w nie w ca\u0142o\u015bci?<\/em><\/p>\n<\/p>\n
Tzn. cz\u0119\u015bciowe prze\u0142adowanie?<\/p>\n
<\/p>\n
Tak-tak. Typu mo\u017cliwo\u015b\u0107 ustawienia tam pola MySQL, tzn. aktualizowa\u0107 po, aby \u0142adowa\u0107 tylko te dane, je\u015bli s\u0142ownik jest bardzo du\u017cy.<\/em><\/p>\n<\/p>\n
Bardzo interesuj\u0105ca funkcja. Wydaje mi si\u0119, \u017ce jaka\u015b osoba proponowa\u0142a j\u0105 na naszym czacie. Mo\u017ce to nawet by\u0142e\u015b ty. <\/p>\n
<\/p>\n
Nie s\u0105dz\u0119, \u017cebym to by\u0142 ja.<\/em><\/p>\n<\/p>\n
\u015awietnie, teraz wychodzi, \u017ce s\u0105 dwa zapytania. I mo\u017cna powoli zaczyna\u0107 to robi\u0107. Ale od razu chc\u0119 was ostrzec, \u017ce ta funkcja jest do\u015b\u0107 prosta do zaimplementowania. Tzn. w zasadzie trzeba po prostu zapisa\u0107 w tabeli numer wersji i pisa\u0107: wersja jest mniejsza ni\u017c taka. A to oznacza, \u017ce najprawdopodobniej zaproponujemy to zrobi\u0107 entuzjastom. Czy jeste\u015b entuzjast\u0105? <\/p>\n
<\/p>\n
Tak, ale niestety nie w C++.<\/em><\/p>\n<\/p>\n
Czy wasi koledzy potrafi\u0105 pisa\u0107 w C++? <\/p>\n
<\/p>\n
Zaraz kogo\u015b znajd\u0119.<\/em><\/p>\n<\/p>\n
\u015awietnie*.<\/p>\n
<\/p>\n
* mo\u017cliwo\u015b\u0107 zosta\u0142a dodana dwa miesi\u0105ce po prezentacji \u2013 zosta\u0142a opracowana przez autora pytania i przes\u0142ana pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Dzi\u0119kuj\u0119!<\/em><\/p>\n<\/p>\n
Cze\u015b\u0107! Dzi\u0119kuj\u0119 za prezentacj\u0119! Wspomina\u0142e\u015b, \u017ce ClickHouse bardzo dobrze wykorzystuje wszystkie dost\u0119pne mu zasoby. A prelegent obok z Luxoft m\u00f3wi\u0142 o swoim rozwi\u0105zaniu dla Poczty Rosyjskiej. Powiedzia\u0142, \u017ce bardzo im si\u0119 spodoba\u0142 ClickHouse, ale nie u\u017cyli go zamiast swojego g\u0142\u00f3wnego konkurenta, w\u0142a\u015bnie dlatego, \u017ce zu\u017cywa\u0142 ca\u0142y procesor. I nie mogli go w\u0142\u0105czy\u0107 w swoj\u0105 architektur\u0119, w swojego ZooKeepera z dockerami. Czy jest mo\u017cliwo\u015b\u0107 jako\u015b ograniczy\u0107 ClickHouse, aby nie zu\u017cywa\u0142 wszystkiego, co mu si\u0119 udost\u0119pnia?<\/em><\/p>\n<\/p>\n
Tak, mo\u017cna to zrobi\u0107 i jest to bardzo proste. Je\u015bli chcesz, aby u\u017cywa\u0142 mniej rdzeni, napisz po prostu set max_threads = 1<\/code>. I wszystko, b\u0119dzie wykonywa\u0142 zapytania na jednym rdzeniu. Mo\u017cna zreszt\u0105 r\u00f3\u017cnym u\u017cytkownikom ustawi\u0107 r\u00f3\u017cne te parametry. Wi\u0119c nie ma problemu. A kolegom z Luxoft przeka\u017c, \u017ce nie dobrze, \u017ce nie znale\u017ali tej opcji w dokumentacji. <\/p>\n<\/p>\n
Aleksiej, cze\u015b\u0107! Chcia\u0142em zada\u0107 takie pytanie. Ju\u017c nie po raz pierwszy s\u0142ysz\u0119, \u017ce wielu zaczyna u\u017cywa\u0107 ClickHouse jako magazyn na logi. Na prezentacji m\u00f3wi\u0142e\u015b, \u017ceby tego nie robi\u0107, tzn. nie nale\u017cy przechowywa\u0107 d\u0142ugich linii. Jak si\u0119 do tego odnosisz?<\/em><\/p>\n<\/p>\n
Po pierwsze, logi to z regu\u0142y nie s\u0105 d\u0142ugie linie. Oczywi\u015bcie bywaj\u0105 wyj\u0105tki. Na przyk\u0142ad, jaki\u015b serwis pisany w javie, zg\u0142asza wyj\u0105tek, kt\u00f3ry jest logowany. I tak w niesko\u0144czonej p\u0119tli, i ko\u0144czy si\u0119 miejsce na dysku twardym. Rozwi\u0105zanie jest bardzo proste. Je\u015bli linie s\u0105 bardzo d\u0142ugie, to je tnij. A co to znaczy d\u0142ugie? Dziesi\u0105tki kilobajt\u00f3w \u2013 to \u017ale.<\/p>\n
<\/p>\n
* w najnowszych wersjach ClickHouse wprowadzono \"adaptacyjne granulowanie indeks\u00f3w\", co w du\u017cej mierze rozwi\u0105zuje problem przechowywania d\u0142ugich \u0142a\u0144cuch\u00f3w.<\/p>\n
<\/p>\n
A kilobajt \u2013 to w porz\u0105dku?<\/em><\/p>\n<\/p>\n
W porz\u0105dku. <\/p>\n
<\/p>\n
Cze\u015b\u0107! Dzi\u0119kuj\u0119 za prezentacj\u0119! Ju\u017c o to pyta\u0142em na czacie, ale nie pami\u0119tam, czy otrzyma\u0142em odpowied\u017a. Czy planuje si\u0119 jako\u015b rozszerzy\u0107 sekcj\u0119 WITH na wz\u00f3r CTE?<\/em><\/p>\n<\/p>\n
Na razie nie. Sekcja WITH to dla nas co\u015b niezbyt powa\u017cnego. To dla nas taka ma\u0142a funkcja.<\/p>\n
<\/p>\n
Rozumiem. Dzi\u0119kuj\u0119!<\/em><\/p>\n<\/p>\n
Dzi\u0119kuj\u0119 za prezentacj\u0119! Bardzo interesuj\u0105co! Mam globalne pytanie. Czy planujecie mo\u017ce wprowadzenie jakich\u015b mechanizm\u00f3w do usuwania danych?<\/em><\/p>\n<\/p>\n
Oczywi\u015bcie. To nasze pierwsze zadanie w kolejce. Aktualnie intensywnie my\u015blimy, jak wszystko zrobi\u0107 poprawnie. I czas zacz\u0105\u0107 stuka\u0107 w klawiatur\u0119.<\/p>\n
<\/p>\n
* naciskali\u015bmy przyciski na klawiaturze i wszystko zrobili\u015bmy.<\/p>\n
<\/p>\n
Czy to wp\u0142ynie jako\u015b na wydajno\u015b\u0107 systemu? Czy wstawianie b\u0119dzie tak samo szybkie, jak teraz?<\/em><\/p>\n<\/p>\n
Mo\u017cliwe, \u017ce same usuni\u0119cia i aktualizacje b\u0119d\u0105 bardzo ci\u0119\u017ckie, ale nie wp\u0142ynie to na wydajno\u015b\u0107 zapyta\u0144 selektywnych i wstawianie.<\/p>\n
<\/p>\n
I jeszcze jedno ma\u0142e pytanie. Na prezentacji m\u00f3wi\u0142e\u015b o kluczu g\u0142\u00f3wnym. Mamy zatem partycjonowanie, kt\u00f3re jest domy\u015blnie miesi\u0119czne, prawda? Kiedy okre\u015blamy zakres dat, kt\u00f3ry mie\u015bci si\u0119 w miesi\u0105cu, to odczytywana jest tylko ta partycja, prawda?<\/em><\/p>\n<\/p>\n
Tak.<\/p>\n
<\/p>\n
Takie pytanie. Je\u015bli nie mo\u017cemy wydzieli\u0107 \u017cadnego klucza g\u0142\u00f3wnego, to czy s\u0142usznie by\u0142oby zrobi\u0107 go na podstawie pola \u201eData\u201d, aby w tle by\u0142a mniejsza reorganizacja tych danych, by by\u0142y uporz\u0105dkowane? Je\u017celi nie masz zapyta\u0144 zakresowych i nie mo\u017cesz wybra\u0107 \u017cadnego klucza g\u0142\u00f3wnego, czy warto umie\u015bci\u0107 dat\u0119 w kluczu g\u0142\u00f3wnym?<\/em><\/p>\n<\/p>\n
Tak.<\/p>\n
<\/p>\n
Mo\u017ce warto umie\u015bci\u0107 w kluczu g\u0142\u00f3wnym takie pole, po kt\u00f3rym dane b\u0119d\u0105 lepiej si\u0119 kompresowa\u0107, je\u015bli b\u0119d\u0105 posortowane wed\u0142ug tego pola. Na przyk\u0142ad, identyfikator u\u017cytkownika. U\u017cytkownik, na przyk\u0142ad, odwiedza t\u0119 sam\u0105 stron\u0119. W tym przypadku umieszczasz ID u\u017cytkownika i czas. Wtedy dane b\u0119d\u0105 lepiej si\u0119 kompresowa\u0107. Je\u017celi chodzi o dat\u0119, je\u015bli naprawd\u0119 nie masz i nigdy nie masz zapyta\u0144 zakresowych po datach, to mo\u017cesz nie umieszcza\u0107 daty w kluczu g\u0142\u00f3wnym. <\/p>\n
<\/p>\n
Dzi\u0119kuj\u0119 bardzo!<\/em><\/p>\n\u0179r\u00f3d\u0142o: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Efektywne](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n