W kwietniu inżynierowie Avito spotkali się online z głównym programistą ClickHouse Aleksiejem Milovidowem i Kirillem Szwakowem, programistą Golang z Integros. Omówiliśmy, w jaki sposób korzystamy z systemu zarządzania bazami danych i jakie napotykamy trudności.
Na podstawie spotkania przygotowaliśmy artykuł z odpowiedziami ekspertów na pytania nasze i czytelników dotyczące tworzenia kopii zapasowych, reshardingu danych, zewnętrznych słowników, sterownika Golang i aktualizacji wersji ClickHouse. Może być przydatny dla programistów, którzy już aktywnie pracują z Yandex DBMS i są zainteresowani jego teraźniejszością i przyszłością. Domyślnie odpowiedzi udziela Aleksiej Milovidov, chyba że napisano inaczej.
Uważaj, pod nacięciem znajduje się dużo tekstu. Mamy nadzieję, że treść zawierająca pytania ułatwi Państwu nawigację.
Zawartość
Jeśli nie chcesz czytać tekstu, możesz obejrzeć nagranie spotkań . Kody czasowe znajdują się w pierwszym komentarzu pod filmem.
ClickHouse jest stale aktualizowany, ale nasze dane nie. Co z tym zrobić?
ClickHouse jest na bieżąco aktualizowany, a nasze dane, które zostały zoptymalizowane i ostatecznie przetworzone, nie są aktualizowane i znajdują się w kopii zapasowej.
Załóżmy, że mieliśmy jakiś problem i dane zostały utracone. Zdecydowaliśmy się na przywrócenie i okazało się, że stare partycje, które są przechowywane na serwerach kopii zapasowych, bardzo różnią się od obecnie używanej wersji ClickHouse. Co zrobić w takiej sytuacji i czy jest to możliwe?
Niemożliwa jest sytuacja, w której przywróciłeś dane z kopii zapasowej w starym formacie, ale nie łączy się ona z nową wersją. Dbamy o to, aby format danych w ClickHouse był zawsze kompatybilny wstecz. Jest to o wiele ważniejsze niż kompatybilność wsteczna funkcjonalności, jeśli zmieniło się zachowanie jakiejś rzadko używanej funkcji. Nowa wersja ClickHouse powinna zawsze móc odczytać dane zapisane na dysku. Takie jest prawo.
Jakie są aktualne najlepsze praktyki tworzenia kopii zapasowych danych z ClickHouse?
Jak zrobić kopie zapasowe, biorąc pod uwagę, że mamy zoptymalizowane operacje końcowe, ogromną terabajtową bazę danych i dane, które są aktualizowane powiedzmy przez ostatnie trzy dni, a potem nie dzieją się z nimi żadne procedury?
Możemy stworzyć własne rozwiązanie i napisać na bashu: zbierz te kopie zapasowe w taki a taki sposób. Może nie trzeba niczego podpierać, a rower wynaleziono dawno temu?
Zacznijmy od najlepszych praktyk. Moi koledzy zawsze radzą, w odpowiedzi na pytania dotyczące kopii zapasowych, aby przypominali im o usłudze Yandex.Cloud, w której ten problem został już rozwiązany. Więc korzystaj z niego, jeśli to możliwe.
Nie ma kompletnego rozwiązania do tworzenia kopii zapasowych, w stu procentach wbudowanego w ClickHouse. Istnieje kilka pustych miejsc, które można wykorzystać. Aby uzyskać kompletne rozwiązanie, będziesz musiał albo trochę majstrować ręcznie, albo utworzyć opakowania w formie skryptów.
Zacznę od najprostszych rozwiązań, a zakończę na najbardziej wyrafinowanych, w zależności od ilości danych i wielkości klastra. Im większy klaster, tym bardziej złożone staje się rozwiązanie.
Jeśli tabela z danymi zajmuje tylko kilka gigabajtów, kopię zapasową można wykonać w następujący sposób:
- Zapisz definicję tabeli, tj. metadane − pokaż utwórz tabelę.
- Zrób zrzut za pomocą klienta ClickHouse - wybierać * ze stołu do pliku. Domyślnie otrzymasz plik w formacie TabSeparated. Jeśli chcesz być bardziej wydajny, możesz to zrobić w formacie natywnym.
Jeśli ilość danych jest większa, kopia zapasowa zajmie więcej czasu i zajmie dużo miejsca. Nazywa się to logiczną kopią zapasową i nie jest powiązana z formatem danych ClickHouse. Jeśli tak, w ostateczności możesz wykonać kopię zapasową i przesłać ją do MySQL w celu odzyskania.
W bardziej zaawansowanych przypadkach ClickHouse posiada wbudowaną możliwość tworzenia migawki partycji w lokalnym systemie plików. Ta funkcja jest dostępna na żądanie zmień tabelę zamrożenia partycji. Lub po prostu zmień zamrożenie tabeli - to jest migawka całej tabeli.
Migawka zostanie utworzona spójnie dla jednej tabeli na jednym shardze, czyli nie da się w ten sposób stworzyć spójnej migawki całego klastra. Jednak w przypadku większości zadań nie ma takiej potrzeby i wystarczy wykonać żądanie na każdym fragmencie i uzyskać spójną migawkę. Jest tworzony w formie twardych linków i dlatego nie zajmuje dodatkowej przestrzeni. Następnie skopiuj tę migawkę na serwer kopii zapasowych lub do magazynu używanego do tworzenia kopii zapasowych.
Przywracanie takiej kopii zapasowej jest dość łatwe. Najpierw utwórz tabele, korzystając z istniejących definicji tabel. Następnie skopiuj zapisane migawki partycji do katalogu Detached dla tych tabel i uruchom zapytanie dołącz partycję. To rozwiązanie jest całkiem odpowiednie dla najpoważniejszych ilości danych.
Czasami potrzebujesz czegoś jeszcze fajniejszego - w przypadkach, gdy masz dziesiątki, a nawet setki terabajtów na każdym serwerze i setkach serwerów. Jest tutaj rozwiązanie, które odebrałem od moich kolegów z Yandex.Metrica. Nie polecałbym jej każdemu – przeczytajcie i sami oceńcie, czy się nadaje, czy nie.
Najpierw musisz utworzyć kilka serwerów z dużymi półkami dyskowymi. Następnie na tych serwerach utwórz kilka serwerów ClickHouse i skonfiguruj je tak, aby działały jako kolejna replika tych samych fragmentów. A następnie użyj systemu plików lub jakiegoś narzędzia na tych serwerach, które pozwala na tworzenie migawek. Istnieją dwie opcje tutaj. Pierwszą opcją są migawki LVM, drugą opcją jest ZFS w systemie Linux.
Potem każdego dnia będziesz musiał utworzyć migawkę, będzie ona leżeć i zajmować trochę miejsca. Naturalnie, jeśli dane ulegną zmianie, ilość miejsca będzie z czasem wzrastać. Tę migawkę można w dowolnym momencie usunąć i przywrócić dane, co jest dziwnym rozwiązaniem. Ponadto musimy również ograniczyć te repliki w konfiguracji, aby nie próbowały zostać liderami.
Czy uda się zorganizować kontrolowane opóźnienie replik w wałach?
W tym roku planujecie wykonanie wałów w ClickHouse. Czy uda się w nich zorganizować kontrolowane opóźnienie replik? Chcielibyśmy go użyć, aby zabezpieczyć się przed negatywnymi scenariuszami za pomocą alter i innych zmian.
Czy można wykonać jakiś rodzaj wycofania dla alter? Przykładowo w istniejącym wale weź i powiedz, że do tego momentu stosujesz zmiany i od tego momentu przestajesz stosować zmiany?
Jeżeli do naszego klastra przyszła komenda i ją zepsuła, to mamy replikę warunkową z godzinnym opóźnieniem, gdzie możemy powiedzieć, że w tej chwili z niej korzystamy, ale nie będziemy w niej wprowadzać zmian przez ostatnie dziesięć minut?
Najpierw o kontrolowanym opóźnieniu replik. Pojawiła się taka prośba od użytkowników i stworzyliśmy problem na Githubie z prośbą: „Jeśli ktoś tego potrzebuje, polub to, włóż serce”. Nikt nie dostarczył i temat został zamknięty. Możesz jednak już zyskać taką możliwość konfigurując ClickHouse. To prawda, dopiero począwszy od wersji 20.3.
ClickHouse stale dokonuje łączenia danych w tle. Po zakończeniu scalania określony zestaw danych zostaje zastąpiony większym fragmentem. Jednocześnie fragmenty danych, które znajdowały się wcześniej, nadal pozostają na dysku przez pewien czas.
Po pierwsze, są one przechowywane tak długo, jak istnieją wybrane zapytania, które z nich korzystają, aby zapewnić działanie nieblokujące. Wybrane zapytania można łatwo odczytać ze starych fragmentów.
Po drugie, istnieje również próg czasowy – stare dane leżą na dysku przez osiem minut. Te osiem minut można dostosować, a nawet zamienić w jeden dzień. Będzie to kosztować miejsce na dysku: w zależności od przepływu danych okazuje się, że ostatniego dnia dane nie tylko się podwoją, ale mogą wzrosnąć pięciokrotnie. Jeśli jednak wystąpi poważny problem, możesz zatrzymać serwer ClickHouse i wszystko uporządkować.
Teraz pojawia się pytanie, w jaki sposób chroni to przed zmianami. Warto przyjrzeć się temu bliżej, gdyż w starszych wersjach ClickHouse alter działał w ten sposób, że po prostu bezpośrednio zmieniał elementy. Z niektórymi plikami jest fragment danych i robimy to np. zmień kolumnę upuszczania. Następnie ta kolumna jest fizycznie usuwana ze wszystkich fragmentów.
Jednak począwszy od wersji 20.3 mechanizm zmiany został całkowicie zmieniony i teraz fragmenty danych są zawsze niezmienne. W ogóle się nie zmieniają – zmiany działają teraz w podobny sposób, jak scalanie. Zamiast wymieniać element na miejscu, tworzymy nowy. W nowym fragmencie pliki, które nie uległy zmianie, stają się dowiązaniami twardymi, a jeśli usuniemy kolumnę, w nowym fragmencie po prostu jej nie będzie. Stary utwór zostanie domyślnie usunięty po ośmiu minutach i tutaj możesz dostosować ustawienia wymienione powyżej.
To samo dotyczy zmian, takich jak mutacje. Kiedy to zrobisz zmień usuń lub zmień aktualizację, nie zmienia utworu, ale tworzy nowy. A następnie usuwa stary.
Co się stanie, jeśli struktura tabeli ulegnie zmianie?
Jak przywrócić kopię zapasową wykonaną według starego schematu? Drugie pytanie dotyczy przypadku z migawkami i narzędziami systemu plików. Czy Btrfs jest tutaj dobry zamiast ZFS na Linux LVM?
Jeśli zrobisz dołącz partycję partycje o innej strukturze, to ClickHouse powie Ci, że nie jest to możliwe. To jest rozwiązanie. Pierwszy polega na utworzeniu tabeli tymczasowej typu MergeTree ze starą strukturą, dołączeniu do niej danych za pomocą metody connect i wykonaniu zapytania alter. Następnie możesz skopiować lub przenieść te dane i załączyć je ponownie lub skorzystać z żądania zmień partycję przeniesienia tabeli.
Teraz drugie pytanie brzmi: czy można zastosować Btrfs. Na początek, jeśli masz LVM, wystarczą migawki LVM, a system plików może być ext4, to nie ma znaczenia. W przypadku Btrts wszystko zależy od Twojego doświadczenia w korzystaniu z niego. Jest to dojrzały system plików, ale nadal istnieją pewne podejrzenia, jak wszystko będzie działać w praktyce w konkretnym scenariuszu. Nie polecałbym używania tego, chyba że masz Btrfs w produkcji.
Jakie są aktualne najlepsze praktyki w zakresie ponownego udostępniania danych?
Problem reshardingu jest złożony i wieloaspektowy. Istnieje kilka możliwych odpowiedzi. Można przejść z jednej strony i powiedzieć tak – ClickHouse nie ma wbudowanej funkcji reshardingu. Obawiam się jednak, że ta odpowiedź nie będzie nikomu odpowiadać. Można zatem przejść od drugiej strony i powiedzieć, że ClickHouse ma wiele sposobów na ponowne shardowanie danych.
Jeśli w klastrze zabraknie miejsca lub nie będzie w stanie obsłużyć obciążenia, dodajesz nowe serwery. Ale te serwery są domyślnie puste, nie ma na nich żadnych danych, nie ma obciążenia. Należy zmienić rozmieszczenie danych, tak aby były równomiernie rozłożone w nowym, większym klastrze.
Pierwszym sposobem, w jaki można to zrobić, jest skopiowanie części partycji na nowe serwery za pomocą żądania zmień partycję pobierania tabeli. Na przykład, miałeś partycje według miesięcy, bierzesz pierwszy miesiąc 2017 i kopiujesz go na nowy serwer, a następnie kopiujesz trzeci miesiąc na inny nowy serwer. I robisz to, aż stanie się mniej więcej równe.
Transfer można wykonać tylko dla tych partycji, które nie ulegają zmianie podczas nagrywania. W przypadku świeżych partycji nagrywanie będzie musiało zostać wyłączone, ponieważ ich transfer nie jest atomowy. W przeciwnym razie pojawią się duplikaty lub luki w danych. Jednak ta metoda jest praktyczna i działa dość skutecznie. Gotowe, skompresowane partycje przesyłane są siecią, czyli dane nie są kompresowane ani ponownie kodowane.
Ta metoda ma jedną wadę i zależy od schematu shardingu, tego, czy zobowiązałeś się do tego schematu shardingu, jaki miałeś klucz shardingu. W Twoim przykładzie dotyczącym metryk kluczem fragmentowania jest skrót ścieżki. Jeśli wybierzesz tabelę rozproszoną, zostanie ona od razu skierowana do wszystkich fragmentów w klastrze i pobierze stamtąd dane.
Oznacza to, że tak naprawdę nie ma dla Ciebie znaczenia, jakie dane znalazły się na którym fragmencie. Najważniejsze jest to, że dane wzdłuż jednej ścieżki trafiają do jednego fragmentu, ale który z nich nie jest ważny. W tym przypadku przeniesienie gotowych partycji jest idealne, ponieważ za pomocą zapytań selekcjonujących otrzymasz również kompletne dane - czy przed reshardingiem, czy po, schemat nie ma większego znaczenia.
Ale są przypadki, które są bardziej złożone. Jeśli na poziomie logiki aplikacji opierasz się na specjalnym schemacie shardingu, to ten klient jest umiejscowiony na takim a takim shardu i żądanie może zostać wysłane bezpośrednio tam, a nie do tabeli Distributed. Lub używasz całkiem nowej wersji ClickHouse i włączyłeś to ustawienie zoptymalizuj, pomiń nieużywane fragmenty. W takim przypadku podczas zapytania wybierającego zostanie przeanalizowane wyrażenie w sekcji Where i zostanie obliczone, które shardy należy zastosować zgodnie ze schematem shardingu. Działa to pod warunkiem, że dane są podzielone dokładnie według tego schematu fragmentowania. Jeśli zmienisz je ręcznie, korespondencja może ulec zmianie.
Jest to więc metoda numer jeden. I czekam na odpowiedź, czy metoda jest odpowiednia, czy idziemy dalej.
Vladimir Kolobaev, główny administrator systemu w Avito: Alexey, metoda, o której wspomniałeś, nie działa zbyt dobrze, gdy trzeba rozłożyć obciążenie, w tym czytanie. Możemy wziąć partycję, która jest miesięczna i może przenieść poprzedni miesiąc do innego węzła, ale gdy przyjdzie żądanie tych danych, tylko je załadujemy. Chcielibyśmy jednak załadować cały klaster, bo w przeciwnym razie przez jakiś czas cały odczyt będzie przetwarzany przez dwa shardy.
Aleksiej Miłowidow: Odpowiedź jest dziwna – tak, jest zła, ale może zadziałać. Wyjaśnię dokładnie jak. Warto przyjrzeć się scenariuszowi obciążenia, który kryje się za Twoimi danymi. Jeśli chodzi o dane z monitorowania, to prawie na pewno możemy powiedzieć, że zdecydowana większość wniosków dotyczy świeżych danych.
Zainstalowałeś nowe serwery, przeprowadziłeś migrację starych partycji, ale także zmieniłeś sposób rejestrowania nowych danych. Nowe dane zostaną rozsiane po całym klastrze. Zatem już po pięciu minutach żądania z ostatnich pięciu minut będą równomiernie ładować klaster, a po jednym dniu żądania z XNUMX godzin będą równomiernie ładować klaster. A żądania za poprzedni miesiąc niestety trafią tylko do części serwerów klastra.
Ale często nie będziesz mieć próśb specjalnie na luty 2019 r. Najprawdopodobniej, jeśli wnioski trafią do 2019 r., to będą dotyczyć całego 2019 r. - przez długi okres, a nie przez jakiś mały zakres. Takie żądania będą również mogły równomiernie ładować klaster. Ale ogólnie rzecz biorąc, Twoja uwaga jest całkowicie słuszna, że jest to rozwiązanie ad hoc, które nie rozkłada danych całkowicie równomiernie.
Mam jeszcze kilka punktów, aby odpowiedzieć na to pytanie. Jedna z nich dotyczy tego, jak początkowo zaprojektować schemat fragmentowania, tak aby ponowne fragmentowanie powodowało mniej bólu. Nie zawsze jest to możliwe.
Na przykład masz dane z monitorowania. Dane z monitoringu rosną z trzech powodów. Pierwszym z nich jest gromadzenie danych historycznych. Po drugie, wzrost ruchu. A trzeci to wzrost liczby rzeczy podlegających monitoringowi. Istnieją nowe mikrousługi i metryki, które należy zapisać.
Możliwe, że spośród nich największy wzrost wiąże się z trzecim powodem – wzrostem wykorzystania monitoringu. I w tym przypadku warto przyjrzeć się charakterowi obciążenia, jakie są główne zapytania wybierające. Podstawowe zapytania wybierające będą najprawdopodobniej opierać się na pewnym podzbiorze metryk.
Na przykład użycie procesora na niektórych serwerach przez niektóre usługi. Okazuje się, że istnieje pewien podzbiór kluczy, za pomocą których uzyskujesz te dane. Samo żądanie tych danych jest najprawdopodobniej dość proste i trwa kilkadziesiąt milisekund. Służy do monitorowania usług i pulpitów nawigacyjnych. Mam nadzieję, że dobrze to rozumiem.
Władimir Kołobajew: Faktem jest, że bardzo często odwołujemy się do danych historycznych, gdyż w czasie rzeczywistym porównujemy sytuację obecną z historyczną. I ważny jest dla nas szybki dostęp do dużej ilości danych, a ClickHouse radzi sobie z tym znakomicie.
Masz całkowitą rację, większość żądań odczytu doświadczamy w ostatnim dniu, jak każdy system monitorowania. Ale jednocześnie obciążenie danymi historycznymi jest również dość duże. Pochodzi w zasadzie z systemu alarmowego, który pojawia się co trzydzieści sekund i mówi do ClickHouse: „Podaj mi dane z ostatnich sześciu tygodni. Teraz zbuduj dla mnie coś w rodzaju średniej ruchomej i porównajmy obecną wartość z wartością historyczną.
Chciałbym powiedzieć, że w przypadku tak niedawnych żądań mamy kolejną małą tabelę, w której przechowujemy dane tylko z dwóch dni i do niej trafiają główne żądania. Wysyłamy tylko duże zapytania historyczne do dużej tabeli podzielonej na fragmenty.
Aleksiej Miłowidow: Niestety okazuje się, że nie nadaje się do Twojego scenariusza, ale opiszę Ci dwa złe i skomplikowane schematy shardingu, których nie trzeba używać, ale które są używane w serwisie moich znajomych.
Istnieje główny klaster ze zdarzeniami Yandex.Metrica. Zdarzenia to odsłony strony, kliknięcia i konwersje. Większość żądań kierowana jest do określonej witryny internetowej. Otwierasz usługę Yandex.Metrica, masz stronę internetową - avito.ru, przechodzisz do raportu i pojawia się żądanie dotyczące Twojej witryny.
Istnieją jednak inne żądania – analityczne i globalne – zgłaszane przez wewnętrznych analityków. Na wszelki wypadek zauważam, że wewnętrzni analitycy składają zamówienia tylko na usługi Yandex. Niemniej jednak nawet usługi Yandex zajmują znaczną część wszystkich danych. Są to prośby nie o konkretne liczniki, a o szersze filtrowanie.
Jak zorganizować dane tak, żeby wszystko sprawnie działało dla jednego licznika i zapytań globalnych też? Kolejną trudnością jest to, że liczba żądań w ClickHouse dla klastra Metrics wynosi kilka tysięcy na sekundę. Jednocześnie jeden serwer ClickHouse nie jest w stanie obsłużyć nietrywialnych żądań, na przykład kilku tysięcy na sekundę.
Rozmiar klastra wynosi sześćset serwerów. Jeśli po prostu przeciągniesz tabelę rozproszoną na ten klaster i wyślesz tam kilka tysięcy żądań, będzie to jeszcze gorsze niż wysłanie ich do jednego serwera. Z drugiej strony opcja, że dane są rozłożone równomiernie, a my zwracamy się do wszystkich serwerów, zostaje natychmiast odrzucona.
Istnieje opcja diametralnie odwrotna. Wyobraź sobie, że dzielimy dane między witrynami, a żądanie dotyczące jednej witryny trafia do jednego fragmentu. Teraz klaster będzie w stanie obsłużyć dziesięć tysięcy żądań na sekundę, ale w przypadku jednego fragmentu każde żądanie będzie działać zbyt wolno. Nie będzie już skalowalny pod względem przepustowości. Zwłaszcza jeśli jest to strona avito.ru. Nie zdradzę tajemnicy, jeśli powiem, że Avito to jedna z najczęściej odwiedzanych stron w RuNet. A przetwarzanie tego na jednym odłamku byłoby szaleństwem.
Dlatego schemat fragmentowania został zaprojektowany w bardziej przebiegły sposób. Cały klaster jest podzielony na pewną liczbę klastrów, które nazywamy warstwami. Każdy klaster zawiera od kilkunastu do kilkudziesięciu fragmentów. W sumie takich klastrów jest trzydzieści dziewięć.
Jak to wszystko się skaluje? Liczba skupień się nie zmienia – tak jak kilka lat temu było trzydzieści dziewięć, tak pozostaje. Jednak w każdym z nich stopniowo zwiększamy liczbę fragmentów w miarę gromadzenia danych. Schemat shardingu w całości wygląda następująco: te klastry są podzielone na strony internetowe i aby zrozumieć, która witryna znajduje się w którym klastrze, używana jest osobna metabaza w MySQL. Jedna lokalizacja - w jednym klastrze. Wewnątrz następuje sharding według identyfikatorów gości.
Podczas nagrywania dzielimy je przez resztę podziału identyfikatora gościa. Jednak po dodaniu nowego fragmentu schemat podziału ulega zmianie; nadal dzielimy, ale z pozostałą częścią dzielenia przez inną liczbę. Oznacza to, że jeden użytkownik znajduje się już na kilku serwerach i nie można na tym polegać. Odbywa się to wyłącznie w celu zapewnienia lepszej kompresji danych. A wysyłając żądania, przechodzimy do tabeli Distributed, która przegląda klaster i uzyskuje dostęp do kilkudziesięciu serwerów. To taki głupi schemat.
Ale moja historia będzie niepełna, jeśli nie powiem, że porzuciliśmy ten schemat. W nowym schemacie zmieniliśmy wszystko i skopiowaliśmy wszystkie dane za pomocą Clickhouse-Copier.
W nowym schemacie wszystkie witryny podzielone są na dwie kategorie – duże i małe. Nie wiem, jak wybrano próg, ale w rezultacie duże witryny są rejestrowane w jednym klastrze, w którym znajduje się 120 shardów po trzy repliki każdy – czyli 360 serwerów. Schemat fragmentowania polega na tym, że każde żądanie trafia do wszystkich fragmentów jednocześnie. Jeśli teraz otworzysz dowolną stronę raportu dla avito.ru w Yandex.Metrica, żądanie trafi do 120 serwerów. W RuNet jest kilka dużych witryn. A żądań nie jest tysiąc na sekundę, ale nawet mniej niż sto. Wszystko to po cichu przeżuwa tabela Distributed, którą każdy z nich przetwarza przy pomocy 120 serwerów.
Drugi klaster jest przeznaczony dla małych witryn. Oto schemat fragmentowania oparty na identyfikatorze witryny, a każde żądanie trafia do dokładnie jednego fragmentu.
ClickHouse ma narzędzie do kopiowania Clickhouse. Czy możesz nam o niej opowiedzieć?
Od razu powiem, że to rozwiązanie jest bardziej kłopotliwe i nieco mniej produktywne. Zaletą jest to, że całkowicie rozmazuje dane zgodnie z określonym wzorcem. Ale wadą tego narzędzia jest to, że w ogóle nie powoduje ponownego fragmentowania. Kopiuje dane z jednego schematu klastra do innego schematu klastra.
Oznacza to, że aby to zadziałało, musisz mieć dwa klastry. Mogą znajdować się na tych samych serwerach, ale mimo to dane nie będą przenoszone przyrostowo, ale zostaną skopiowane.
Na przykład były cztery serwery, teraz jest ich osiem. Tworzysz nową tabelę Distributed na wszystkich serwerach, nowe tabele lokalne i uruchamiasz clickhouse-copier, wskazując w niej schemat pracy, który ma stamtąd odczytać, zaakceptować nowy schemat shardingu i tam przenieść dane. A na starych serwerach będziesz potrzebować półtora razy więcej miejsca niż obecnie, ponieważ stare dane muszą na nich pozostać, a połowa tych samych starych danych pojawi się na nich. Jeśli z góry pomyślałeś, że dane wymagają ponownego podziału i jest na to miejsce, ta metoda jest odpowiednia.
Jak działa kopiarka Clickhouse w środku? Dzieli całą pracę na zestaw zadań do przetwarzania jednej partycji jednej tabeli na jednym fragmencie. Wszystkie te zadania mogą być wykonywane równolegle, a kopiarka Clickhouse może być uruchamiana na różnych komputerach w wielu instancjach, ale to, co robi dla jednej partycji, to nic innego jak wybór wstawiania. Dane są odczytywane, dekompresowane, ponownie dzielone na partycje, a następnie ponownie kompresowane, gdzieś zapisywane i ponownie sortowane. To trudniejsza decyzja.
Miałeś pilotażowe rozwiązanie zwane reshardingiem. Co z nią?
W 2017 roku mieliśmy pilotażowe rozwiązanie zwane reshardingiem. W ClickHouse dostępna jest nawet taka opcja. Jak rozumiem, nie wypaliło. Czy możesz mi powiedzieć, dlaczego tak się stało? Wydaje się, że jest to bardzo istotne.
Cały problem polega na tym, że jeśli konieczne jest ponowne rozdrobnienie danych na miejscu, wymagana jest bardzo złożona synchronizacja, aby można było to zrobić atomowo. Kiedy zaczęliśmy przyglądać się, jak działa ta synchronizacja, stało się jasne, że istnieją zasadnicze problemy. I te fundamentalne problemy są nie tylko teoretyczne, ale od razu zaczęły pojawiać się w praktyce w postaci czegoś, co da się bardzo prosto wytłumaczyć – nic nie działa.
Czy możliwe jest połączenie wszystkich danych w całość przed przeniesieniem ich na wolne dyski?
Pytanie dotyczące TTL z opcją przejścia na wolny dysk w kontekście fuzji. Czy istnieje sposób inny niż przez cron, aby połączyć wszystkie części w jedną przed przeniesieniem ich na wolne dyski?
Odpowiedź na pytanie, czy można w jakiś sposób automatycznie skleić wszystkie elementy w jedną przed ich przeniesieniem - nie. Nie sądzę, że jest to konieczne. Nie musisz łączyć wszystkich części w jedną, możesz po prostu liczyć na to, że zostaną one automatycznie przeniesione na wolne dyski.
Mamy dwa kryteria dotyczące zasad transferów. Pierwsza jest taka, jak jest wypełniona. Jeśli bieżąca warstwa pamięci ma mniej niż określony procent wolnego miejsca, wybieramy jedną porcję i przenosimy ją do wolniejszej pamięci. A raczej nie wolniej, ale następny - zgodnie z konfiguracją.
Drugim kryterium jest rozmiar. Chodzi o przenoszenie dużych elementów. Możesz dostosować próg w zależności od wolnego miejsca na szybkim dysku, a dane zostaną przesłane automatycznie.
Jak przeprowadzić migrację do nowych wersji ClickHouse, jeśli nie ma możliwości wcześniejszego sprawdzenia kompatybilności?
Temat ten jest regularnie omawiany biorąc pod uwagę różne wersje, i nadal. Jak bezpieczna jest aktualizacja z wersji 19.11 do 19.16 i np. z 19.16 do 20.3. Jaki jest najlepszy sposób migracji do nowych wersji bez możliwości wcześniejszego sprawdzenia zgodności w piaskownicy?
Jest tu kilka „złotych” zasad. Pierwszy - . Jest duży, ale znajdują się w nim osobne akapity dotyczące zmian niekompatybilnych wstecz. Nie traktuj tych punktów jako czerwonej flagi. Są to zazwyczaj drobne niezgodności, które obejmują pewne funkcje brzegowe, z których najprawdopodobniej nie korzystasz.
Po drugie, jeśli nie ma możliwości sprawdzenia kompatybilności w piaskownicy, a chcesz dokonać aktualizacji od razu w środowisku produkcyjnym, zaleca się, aby nie było potrzeby tego robić. Najpierw utwórz piaskownicę i przetestuj. Jeśli nie ma środowiska testowego, to najprawdopodobniej nie masz bardzo dużej firmy, co oznacza, że możesz skopiować część danych na swój laptop i upewnić się, że wszystko na nim działa poprawnie. Możesz nawet utworzyć kilka replik lokalnie na swoim komputerze. Możesz też pobrać nową wersję gdzieś w pobliżu i przesłać tam część danych - czyli stworzyć zaimprowizowane środowisko testowe.
Kolejną zasadą jest nieaktualizowanie wersji przez tydzień po wydaniu wersji ze względu na wyłapanie błędów na produkcji i późniejsze szybkie poprawki. Ustalmy numerację wersji ClickHouse, aby się nie pomylić.
Dostępna jest wersja 20.3.4. Liczba 20 oznacza rok produkcji - 2020. Z punktu widzenia tego, co znajduje się w środku, nie ma to znaczenia, więc nie będziemy zwracać na to uwagi. Następny - 20.3. Zwiększamy drugą liczbę – w tym przypadku 3 – za każdym razem, gdy wypuszczamy wersję zawierającą nową funkcjonalność. Jeśli chcemy dodać jakąś funkcję do ClickHouse, musimy zwiększyć tę liczbę. Oznacza to, że w wersji 20.4 ClickHouse będzie działać jeszcze lepiej. Trzecia cyfra to 20.3.4. Tutaj 4 to liczba wydań poprawek, w których nie dodaliśmy nowych funkcji, ale naprawiliśmy kilka błędów. A 4 oznacza, że zrobiliśmy to cztery razy.
Nie myśl, że to coś strasznego. Zwykle użytkownik może zainstalować najnowszą wersję i będzie ona działać bez problemów z czasem pracy w skali roku. Ale wyobraźcie sobie, że w jakiejś funkcji przetwarzania bitmap, która została dodana przez naszych chińskich towarzyszy, serwer zawiesza się przy przekazywaniu błędnych argumentów. Mamy obowiązek to naprawić. Wydamy nową wersję łatki, a ClickHouse stanie się bardziej stabilny.
Jeśli masz ClickHouse działający w środowisku produkcyjnym i wypuszczona zostanie nowa wersja ClickHouse z dodatkowymi funkcjami - na przykład 20.4.1 jest pierwszą, nie spiesz się, aby wprowadzić ją do produkcji już pierwszego dnia. Dlaczego jest to w ogóle potrzebne? Jeśli jeszcze nie korzystasz z ClickHouse, możesz go zainstalować i najprawdopodobniej wszystko będzie dobrze. Ale jeśli ClickHouse już działa stabilnie, miej oko na łatki i aktualizacje, aby zobaczyć, jakie problemy naprawiamy.
Cyryl Szwakow: Chciałbym dodać trochę o środowiskach testowych. Wszyscy bardzo boją się środowisk testowych i z jakiegoś powodu uważają, że jeśli masz bardzo duży klaster ClickHouse, to środowisko testowe powinno być nie mniejsze lub co najmniej dziesięciokrotnie mniejsze. To wcale tak nie jest.
Mogę ci to powiedzieć na własnym przykładzie. Mam projekt i jest ClickHouse. Nasze środowisko testowe jest właśnie dla niego - jest to mała wirtualna maszyna w Hetzner za dwadzieścia euro, na której rozmieszczone jest absolutnie wszystko. Aby to zrobić, mamy w Ansible pełną automatyzację i dlatego w zasadzie nie ma znaczenia, gdzie się udać - na serwery sprzętowe, czy po prostu wdrożyć na maszynach wirtualnych.
Co można zrobić? Byłoby miło podać przykład w dokumentacji ClickHouse, jak wdrożyć mały klaster we własnym domu - w Dockerze, w LXC, być może utwórz podręcznik Ansible, ponieważ różni ludzie mają różne wdrożenia. To wiele uprości. Kiedy weźmiesz i wdrożysz klaster w ciągu pięciu minut, znacznie łatwiej jest spróbować coś wymyślić. Jest to o wiele wygodniejsze, ponieważ przejście na wersję produkcyjną, której nie testowałeś, to droga donikąd. Czasami to działa, a czasami nie. Dlatego nadzieja na sukces jest zła.
Maxim Kotyakov, starszy inżynier backendu Avito: Dorzucę jeszcze trochę o środowiskach testowych z szeregu problemów, z jakimi borykają się duże firmy. Posiadamy pełnoprawny klaster akceptacji ClickHouse, pod względem schematów danych i ustawień jest to dokładna kopia tego, co jest w produkcji. Ten klaster jest wdrażany w dość zniszczonych kontenerach z minimalną ilością zasobów. Zapisujemy tam pewien procent danych produkcyjnych, na szczęście istnieje możliwość odtworzenia strumienia w Kafce. Wszystko tam jest zsynchronizowane i skalowane – zarówno pod względem wydajności, jak i przepływu, i teoretycznie, przy założeniu, że wszystkie inne rzeczy są niezmienne, pod względem metryk powinno zachowywać się jak produkcja. Wszystko, co potencjalnie może wybuchnąć, jest najpierw zwijane na ten stojak i pozostawiane tam na kilka dni, aż będzie gotowe. Ale oczywiście to rozwiązanie jest drogie, trudne i ma niezerowe koszty wsparcia.
Aleksiej Miłowidow: Opowiem Wam jak wygląda środowisko testowe naszych przyjaciół z Yandex.Metrica. Jeden klaster miał 600 serwerów, inny 360, a trzeci i kilka klastrów. Środowisko testowe dla jednego z nich to po prostu dwa fragmenty z dwiema replikami w każdym. Dlaczego dwa odłamki? Abyś nie był sam. I powinny być też repliki. Tylko pewna minimalna kwota, na którą Cię stać.
To środowisko testowe pozwala sprawdzić, czy zapytania działają i czy coś istotnego nie jest uszkodzone. Ale często pojawiają się problemy o zupełnie innym charakterze, gdy wszystko działa, ale występują pewne niewielkie zmiany w obciążeniu.
Dam ci przykład. Zdecydowaliśmy się na instalację nowej wersji ClickHouse. Została umieszczona na środowisku testowym, w samym Yandex.Metrica zostały zakończone automatyczne testy, które porównują dane na starej wersji i nowej, uruchamiając cały potok. No i oczywiście zielone testy naszego CI. W przeciwnym razie nawet byśmy nie proponowali tej wersji.
Wszystko w porządku. Zaczynamy ruszać z produkcją. Dostaję komunikat, że obciążenie wykresów wzrosło kilkukrotnie. Wycofujemy wersję. Patrzę na wykres i widzę: obciążenie faktycznie wzrosło kilka razy podczas wdrażania i ponownie spadło po wdrożeniu. Następnie zaczęliśmy wycofywać wersję. I obciążenie wzrastało w ten sam sposób i spadało w ten sam sposób. Wniosek jest więc taki: obciążenie wzrosło ze względu na układ, nic dziwnego.
Wtedy ciężko było przekonać kolegów do zainstalowania nowej wersji. Mówię: „W porządku, rozwijaj się. Trzymajcie kciuki, wszystko się ułoży. Teraz obciążenie wykresów wzrosło, ale wszystko jest w porządku. Powieś tam." Ogólnie rzecz biorąc, zrobiliśmy to i tyle - wersja została wypuszczona do produkcji. Ale prawie przy każdym układzie pojawiają się podobne problemy.
Zabijanie zapytań powinno zabijać zapytania, ale tak nie jest. Dlaczego?
Przyszedł do mnie użytkownik, jakiś analityk i stworzył prośbę o umieszczenie mojego klastra ClickHouse. Jakiś węzeł lub cały klaster, w zależności od repliki lub fragmentu, do którego trafiło żądanie. Widzę, że wszystkie zasoby procesora na tym serwerze są na półce, wszystko jest czerwone. Jednocześnie ClickHouse sam odpowiada na zgłoszenia. I piszę: „Proszę mi pokazać listę procesów, jakie żądanie wywołało to szaleństwo”.
Znajduję tę prośbę i piszę do niej „zabij”. I widzę, że nic się nie dzieje. Mój serwer stoi na półce, ClickHouse wydaje mi wtedy jakieś polecenia, pokazuje, że serwer żyje i wszystko jest w jak najlepszym porządku. Ale mam degradację we wszystkich żądaniach użytkowników, degradacja zaczyna się od rekordów w ClickHouse, a moje zapytanie o zabicie nie działa. Dlaczego? Myślałem, że zapytanie zabijające miało zabijać zapytania, ale tak nie jest.
Teraz będzie dość dziwna odpowiedź. Chodzi o to, że zapytanie zabijające nie zabija zapytań.
Zabij zapytanie zaznacza małe pole o nazwie „Chcę, aby to zapytanie zostało zabite”. Samo żądanie sprawdza tę flagę podczas przetwarzania każdego bloku. Jeśli jest ustawiony, żądanie przestaje działać. Okazuje się, że nikt nie zabija żądania, on sam musi wszystko sprawdzić i przestać. I to powinno działać we wszystkich przypadkach, gdy żądanie jest w stanie przetwarzania bloków danych. Przetworzy następny blok danych, sprawdzi flagę i zatrzyma się.
Nie działa to w przypadkach, gdy żądanie jest blokowane w przypadku jakiejś operacji. To prawda, najprawdopodobniej tak nie jest w Twoim przypadku, ponieważ według Ciebie zużywa mnóstwo zasobów serwera. Możliwe, że to nie zadziała w przypadku sortowania zewnętrznego i w niektórych innych szczegółach. Ale ogólnie rzecz biorąc, nie powinno się to zdarzyć, jest to błąd. Jedyne co mogę polecić to aktualizacja ClickHouse.
Jak obliczyć czas odpowiedzi przy obciążeniu odczytem?
Istnieje tabela przechowująca agregaty pozycji - różne liczniki. Liczba linii wynosi około stu milionów. Czy można liczyć na przewidywalny czas reakcji, jeśli wylejesz 1 tys. RPS na 1 tys. pozycji?
Sądząc po kontekście, mówimy o obciążeniu odczytem, ponieważ z zapisem nie ma problemów - można wstawić nawet tysiąc, nawet sto tysięcy, a czasem kilka milionów wierszy.
Prośby o przeczytanie są bardzo różne. W przypadku wyboru 1 ClickHouse może wykonać około dziesiątek tysięcy żądań na sekundę, więc nawet żądania jednego klucza będą już wymagały pewnych zasobów. A takie zapytania punktowe będą trudniejsze niż w niektórych bazach klucz-wartość, bo przy każdym czytaniu trzeba odczytać blok danych według indeksu. Nasz indeks dotyczy nie każdego rekordu, ale każdego zakresu. Oznacza to, że będziesz musiał przeczytać cały zakres - domyślnie są to 8192 linie. Będziesz musiał zdekompresować skompresowany blok danych z 64 KB do 1 MB. Zazwyczaj wykonanie takich ukierunkowanych zapytań zajmuje kilka milisekund. Ale to jest najprostsza opcja.
Spróbujmy prostej arytmetyki. Jeśli pomnożysz kilka milisekund przez tysiąc, otrzymasz kilka sekund. To tak, jakby nie można było nadążyć za tysiącem żądań na sekundę, ale faktycznie jest to możliwe, ponieważ mamy kilka rdzeni procesorów. Zasadniczo ClickHouse może czasami pomieścić 1000 RPS, ale w przypadku krótkich żądań, konkretnie ukierunkowanych.
Jeśli potrzebujesz skalować klaster ClickHouse pod względem liczby prostych żądań, to polecam najprostszą rzecz - zwiększyć liczbę replik i wysyłać żądania do losowej repliki. Jeśli jedna replika obsługuje pięćset żądań na sekundę, co jest całkowicie realistyczne, wówczas trzy repliki obsłużą półtora tysiąca.
Czasami oczywiście można skonfigurować ClickHouse na maksymalną liczbę odczytów punktowych. Co jest do tego potrzebne? Pierwszym z nich jest zmniejszenie szczegółowości indeksu. W takim przypadku nie należy go redukować do jednego, ale przyjąć, że liczba wpisów w indeksie będzie wynosić kilka milionów lub dziesiątki milionów na serwer. Jeśli tabela ma sto milionów wierszy, wówczas ziarnistość można ustawić na 64.
Można zmniejszyć rozmiar skompresowanego bloku. Są do tego ustawienia minimalny rozmiar bloku kompresji, maksymalny rozmiar bloku kompresji. Można je ograniczyć, uzupełnić danymi, a wtedy zapytania kierowane będą szybsze. Jednak ClickHouse nie jest bazą danych typu klucz-wartość. Duża liczba małych żądań to antywzorzec obciążenia.
Cyryl Szwakow: Udzielę porady na wypadek, gdyby były tam zwykłe konta. Jest to dość standardowa sytuacja, gdy ClickHouse przechowuje jakiś licznik. Mam użytkownika, jest z takiego a takiego kraju i jakiegoś trzeciego pola i muszę coś stopniowo zwiększać. Weź MySQL, utwórz unikalny klucz - w MySQL jest to duplikat klucza, a w PostgreSQL jest to konflikt - i dodaj znak plus. To będzie działać znacznie lepiej.
Jeśli nie masz dużo danych, nie ma sensu używać ClickHouse. Istnieją regularne bazy danych i robią to dobrze.
Co mogę poprawić w ClickHouse, aby w pamięci podręcznej znajdowało się więcej danych?
Wyobraźmy sobie sytuację - serwery mają 256 GB RAM, na co dzień ClickHouse zajmuje około 60-80 GB, w szczycie - do 130. Co można włączyć i podkręcić, aby w pamięci podręcznej znajdowało się więcej danych i odpowiednio jest mniej podróży na dysk?
Zazwyczaj pamięć podręczna stron systemu operacyjnego radzi sobie z tym dobrze. Jeśli po prostu otworzysz górę, poszukaj tam pamięci podręcznej lub wolnej - jest tam również napisane, ile jest w pamięci podręcznej - zauważysz, że cała wolna pamięć jest wykorzystywana na pamięć podręczną. A podczas odczytu tych danych zostaną one odczytane nie z dysku, ale z pamięci RAM. Jednocześnie mogę powiedzieć, że pamięć podręczna jest wykorzystywana efektywnie, ponieważ buforowane są skompresowane dane.
Jeśli jednak chcesz jeszcze bardziej przyspieszyć niektóre proste zapytania, możliwe jest włączenie pamięci podręcznej w zdekompresowanych danych w ClickHouse. Nazywa się to nieskompresowana pamięć podręczna. W pliku konfiguracyjnym config.xml ustaw rozmiar nieskompresowanej pamięci podręcznej na potrzebną wartość - polecam nie więcej niż połowę wolnej pamięci RAM, ponieważ reszta trafi pod pamięć podręczną strony.
Ponadto istnieją dwa ustawienia poziomu żądania. Pierwsze ustawienie - użyj nieskompresowanej pamięci podręcznej - obejmuje jego użycie. Zaleca się włączenie go dla wszystkich żądań, z wyjątkiem ciężkich, które mogą odczytać wszystkie dane i opróżnić pamięć podręczną. Drugie ustawienie to coś w rodzaju maksymalnej liczby wierszy do wykorzystania pamięci podręcznej. Automatycznie ogranicza duże zapytania, tak aby omijały pamięć podręczną.
Jak mogę skonfigurować konfigurację_przechowywania dla przechowywania w pamięci RAM?
W nowej dokumentacji ClickHouse przeczytałem sekcję powiązaną . W opisie przykład z szybkim dyskiem SSD.
Zastanawiam się, jak to samo można skonfigurować z pamięcią typu Volume Hot. I jeszcze jedno pytanie. Jak Select radzi sobie z tą organizacją danych, czy odczyta cały zestaw, czy tylko ten, który jest na dysku i czy te dane są skompresowane w pamięci? A jak sekcja prewhere współpracuje z taką organizacją danych?
To ustawienie wpływa na przechowywanie fragmentów danych, a ich format nie zmienia się w żaden sposób.
Przyjrzyjmy się bliżej.
Możesz skonfigurować przechowywanie danych w pamięci RAM. Wszystko, co jest skonfigurowane dla dysku, to jego ścieżka. Tworzysz partycję tmpfs, która jest zamontowana w jakiejś ścieżce w systemie plików. Określasz tę ścieżkę jako ścieżkę do przechowywania danych dla najgorętszej partycji, fragmenty danych zaczynają tam docierać i być zapisywane, wszystko jest w porządku.
Ale nie polecam tego robić ze względu na niską niezawodność, chociaż jeśli masz co najmniej trzy repliki w różnych centrach danych, jest to możliwe. Jeśli coś się stanie, dane zostaną przywrócone. Wyobraźmy sobie, że serwer został nagle wyłączony i włączony ponownie. Przegroda została ponownie zamontowana, ale nic tam nie było. Kiedy serwer ClickHouse uruchamia się, widzi, że nie ma tych elementów, chociaż według metadanych ZooKeepera powinny tam być. Sprawdza, które repliki je posiadają, żąda ich i pobiera. W ten sposób dane zostaną przywrócone.
W tym sensie przechowywanie danych w pamięci RAM nie różni się zasadniczo od przechowywania ich na dysku, ponieważ dane zapisywane na dysku najpierw trafiają do pamięci podręcznej strony, a później są fizycznie zapisywane. Zależy to od opcji montowania systemu plików. Ale na wszelki wypadek powiem, że ClickHouse nie synchronizuje fsync podczas wstawiania.
W takim przypadku dane w pamięci RAM są przechowywane dokładnie w tym samym formacie, co na dysku. Zapytanie wybierające w ten sam sposób wybiera fragmenty, które należy przeczytać, wybiera niezbędne zakresy danych w fragmentach i je odczytuje. A prewhere działa dokładnie tak samo, niezależnie od tego, czy dane znajdowały się w RAM-ie, czy na dysku.
Do jakiej liczby unikalnych wartości skuteczna jest niska kardynalność?
Funkcja Low Cardinality została sprytnie zaprojektowana. Kompiluje słowniki danych, ale są one lokalne. Po pierwsze, dla każdego egzemplarza istnieją różne słowniki, a po drugie, nawet w ramach jednego utworu mogą być one różne dla każdego zakresu. Kiedy liczba unikalnych wartości osiąga próg – myślę, że milion – słownik jest po prostu odkładany na półkę i tworzony jest nowy.
Odpowiedź jest generalna: dla każdego zakresu lokalnego – powiedzmy na każdy dzień – gdzieś działa aż do miliona unikalnych wartości. Niska kardynalność jest skuteczna. Następnie nastąpi po prostu powrót, w którym będzie używanych wiele różnych słowników, a nie tylko jeden. Będzie działać mniej więcej tak samo jak zwykła kolumna łańcuchowa, może trochę mniej wydajna, ale nie będzie poważnego pogorszenia wydajności.
Jakie są najlepsze praktyki przeszukiwania pełnotekstowego tabeli zawierającej pięć miliardów wierszy?
Istnieją różne odpowiedzi. Po pierwsze, ClickHouse nie jest wyszukiwarką pełnotekstową. Istnieją do tego specjalne systemy, np. и . Jednak coraz częściej widzę ludzi, którzy mówią, że przechodzą z Elasticsearch na ClickHouse.
Dlaczego to się dzieje? Tłumaczą to tym, że Elasticsearch przestaje radzić sobie z obciążeniem przy niektórych woluminach, zaczynając od konstrukcji indeksów. Indeksy stają się zbyt uciążliwe, a jeśli po prostu przeniesiesz dane do ClickHouse, okaże się, że są one przechowywane kilkukrotnie wydajniej pod względem wolumenowym. Jednocześnie zapytania często nie były takie, że trzeba było znaleźć jakąś frazę w całym wolumenie danych, biorąc pod uwagę morfologię, ale zupełnie inną. Na przykład znajdź podciąg bajtów w logach z ostatnich kilku godzin.
W tym wypadku tworzysz w ClickHouse indeks, którego pierwszym polem będzie data i godzina. Największa granica danych będzie oparta na zakresie dat. W wybranym zakresie dat z reguły możliwe jest już przeszukiwanie pełnotekstowe, nawet metodą brute-force z wykorzystaniem like. Operator like w ClickHouse jest najskuteczniejszym operatorem like, jaki można znaleźć. Jeśli znajdziesz coś lepszego, powiedz mi.
Ale nadal, jak pełne skanowanie. Pełne skanowanie może być powolne nie tylko na procesorze, ale także na dysku. Jeśli nagle będziesz mieć jeden terabajt danych dziennie i będziesz szukać słowa w ciągu dnia, będziesz musiał przeskanować terabajt. I to zapewne na zwykłych dyskach twardych, a na koniec zostaną one załadowane w taki sposób, że nie będzie można uzyskać dostępu do tego serwera przez SSH.
W tym przypadku jestem gotowy zaoferować jeszcze jedną małą sztuczkę. To eksperyment – może zadziałać, może nie. ClickHouse posiada indeksy pełnotekstowe w postaci trygramowych filtrów Blooma. Nasi koledzy z Arenadata wypróbowali już te indeksy i często działają one dokładnie zgodnie z przeznaczeniem.
Aby poprawnie z nich korzystać, należy dobrze wiedzieć, jak dokładnie działają: czym jest trygramowy filtr Blooma i jak dobrać jego rozmiar. Mogę powiedzieć, że pomogą w zapytaniach dotyczących rzadkich fraz, podciągów, które rzadko można znaleźć w danych. W takim przypadku podzakresy zostaną wybrane za pomocą indeksów i odczytana zostanie mniejsza ilość danych.
Ostatnio ClickHouse dodał jeszcze bardziej zaawansowane funkcje wyszukiwania pełnotekstowego. Po pierwsze, jest to wyszukiwanie kilku podciągów jednocześnie w jednym przebiegu, włączając opcje uwzględniające wielkość liter, niewrażliwe na wielkość liter, z obsługą UTF-8 lub tylko ASCII. Wybierz najbardziej skuteczny, jakiego potrzebujesz.
Pojawiło się także wyszukiwanie wielu wyrażeń regularnych w jednym przebiegu. Nie musisz pisać X jak jednego podciągu lub X jak innego podciągu. Piszesz od razu, a wszystko odbywa się możliwie sprawnie.
Po trzecie, istnieje teraz przybliżone wyszukiwanie wyrażeń regularnych i przybliżone wyszukiwanie podciągów. Jeśli ktoś błędnie wpisał słowo, zostanie ono przeszukane pod kątem maksymalnego dopasowania.
Jak najlepiej zorganizować dostęp do ClickHouse dla dużej liczby użytkowników?
Powiedz nam, jak najlepiej zorganizować dostęp dla dużej liczby konsumentów i analityków. Jak utworzyć kolejkę, nadać priorytet maksymalnej liczbie jednoczesnych zapytań i za pomocą jakich narzędzi?
Jeżeli klaster jest wystarczająco duży, dobrym rozwiązaniem byłoby dobudowanie dwóch kolejnych serwerów, które staną się punktem wyjścia dla analityków. Oznacza to, że nie zezwalaj analitykom na dostęp do określonych fragmentów w klastrze, ale po prostu utwórz dwa puste serwery bez danych i skonfiguruj do nich prawa dostępu. W takim przypadku ustawienia użytkownika dotyczące żądań rozproszonych są przesyłane do serwerów zdalnych. Oznacza to, że konfigurujesz wszystko na tych dwóch serwerach, a ustawienia mają wpływ na cały klaster.
W zasadzie serwery te nie mają danych, jednak ilość znajdującej się na nich pamięci RAM jest bardzo istotna dla realizacji żądań. Dysk może być również używany do przechowywania danych tymczasowych, jeśli włączona jest zewnętrzna agregacja lub sortowanie zewnętrzne.
Ważne jest, aby przyjrzeć się ustawieniom, które są powiązane ze wszystkimi możliwymi limitami. Jeśli teraz udam się do klastra Yandex.Metrica jako analityk i poproszę o prośbę wybierz liczbę trafień, wówczas natychmiast otrzymam wyjątek mówiący, że nie mogę wykonać żądania. Maksymalna liczba wierszy, które mogę przeskanować, wynosi sto miliardów, a w sumie jest ich pięćdziesiąt bilionów w jednej tabeli w klastrze. To jest pierwsze ograniczenie.
Załóżmy, że usuwam limit wierszy i ponownie uruchamiam zapytanie. Następnie zobaczę następujący wyjątek - ustawienie włączone wymuś indeksowanie według daty. Nie mogę ukończyć zapytania, jeśli nie określiłem zakresu dat. Nie musisz polegać na analitykach, którzy określają to ręcznie. Typowym przypadkiem jest zapisanie zakresu dat, w którym data wydarzenia mieści się w przedziale tygodniowym. A potem po prostu podali nawias w niewłaściwym miejscu i zamiast i okazało się, że jest to or - lub dopasowanie adresu URL. Jeśli nie ma limitu, przeszuka kolumnę adresu URL i po prostu zmarnuje mnóstwo zasobów.
Ponadto ClickHouse ma dwa ustawienia priorytetów. Niestety, są one bardzo prymitywne. Jeden nazywa się po prostu priorytet. Jeżeli priorytet ≠ 0 i żądania z pewnym priorytetem są realizowane, ale realizowane jest żądanie z priorytetem mniejszym niż, co oznacza wyższy priorytet, to żądanie z priorytetem większym, co oznacza niższy priorytet , jest po prostu zawieszony i w tym czasie w ogóle nie będzie działać.
Jest to bardzo przybliżone ustawienie i nie jest odpowiednie w przypadkach, gdy klaster ma stałe obciążenie. Jeśli jednak masz krótkie i serie ważnych żądań, a klaster jest w większości bezczynny, ta konfiguracja będzie odpowiednia.
Wywoływane jest kolejne ustawienie priorytetu Priorytet wątku systemu operacyjnego. Po prostu ustawia wartość nice dla wszystkich wątków wykonywania żądań dla harmonogramu Linuksa. Działa tak sobie, ale nadal działa. Jeśli ustawisz minimalną wartość nice - jest to największa wartość, a zatem najniższy priorytet - i ustawisz -19 dla żądań o wysokim priorytecie, wówczas procesor będzie zużywał żądania o niskim priorytecie około cztery razy mniej niż te o wysokim priorytecie.
Musisz także skonfigurować maksymalny czas realizacji żądania - powiedzmy pięć minut. Najfajniejsza jest minimalna prędkość wykonywania zapytań. To ustawienie istnieje już od dawna i wymaga nie tylko zapewnienia, że ClickHouse nie spowalnia, ale także wymuszenia tego.
Wyobraź sobie, że konfigurujesz: jeśli jakieś zapytanie przetwarza mniej niż milion wierszy na sekundę, nie możesz tego zrobić. To hańbi nasze dobre imię i naszą dobrą bazę danych. Po prostu zakazajmy tego. Właściwie są dwa ustawienia. Jeden się nazywa minimalna prędkość wykonania - w liniach na sekundę, a druga nazywa się limitem czasu przed sprawdzeniem minimalnej szybkości wykonania - domyślnie piętnaście sekund. Oznacza to, że możliwe jest piętnaście sekund, a następnie, jeśli jest wolne, po prostu rzuć wyjątek i przerwij żądanie.
Musisz także ustawić limity. ClickHouse ma wbudowaną funkcję przydziału, która zlicza zużycie zasobów. Ale niestety nie zasoby sprzętowe, takie jak procesor, dyski, ale logiczne - liczba przetworzonych żądań, odczytanych linii i bajtów. I możesz skonfigurować na przykład maksymalnie sto żądań w ciągu pięciu minut i tysiąc żądań na godzinę.
Dlaczego to jest ważne? Ponieważ niektóre zapytania analityczne będą wykonywane ręcznie bezpośrednio z klienta ClickHouse. I wszystko będzie dobrze. Ale jeśli masz w firmie zaawansowanych analityków, to oni napiszą scenariusz i w skrypcie może pojawić się błąd. A ten błąd spowoduje wykonanie żądania w nieskończonej pętli. To jest to, przed czym musimy się chronić.
Czy można przekazać wyniki jednego zapytania dziesięciu klientom?
Mamy kilku użytkowników, którzy lubią przychodzić z bardzo dużymi prośbami w tym samym momencie. Żądanie jest duże i w zasadzie realizowane szybko, jednak ze względu na to, że takich próśb jest jednocześnie wiele, staje się bardzo bolesne. Czy można wykonać to samo żądanie, które przyszło dziesięć razy z rzędu i przekazać wynik dziesięciu klientom?
Problem w tym, że nie mamy wyników z pamięci podręcznej ani pamięci podręcznej danych pośrednich. Istnieje pamięć podręczna stron systemu operacyjnego, która uniemożliwi ponowne odczytanie danych z dysku, ale niestety dane nadal będą dekompresowane, deserializowane i ponownie przetwarzane.
Chciałbym w jakiś sposób tego uniknąć, buforując dane pośrednie lub ustawiając podobne zapytania w jakiejś kolejce i dodając pamięć podręczną wyników. Obecnie opracowujemy jedno żądanie ściągnięcia, które dodaje pamięć podręczną żądań, ale tylko dla podzapytań w sekcjach in i Join — oznacza to, że rozwiązanie jest niekompletne.
Jednak my również mamy do czynienia z taką sytuacją. Szczególnie kanonicznym przykładem są zapytania paginowane. Jest raport, ma kilka stron i jest prośba o limit 10. Potem to samo, ale limit 10,10. Potem kolejna następna strona. I pytanie brzmi: po co to wszystko liczymy za każdym razem? Ale teraz nie ma rozwiązania i nie ma sposobu, aby tego uniknąć.
Istnieje alternatywne rozwiązanie, które można umieścić jako wózek boczny obok ClickHouse - .
Cyryl Szwakow: ClickHouse Proxy ma wbudowany ogranicznik prędkości i wbudowaną pamięć podręczną wyników. Dokonano tam wielu ustawień, ponieważ rozwiązywano podobny problem. Serwer proxy umożliwia ograniczenie żądań poprzez kolejkowanie ich i skonfigurowanie czasu życia pamięci podręcznej żądań. Jeśli żądania były rzeczywiście takie same, Proxy wyśle je wiele razy, ale do ClickHouse trafi tylko raz.
Nginx ma również pamięć podręczną w wersji darmowej i to również będzie działać. Nginx ma nawet ustawienia, które powodują, że jeśli żądania dotrą w tym samym czasie, spowalniają inne, dopóki jedno nie zostanie zakończone. Ale to w ClickHouse Proxy konfiguracja przebiega znacznie lepiej. Został stworzony specjalnie dla ClickHouse, specjalnie na te prośby, więc jest bardziej odpowiedni. Cóż, jest łatwy w instalacji.
A co z operacjami asynchronicznymi i widokami zmaterializowanymi?
Jest taki problem, że operacje z silnikiem powtórek są asynchroniczne – najpierw dane są zapisywane, potem zwijane. Jeśli pod znakiem znajduje się zmaterializowana tablica z pewnymi agregatami, wówczas zostaną na niej zapisane duplikaty. A jeśli nie ma złożonej logiki, dane zostaną zduplikowane. Co możesz z tym zrobić?
Istnieje oczywiste rozwiązanie - zaimplementować wyzwalacz w określonej klasie widoków mat podczas operacji asynchronicznego zwijania. Czy są jakieś złote rady lub plany wdrożenia podobnej funkcjonalności?
Warto zrozumieć, jak działa deduplikacja. To, co ci teraz powiem, nie dotyczy pytania, ale na wszelki wypadek warto o tym pamiętać.
Podczas wstawiania do zreplikowanej tabeli następuje deduplikacja całych wstawionych bloków. Jeśli ponownie wstawisz ten sam blok zawierający tę samą liczbę tych samych wierszy w tej samej kolejności, dane zostaną deduplikowane. W odpowiedzi na wstawienie otrzymasz „OK”, ale tak naprawdę zostanie zapisany jeden pakiet danych, który nie będzie powielany.
Jest to konieczne dla pewności. Jeśli podczas wstawiania otrzymasz komunikat „OK”, oznacza to, że Twoje dane zostały wstawione. Jeśli otrzymasz błąd od ClickHouse, oznacza to, że nie zostały wstawione i musisz powtórzyć wstawianie. Jeśli jednak połączenie zostanie zerwane podczas wstawiania, nie wiadomo, czy dane zostały wstawione, czy nie. Jedyną opcją jest ponowne wstawienie. Jeśli dane zostały faktycznie wstawione i włożyłeś je ponownie, następuje deduplikacja blokowa. Jest to konieczne, aby uniknąć duplikatów.
Ważne jest również, jak to działa w przypadku poglądów zmaterializowanych. Jeśli dane zostały zdeduplikowane podczas wstawiania do głównej tabeli, to również nie trafią do widoku zmaterializowanego.
A teraz pytanie. Twoja sytuacja jest bardziej skomplikowana, ponieważ nagrywasz duplikaty poszczególnych linii. Oznacza to, że nie jest duplikowany cały pakiet, ale określone linie, które zapadają się w tle. Rzeczywiście, dane zostaną zwinięte w głównej tabeli, ale niezwinięte dane trafią do zmaterializowanego widoku, a podczas łączenia nic się nie stanie ze zmaterializowanymi widokami. Ponieważ zmaterializowany widok to nic innego jak wyzwalacz wstawiania. Podczas innych operacji nic więcej się z nim nie dzieje.
I nie mogę cię tutaj uszczęśliwić. Trzeba po prostu poszukać konkretnego rozwiązania w tym przypadku. Na przykład, czy możliwe jest odtworzenie go w widoku zmaterializowanym i metoda deduplikacji może działać w ten sam sposób. Ale niestety nie zawsze. Jeśli będzie się agregować, nie będzie działać.
Cyryl Szwakow: Kiedyś mieliśmy też konstrukcję kulową. Był problem, że są wyświetlenia reklam, a są pewne dane, które możemy pokazać w czasie rzeczywistym – to są tylko wyświetlenia. Rzadko się je powiela, ale jeśli tak się stanie, i tak je później zwiniemy. I były rzeczy, których nie dało się powielić – kliknięcia i cała ta historia. Ale też chciałam je pokazać niemal od razu.
Jak powstały zmaterializowane poglądy? Były widoki, w których było to pisane bezpośrednio - było zapisywane do surowych danych i zapisywane do widoków. Tam w pewnym momencie dane nie są zbyt poprawne, są powielane i tak dalej. I jest druga część tabeli, gdzie wyglądają dokładnie tak samo jak widoki zmaterializowane, to znaczy mają absolutnie identyczną strukturę. Co jakiś czas przeliczamy dane, liczymy dane bez duplikatów, zapisujemy do tych tabel.
Przeszliśmy przez API - w ClickHouse nie będzie to działać ręcznie. A API wygląda: gdy mam datę ostatniego dodania do tabeli, gdzie jest pewność, że zostały już obliczone prawidłowe dane, i wysyła żądanie do jednej tabeli i do drugiej tabeli. Z jednego żądanie wybiera do określonej ilości czasu, a z drugiego dostaje to, co nie zostało jeszcze obliczone. I to działa, ale nie tylko poprzez ClickHouse.
Jeśli masz jakiś interfejs API - dla analityków, dla użytkowników - to w zasadzie jest to opcja. Zawsze liczysz, zawsze liczysz. Można to robić raz dziennie lub o innej porze. Wybierasz dla siebie zakres, którego nie potrzebujesz i nie jest krytyczny.
ClickHouse ma wiele dzienników. Jak mogę na pierwszy rzut oka zobaczyć wszystko, co dzieje się z serwerem?
ClickHouse posiada bardzo dużą liczbę różnych logów i liczba ta stale rośnie. W nowych wersjach niektóre z nich są nawet domyślnie włączone, w starszych wersjach należy je włączyć podczas aktualizacji. Jest ich jednak coraz więcej. Docelowo chciałbym zobaczyć, co dzieje się teraz z moim serwerem, może na jakimś panelu podsumowującym.
Czy masz w swoim zespole ClickHouse lub w zespołach znajomych, którzy obsługują jakąś funkcjonalność gotowych dashboardów, które wyświetlałyby te logi jako gotowy produkt? Ostatecznie samo przeglądanie logów w ClickHouse jest świetne. Ale byłoby bardzo fajnie, gdyby było już przygotowane w formie dashboardu. Miałbym z tego frajdę.
Istnieją dashboardy, chociaż nie są one ustandaryzowane. W naszej firmie z ClickHouse korzysta około 60 zespołów, a najdziwniejsze jest to, że wiele z nich ma dashboardy, które sami stworzyli i to nieco inne. Niektóre zespoły korzystają z wewnętrznej instalacji Yandex.Cloud. Istnieją gotowe raporty, choć nie wszystkie niezbędne. Inni mają swoje.
Moi koledzy z Metrica mają swój własny dashboard w Grafanie, a ja mam swój własny dla ich klastra. Patrzę na takie rzeczy, jak trafienie w pamięć podręczną dla pamięci podręcznej szeryfowej. A jeszcze trudniejsze jest to, że używamy różnych narzędzi. Stworzyłem swój dashboard przy użyciu bardzo starego narzędzia o nazwie Graphite-web. Jest całkowicie brzydki. I nadal tak z niego korzystam, choć Grafana byłaby pewnie wygodniejsza i piękniejsza.
Podstawowa rzecz w dashboardach jest taka sama. Są to metryki systemowe klastra: procesor, pamięć, dysk, sieć. Inne - liczba jednoczesnych żądań, liczba jednoczesnych łączeń, liczba żądań na sekundę, maksymalna liczba fragmentów dla partycji tabeli MergeTree, opóźnienie replikacji, wielkość kolejki replikacji, liczba wstawianych wierszy na sekundę, liczba wstawianych bloków na sekundę. To wszystko, co uzyskuje się nie z logów, ale z metryk.
Władimir Kołobajew: Alexey, chciałbym to trochę poprawić. Jest Grafana. Grafana posiada źródło danych, którym jest ClickHouse. Oznacza to, że mogę wysyłać prośby z Grafany bezpośrednio do ClickHouse. ClickHouse posiada stół z baliami, jest on taki sam dla wszystkich. W rezultacie chcę uzyskać dostęp do tej tabeli dzienników w Grafanie i zobaczyć żądania wysyłane przez mój serwer. Byłoby wspaniale mieć taki pulpit nawigacyjny.
Sam jeździłem na rowerze. Ale mam pytanie - jeśli wszystko jest ustandaryzowane, a Grafana jest używana przez wszystkich, to dlaczego Yandex nie ma takiego oficjalnego dashboardu?
Cyryl Szwakow: W rzeczywistości źródło danych trafiające do ClickHouse obsługuje teraz Altinity. Chcę tylko dać wektor tego, gdzie kopać i kogo popchnąć. Możesz ich zapytać, ponieważ Yandex nadal tworzy ClickHouse, a nie związaną z nim historię. Altinity jest główną firmą aktualnie promującą ClickHouse. Nie opuszczą go, ale będą go wspierać. Bo w zasadzie, żeby wgrać dashboard na stronę Grafany wystarczy się jedynie zarejestrować i wgrać – nie ma specjalnych problemów.
Aleksiej Miłowidow: W ciągu ostatniego roku ClickHouse dodał wiele możliwości profilowania zapytań. Dla każdego żądania dostępne są metryki dotyczące użycia zasobów. Niedawno dodaliśmy profiler zapytań jeszcze niższego poziomu, który pozwala zobaczyć, gdzie zapytanie spędza każdą milisekundę. Aby jednak skorzystać z tej funkcjonalności, muszę otworzyć klienta konsoli i wpisać żądanie, o którym zawsze zapominam. Gdzieś to zapisałem i ciągle zapominam gdzie dokładnie.
Szkoda, że nie było narzędzia, które właśnie powiedziało: oto Twoje ciężkie zapytania, pogrupowane według klasy zapytań. Nacisnąłem jeden, a oni mi powiedzieli, że dlatego jest ciężki. Teraz nie ma takiego rozwiązania. I to naprawdę dziwne, że kiedy ludzie pytają mnie: „Powiedz mi, czy są gotowe dashboardy dla Grafany?”, odpowiadam: „Wejdź na stronę Grafany, jest tam społeczność „Dashboardy” i jest dashboard od Dimki jest deska rozdzielcza od Kostyana. Nie wiem, co to jest, sama tego nie używałam.
Jak wpłynąć na fuzje, aby serwer nie wpadł w OOM?
Mam tabelę, w tabeli jest tylko jedna partycja, jest to ReplacingMergeTree. Zapisuję w nim dane od czterech lat. Musiałem dokonać w nim zmian i usunąć niektóre dane.
Zrobiłem to i podczas przetwarzania tego żądania cała pamięć na wszystkich serwerach w klastrze została zużyta, a wszystkie serwery w klastrze przeszły w tryb OOM. Potem wszyscy wstali, zaczęli łączyć tę samą operację, ten blok danych, i ponownie wpadli w OOM. Potem znowu wstali i znowu upadli. I ta sprawa się nie zatrzymała.
Potem okazało się, że był to właściwie błąd, który chłopaki naprawili. To bardzo miłe, dziękuję bardzo. Ale pozostała pozostałość. I teraz, gdy myślę o dokonaniu jakiegoś scalania w tabeli, pojawia się pytanie – dlaczego nie mogę w jakiś sposób wpłynąć na te scalania? Na przykład ogranicz je ilością wymaganej pamięci RAM lub w zasadzie ilością, która przetworzy tę konkretną tabelę.
Mam tabelę o nazwie „Metryki”. Proszę przetworzyć ją w dwóch wątkach. Nie ma potrzeby tworzenia dziesięciu lub pięciu połączeń równolegle, zrób to w dwóch. Myślę, że mam wystarczająco dużo pamięci dla dwóch osób, ale może nie wystarczyć do przetworzenia dziesięciu. Dlaczego strach pozostaje? Ponieważ tabela rośnie i kiedyś stanę przed sytuacją, która w zasadzie nie jest już spowodowana błędem, ale tym, że dane zmienią się w tak dużej ilości, że po prostu nie będę miał wystarczającej ilości pamięci na dysku serwer. A następnie serwer ulegnie awarii w OOM podczas łączenia. Co więcej, mogę anulować mutację, ale Merjiego już nie ma.
Wiadomo, przy łączeniu serwer nie wpadnie w OOM, bo przy łączeniu ilość RAM-u jest wykorzystywana tylko na jeden mały zakres danych. Zatem wszystko będzie dobrze niezależnie od ilości danych.
Władimir Kołobajew: Cienki. Tutaj jest taki moment, że po naprawieniu błędu pobrałem dla siebie nową wersję, a na innej tabeli, mniejszej, gdzie jest wiele partycji, wykonałem podobną operację. A podczas fuzji na serwerze spalono około 100 GB RAM-u. Miałem 150 zajętych, 100 zjedzonych i zostało 50 GB wolnego miejsca, więc nie wpadłem w OOM.
Co obecnie chroni mnie przed wpadnięciem w OOM, jeśli faktycznie zużywa 100 GB RAM? Co zrobić, jeśli nagle skończy się pamięć RAM w fuzjach?
Aleksiej Miłowidow: Istnieje taki problem, że zużycie pamięci RAM specjalnie do łączenia nie jest ograniczone. A drugi problem jest taki, że jeśli zostało przypisane jakieś scalanie, to trzeba je wykonać, bo jest to odnotowane w logu replikacji. Dziennik replikacji to działania potrzebne do doprowadzenia repliki do spójnego stanu. Jeśli nie wykonasz ręcznych manipulacji, które spowodują wycofanie dziennika replikacji, scalanie będzie musiało zostać przeprowadzone w ten czy inny sposób.
Oczywiście nie byłoby zbyteczne posiadanie ograniczenia pamięci RAM, które „na wszelki wypadek” chroni przed OOM. Nie pomoże to w dokończeniu scalania, zacznie się od nowa, osiągnie pewien próg, zgłosi wyjątek i zacznie od nowa - nic dobrego z tego nie wyniknie. Ale w zasadzie przydatne byłoby wprowadzenie tego ograniczenia.
W jaki sposób zostanie opracowany sterownik Golang dla ClickHouse?
Sterownik Golang, napisany przez Kirilla Szwakowa, jest teraz oficjalnie wspierany przez zespół ClickHouse. On , jest teraz duży i prawdziwy.
Mała uwaga. Istnieje wspaniałe i ukochane repozytorium normalnych form nieskończonego porządku - to jest Vertica. Mają także swój własny oficjalny sterownik Pythona, który jest wspierany przez programistów Vertica. Kilka razy zdarzyło się, że wersje pamięci masowej i wersje sterowników znacznie się od siebie różniły, a sterownik w pewnym momencie przestał działać. I drugi punkt. Wydaje mi się, że wsparcie dla tego oficjalnego sterownika zapewnia system „sutek” - piszesz do nich problem i zawiesza się na zawsze.
Mam dwa pytania. Teraz sterownik Golang firmy Kirill jest prawie domyślnym sposobem komunikacji z Golang z ClickHouse. Chyba, że ktoś nadal komunikuje się poprzez interfejs http, bo tak mu się podoba. Jak będzie przebiegał rozwój tego sterownika? Czy będzie to zsynchronizowane z jakimikolwiek istotnymi zmianami w samym repozytorium? Jaka jest procedura rozpatrywania danej sprawy?
Cyryl Szwakow: Po pierwsze, wszystko jest zorganizowane biurokratycznie. Ta kwestia nie była poruszana, więc nie mam na co odpowiedzieć.
Aby odpowiedzieć na pytanie dotyczące problemu, potrzebujemy krótkiej historii sterownika. Pracowałem w firmie, która miała dużo danych. Był to spinner reklamowy z ogromną liczbą wydarzeń, które trzeba było gdzieś zapisać. I w pewnym momencie pojawił się ClickHouse. Wypełniliśmy go danymi i na początku wszystko było w porządku, ale potem ClickHouse uległ awarii. W tym momencie uznaliśmy, że nie jest nam to potrzebne.
Rok później wróciliśmy do pomysłu wykorzystania ClickHouse i musieliśmy jakoś zapisać tam dane. Wstępna wiadomość była następująca: sprzęt jest bardzo słaby, jest mało zasobów. Zawsze jednak tak pracowaliśmy i dlatego skupiliśmy się na natywnym protokole.
Ponieważ pracowaliśmy w Go, było jasne, że potrzebowaliśmy sterownika Go. Robiłem to niemal na pełen etat – było to moje zadanie zawodowe. Doprowadziliśmy to do pewnego momentu i w zasadzie nikt nie zakładał, że ktoś inny niż my będzie z tego korzystał. Potem przyszedł CloudFlare z dokładnie tym samym problemem i przez jakiś czas współpracowaliśmy z nimi bardzo sprawnie, bo mieli te same zadania. Co więcej, zrobiliśmy to zarówno w ClickHouse sami, jak i w sterowniku.
W pewnym momencie po prostu przestałem to robić, bo moja aktywność w ClickHouse i pracy trochę się zmieniła. Dlatego tematy nie są zamknięte. Okresowo ludzie, którzy sami czegoś potrzebują, angażują się w repozytorium. Następnie patrzę na żądanie ściągnięcia i czasami nawet sam coś edytuję, ale zdarza się to rzadko.
Chcę wrócić do sterownika. Kilka lat temu, kiedy to wszystko się zaczęło, ClickHouse również był inny i miał inne możliwości. Teraz wiemy, jak przerobić sterownik, aby działał dobrze. Jeśli tak się stanie, wersja 2 i tak będzie niekompatybilna ze względu na nagromadzone kule.
Nie wiem jak zorganizować tę sprawę. Sam nie mam dużo czasu. Jeśli niektórzy ludzie skończą sterownik, mogę im pomóc i powiedzieć, co mają robić. Ale aktywny udział Yandex w rozwoju projektu nie został jeszcze omówiony.
Aleksiej Miłowidow: Tak naprawdę nie ma jeszcze biurokracji związanej z tymi sterownikami. Jedyną rzeczą jest to, że są one przekazywane oficjalnej organizacji, to znaczy ten sterownik jest uznawany za oficjalne rozwiązanie domyślne dla Go. Jest jeszcze kilka innych sterowników, ale są one dostarczane osobno.
Nie mamy żadnego wewnętrznego rozwoju dla tych sterowników. Pytanie, czy możemy zatrudnić indywidualną osobę, nie do tego konkretnego kierowcy, ale do rozwoju wszystkich kierowców społecznych, czy też możemy znaleźć kogoś z zewnątrz.
Słownik zewnętrzny nie ładuje się po ponownym uruchomieniu komputera z włączoną opcją lazy_load. Co robić?
Mamy włączone ustawienie lazy_load i po ponownym uruchomieniu serwera słownik nie ładuje się sam. Jest wywoływany dopiero po uzyskaniu przez użytkownika dostępu do tego słownika. A przy pierwszym dostępie do niego wyskakuje błąd. Czy można w jakiś sposób automatycznie ładować słowniki za pomocą ClickHouse, czy też trzeba zawsze samemu kontrolować ich gotowość, aby użytkownicy nie otrzymywali błędów?
Być może mamy starą wersję ClickHouse, więc słownik nie załadował się automatycznie. Czy tak może być?
Po pierwsze, słowniki można wymusić za pomocą zapytania przeładuj słowniki systemu. Po drugie, co do błędu - jeśli słownik jest już załadowany, to zapytania będą działać w oparciu o załadowane dane. Jeżeli słownik nie został jeszcze załadowany, zostanie on załadowany bezpośrednio w trakcie żądania.
Nie jest to zbyt wygodne w przypadku ciężkich słowników. Na przykład musisz pobrać milion wierszy z MySQL. Ktoś dokonuje prostego wyboru, ale ten wybór będzie czekać na ten sam milion wierszy. Istnieją tutaj dwa rozwiązania. Pierwszym z nich jest wyłączenie lazy_load. Po drugie, gdy serwer jest uruchomiony, przed obciążeniem go wykonaj przeładuj słownik systemu lub po prostu wykonaj zapytanie korzystające ze słownika. Następnie słownik zostanie załadowany. Musisz kontrolować dostępność słowników przy włączonym ustawieniu lazy_load, ponieważ ClickHouse nie ładuje ich automatycznie.
Odpowiedź na ostatnie pytanie brzmi: albo wersja jest stara, albo wymaga debugowania.
Co zrobić z tym, że systemowe przeładowanie słowników nie ładuje żadnego z wielu słowników, jeśli choć jeden z nich ulegnie awarii z powodu błędu?
Jest jeszcze jedno pytanie dotyczące słowników ponownego ładowania systemu. Mamy dwa słowniki - jeden nie jest załadowany, drugi jest załadowany. W tym przypadku przeładowanie słowników systemowych nie ładuje żadnego słownika i należy załadować konkretny słownik punkt po punkcie według jego nazwy, korzystając z systemowego słownika przeładowującego. Czy dotyczy to również wersji ClickHouse?
Chcę cię uszczęśliwić. To zachowanie się zmieniało. Oznacza to, że jeśli zaktualizujesz ClickHouse, to również się zmieni. Jeśli nie jesteś zadowolony ze swojego obecnego zachowania przeładuj słowniki systemu, zaktualizuj i miejmy nadzieję, że zmieni się to na lepsze.
Czy istnieje sposób na skonfigurowanie szczegółów w konfiguracji ClickHouse, ale nie wyświetlanie ich w przypadku błędów?
Kolejne pytanie dotyczy błędów związanych ze słownikiem, a mianowicie szczegółów. W konfiguracji ClickHouse dla słownika określiliśmy szczegóły połączenia i jeśli wystąpi błąd, w odpowiedzi otrzymamy te dane i hasło.
Rozwiązaliśmy ten błąd, dodając szczegóły do konfiguracji sterownika ODBC. Czy jest jakiś sposób, aby skonfigurować szczegóły w konfiguracji ClickHouse, ale nie wyświetlać tych szczegółów w przypadku błędów?
Prawdziwym rozwiązaniem jest określenie tych poświadczeń w odbc.ini, a w samym ClickHouse określ tylko nazwę źródła danych ODBC. Nie stanie się to w przypadku innych źródeł słownikowych - ani w przypadku słownika z MySQL, ani w przypadku innych, hasło nie powinno być widoczne po otrzymaniu komunikatu o błędzie. W przypadku ODBC również poszukam – jeśli istnieje, wystarczy go usunąć.
Bonus: tła dla Zoomu ze spotkań
Klikając w obrazek, dla najbardziej wytrwałych czytelników otworzą się bonusowe tła ze spotkań. Gasimy pożar razem z maskotkami technologii Avito, naradzamy się z kolegami z pokoju administratora systemu lub oldschoolowego klubu komputerowego, a codzienne spotkania prowadzimy pod mostem na tle graffiti.
Źródło: www.habr.com