Во април, инженерите на Avito се собраа на онлајн состаноци со главниот развивач на ClickHouse Алексеј Миловидов и Кирил Шваков, развивач на Golang од Integros. Разговаравме за тоа како користиме систем за управување со бази на податоци и со какви потешкотии се среќаваме.
Врз основа на состанокот, составивме статија со одговори на експерти на нашите и прашањата на публиката за резервните копии, обновувањето на податоците, надворешните речници, двигателот Golang и ажурирањето на верзии на ClickHouse. Може да биде корисно за програмерите кои веќе активно работат со Yandex DBMS и се заинтересирани за неговата сегашност и иднина. Стандардно, одговорите се на Алексеј Миловидов, освен ако не е поинаку напишано.
Внимавајте, под резот има многу текст. Се надеваме дека содржината со прашања ќе ви помогне да се движите.
содржина
Ако не сакате да го читате текстот, можете да го гледате снимањето на собирите . Временските кодови се во првиот коментар под видеото.
ClickHouse постојано се ажурира, но нашите податоци не се. Што да се прави во врска со тоа?
ClickHouse постојано се ажурира, а нашите податоци, кои беа оптимизирани конечно обработени, не се ажурираат и се во резервна копија.
Да речеме дека имавме некој проблем и податоците беа изгубени. Решивме да ги вратиме, и се покажа дека старите партиции, кои се зачувани на резервните сервери, се многу различни од моментално користената верзија на ClickHouse. Што да направите во таква ситуација и дали е можно?
Невозможна е ситуација во која сте ги обновиле податоците од резервна копија во стар формат, но тие не се поврзуваат со новата верзија. Се грижиме дека форматот на податоци во ClickHouse секогаш останува компатибилен наназад. Ова е многу поважно од компатибилноста наназад во функционалноста ако однесувањето на некоја ретко користена функција се промени. Новата верзија на ClickHouse секогаш треба да може да ги чита податоците што се зачувани на дискот. Ова е закон.
Кои се тековните најдобри практики за резервна копија на податоците од ClickHouse?
Како да направите резервни копии, имајќи предвид дека имаме оптимизирани финални операции, огромна база на терабајти и податоци што се ажурираат, да речеме, последните три дена, а потоа не се случуваат никакви процедури?
Можеме да направиме свое решение и да напишеме на баш: соберете ги овие резервни копии на таков и таков начин. Можеби нема потреба ништо да се патерици, а велосипедот е измислен одамна?
Да почнеме со најдобрите практики. Моите колеги секогаш советуваат, како одговор на прашања за резервни копии, да ги потсетат за услугата Yandex.Cloud, каде што овој проблем е веќе решен. Затоа користете го ако е можно.
Не постои целосно решение за бекап, сто проценти вградено во ClickHouse. Има некои празни места што може да се користат. За да добиете комплетно решение, или ќе треба малку да штимате рачно, или да креирате обвивки во форма на скрипти.
Ќе започнам со наједноставните решенија и ќе завршам со најсофистицираните, во зависност од обемот на податоци и големината на кластерот. Колку е поголем кластерот, толку решението станува покомплексно.
Ако табелата со податоци зафаќа само неколку гигабајти, резервната копија може да се направи вака:
- Зачувајте ја дефиницијата на табелата, т.е. метаподатоци − прикажи креирај табела.
- Направете депонија користејќи го клиентот ClickHouse - изберете * од масата да поднесе. Стандардно ќе добиете датотека во формат TabSeparated. Ако сакате да бидете поефикасни, можете да го направите во мајчин формат.
Ако количината на податоци е поголема, тогаш резервната копија ќе потрае повеќе време и многу простор. Ова се нарекува логичка резервна копија; не е поврзана со форматот на податоци на ClickHouse. Ако е така, тогаш како последно средство можете да направите резервна копија и да ја поставите на MySQL за обновување.
За понапредни случаи, ClickHouse има вградена способност да креира слика од партиции во локалниот датотечен систем. Оваа функција е достапна како барање алтер маса замрзнување партиција. Или едноставно промена на масата замрзнување - ова е слика од целата табела.
Снимката ќе се креира постојано за една табела на еден фрагмент, односно, невозможно е на овој начин да се создаде конзистентна слика од целиот кластер. Но, за повеќето задачи нема таква потреба, и доволно е да се изврши барање на секој дел и да се добие конзистентна слика. Се создава во форма на тврди врски и затоа не зазема дополнителен простор. Следно, ја копирате оваа слика на резервниот сервер или на складиштето што го користите за резервни копии.
Враќањето на таква резервна копија е прилично лесно. Прво, креирајте табели користејќи ги постојните дефиниции за табели. Следно, копирајте ги зачуваните снимки од партициите во „Directory-Detached“ за овие табели и извршете го барањето прикачи партиција. Ова решение е сосема погодно за најсериозните количини на податоци.
Понекогаш ви треба нешто уште поладно - во случаи кога имате десетици или дури стотици терабајти на секој сервер и стотици сервери. Овде има решение што го подигнав од моите колеги од Yandex.Metrica. Не би го препорачал на сите - прочитајте го и одлучете сами дали е соодветно или не.
Прво треба да креирате неколку сервери со големи полици за дискови. Следно, на овие сервери, подигнете неколку ClickHouse сервери и конфигурирајте ги така што тие ќе работат како друга реплика за истите парчиња. А потоа користете датотечен систем или некоја алатка на овие сервери што ви овозможува да креирате снимки. Тука има две опции. Првата опција е LVM snapshots, втората опција е ZFS на Linux.
После тоа, секој ден треба да креирате слика, таа ќе лежи и ќе заземе малку простор. Секако, ако податоците се променат, просторот ќе се зголеми со текот на времето. Оваа слика може да се извади во секое време и да се обноват податоците, толку чудно решение. Плус, ние исто така треба да ги ограничиме овие реплики во конфигурацијата за да не се обидуваат да станат лидери.
Дали ќе биде можно да се организира контролирано заостанување на репликите во шахтите?
Оваа година планирате да направите шахти во ClickHouse. Дали ќе биде можно да се организира контролирано заостанување на реплики во нив? Би сакале да го искористиме за да се заштитиме од негативни сценарија со измени и други промени.
Дали е можно да се направи некаков вид на враќање за промени? На пример, во постоечка шахта, земете и кажете дека до овој момент ги применувате промените, а од овој момент престанувате да ги применувате промените?
Ако командата дојде во нашиот кластер и ја скрши, тогаш имаме условна реплика со еден час задоцнување, каде што можеме да кажеме дека ајде да ја користиме во моментот, но нема да примениме промени на неа во последните десет минути?
Прво, за контролираното заостанување на репликите. Имаше такво барање од корисниците, а ние направивме проблем на Github со барање: „Ако некому му треба ова, лајкнете, ставете срце“. Никој не достави, а прашањето беше затворено. Сепак, веќе можете да ја добиете оваа можност со поставување на ClickHouse. Точно, само почнувајќи од верзијата 20.3.
ClickHouse постојано врши спојување на податоци во позадина. Кога ќе заврши спојувањето, одреден сет на податоци се заменува со поголем дел. Во исто време, делови од податоци што беа таму претходно продолжуваат да останат на дискот некое време.
Прво, тие продолжуваат да се складираат сè додека има избрани прашања што ги користат, со цел да се обезбеди не-блокирање. Избраните прашања лесно се читаат од стари парчиња.
Второ, постои и временски праг - старите парчиња податоци лежат на дискот осум минути. Овие осум минути може да се прилагодат, па дури и да се претворат во еден ден. Ова ќе чини простор на дискот: во зависност од протокот на податоци, излегува дека во последниот ден податоците не само што ќе се удвојат, туку може да станат пет пати повеќе. Но, ако има сериозен проблем, можете да го запрете серверот ClickHouse и да средите сè.
Сега се поставува прашањето како ова штити од промени. Вреди да се погледне подлабоко овде, бидејќи во постарите верзии на ClickHouse, алтерот функционираше на таков начин што едноставно директно менуваше парчиња. Има дел од податоци со некои датотеки, а ние го правиме, на пример, промена на пад колона. Потоа оваа колона е физички отстранета од сите делови.
Но, почнувајќи од верзијата 20.3, механизмот за менување е целосно променет и сега деловите од податоците се секогаш непроменливи. Тие воопшто не се менуваат - промените сега работат на ист начин како и спојувањата. Наместо да замениме парче на лице место, создаваме ново. Во новиот дел, датотеките што не се променети стануваат тврда врска и ако избришеме колона, таа едноставно ќе недостасува во новиот дел. Старото парче ќе биде стандардно избришано по осум минути, и тука можете да ги измените поставките споменати погоре.
Истото важи и за промените како што се мутациите. Кога правите измени бришење или измени ажурирање, не го менува парчето, туку создава ново. И потоа го брише стариот.
Што ако структурата на табелата се промени?
Како да вратите резервна копија што е направена со старата шема? И второто прашање е за случајот со снимки и алатки за датотечен систем. Дали е добар Btrfs овде наместо ZFS на Linux LVM?
Ако направиш прикачи партиција партиции со различна структура, тогаш ClickHouse ќе ви каже дека тоа не е можно. Ова е решението. Првиот е да се создаде привремена табела од типот MergeTree со старата структура, да се прикачат податоци таму со помош на прикачување и да се направи алтер барање. Потоа можете да ги копирате или префрлите овие податоци и повторно да ги прикачите или да користите барање алтер табела поместување партиција.
Сега второто прашање е дали може да се користат Btrfs. За почеток, ако имате LVM, тогаш снимките од LVM се доволни, а датотечниот систем може да биде ext4, не е важно. Со Btrts, сè зависи од вашето искуство во користењето. Ова е зрел датотечен систем, но сè уште има некои сомнежи за тоа како сè ќе функционира во пракса во одредено сценарио. Не би препорачал да го користите ова освен ако немате Btrfs во производство.
Кои се тековните најдобри практики во обновувањето на податоците?
Прашањето за освежување е сложено и повеќеслојно. Овде има неколку можни одговори. Можете да одите од една страна и да го кажете ова - ClickHouse нема вградена функција за освежување. Но, се плашам дека овој одговор нема да одговара на никого. Затоа, можете да тргнете од другата страна и да кажете дека ClickHouse има многу начини за преобликување на податоците.
Ако кластерот снема простор или не може да се справи со оптоварувањето, додавате нови сервери. Но, овие сервери се стандардно празни, нема податоци за нив, нема оптоварување. Треба да ги преуредите податоците за да бидат рамномерно распоредени низ новиот, поголем кластер.
Првиот начин на кој ова може да се направи е да се копира дел од партициите на нови сервери користејќи барање изменете партиција за преземање на табелата. На пример, имавте партиции по месеци, и го земате првиот месец од 2017 година и го копирате на нов сервер, а потоа го копирате третиот месец на некој друг нов сервер. И го правите тоа додека не стане повеќе или помалку изедначено.
Преносот може да се изврши само за оние партиции кои не се менуваат за време на снимањето. За свежи партиции, снимањето ќе мора да биде оневозможено, бидејќи нивниот пренос не е атомски. Во спротивно, ќе завршите со дупликати или празнини во податоците. Сепак, овој метод е практичен и работи доста ефикасно. Готови компресирани партиции се пренесуваат преку мрежата, односно податоците не се компресирани или повторно кодирани.
Овој метод има еден недостаток, и зависи од шемата за сечење, дали сте се заложиле за оваа шема за сечење, каков клуч за сечење сте имале. Во вашиот пример за случајот со метрика, клучот за споделување е хашот на патеката. Кога ќе изберете Дистрибуирана табела, таа оди до сите делови во кластерот одеднаш и зема податоци од таму.
Ова значи дека всушност не ви е важно кои податоци на кој фрагмент завршиле. Главната работа е дека податоците по една патека завршуваат на еден дел, но кој не е важен. Во овој случај, префрлањето на готови партиции е совршено, бидејќи со одбрани прашања ќе добиете и целосни податоци - без разлика дали пред повторното освежување или после тоа, шемата навистина не е важна.
Но, има случаи кои се посложени. Ако на ниво на логика на апликацијата се потпирате на специјална шема за раздвојување, дека овој клиент се наоѓа на таков и таков фрагмент, и барањето може да се испрати директно таму, а не во табелата Distributed. Или користите прилично неодамнешна верзија на ClickHouse и сте ја овозможиле поставката оптимизирајте прескокнете ги неискористените парчиња. Во овој случај, при изборот на барањето, ќе се анализира изразот во делот каде и ќе се пресмета кои фрагменти треба да се користат според шемата за сечење. Ова функционира под услов податоците да се поделат точно според оваа шема за поделба. Ако сте ги преуредиле рачно, кореспонденцијата може да се промени.
Значи, ова е метод број еден. И го чекам вашиот одговор, дали методот е соодветен или да продолжиме понатаму.
Владимир Колобаев, главен системски администратор во Avito: Алексеј, методот што го спомна не функционира многу добро кога треба да го рашириш товарот, вклучително и читањето. Можеме да земеме партиција што е месечна и може да го однесе претходниот месец на друг јазол, но кога ќе дојде барање за овие податоци, ние само ќе ги вчитаме. Но, ние би сакале да го вчитаме целиот кластер, бидејќи во спротивно, одредено време целото оптоварување за читање ќе се обработува со два фрагменти.
Алексеј Миловидов: Одговорот овде е чуден - да, тоа е лошо, но може да работи. Ќе објаснам точно како. Вреди да се погледне сценариото за оптоварување кое стои зад вашите податоци. Ако ова се податоци за следење, тогаш речиси сигурно можеме да кажеме дека огромното мнозинство на барања се за свежи податоци.
Инсталиравте нови сервери, мигриравте стари партиции, но го променивте и начинот на снимање на свежи податоци. И свежи податоци ќе се шират низ кластерот. Така, по само пет минути, барањата за последните пет минути рамномерно ќе го вчитаат кластерот; по еден ден, барањата за XNUMX часа рамномерно ќе го вчитаат кластерот. А барањата за претходниот месец, за жал, ќе одат само на дел од кластер серверите.
Но, често нема да имате барања конкретно за февруари 2019 година. Најверојатно, ако барањата одат во 2019 година, тогаш тие ќе бидат за целата 2019 година - за голем временски период, а не за некој мал опсег. И таквите барања ќе можат рамномерно да го вчитаат кластерот. Но, генерално, вашата забелешка е апсолутно точна дека се работи за ад хок решение кое не ги шири податоците целосно рамномерно.
Имам уште неколку точки да одговорам на прашањето. Еден од нив е за тоа како првично да се дизајнира шема за сечење, така што повторното делење би било помалку болно. Ова не е секогаш можно.
На пример, имате податоци за следење. Податоците од мониторингот растат од три причини. Првата е акумулација на историски податоци. Вториот е растот на сообраќајот. И третото е зголемување на бројот на работи кои се предмет на мониторинг. Има нови микроуслуги и метрика што треба да се зачуваат.
Можно е од нив најголемото зголемување да е поврзано со третата причина - зголемувањето на употребата на мониторинг. И во овој случај, вреди да се погледне природата на товарот, кои се главните избрани прашања. Основните прашања за избор најверојатно ќе се засноваат на некоја подгрупа метрика.
На пример, користење на процесорот на некои сервери од некоја услуга. Излегува дека постои одредена подгрупа на клучеви со кои ги добивате овие податоци. И самото барање за овие податоци е најверојатно прилично едноставно и се комплетира за десетици милисекунди. Се користи за мониторинг услуги и контролни табли. Се надевам дека го разбирам ова правилно.
Владимир Колобаев: Факт е дека многу често се повикуваме на историски податоци, бидејќи моменталната состојба ја споредуваме со историската во реално време. И за нас е важно да имаме брз пристап до голема количина на податоци, а ClickHouse прави одлична работа со ова.
Сосема сте во право, повеќето од барањата за читање ги доживуваме во последниот ден, како и секој систем за следење. Но, во исто време, оптоварувањето на историските податоци е исто така доста големо. Во основа е од систем за предупредување кој оди наоколу на секои триесет секунди и му вели на ClickHouse: „Дајте ми ги податоците за последните шест недели. Сега изградете ми некаков подвижен просек од нив и ајде да ја споредиме сегашната вредност со историската“.
Би сакал да кажам дека за ваквите многу неодамнешни барања имаме уште една мала табела во која складираме само два дена податоци, а главните барања летаат во неа. Испраќаме само големи историски прашања до големата исецкана табела.
Алексеј Миловидов: За жал, се покажа дека е слабо применливо за вашето сценарио, но ќе ви кажам опис на две лоши и сложени шеми за сечење кои не треба да се користат, но кои се користат во услугата на моите пријатели.
Постои главен кластер со настани на Yandex.Metrica. Настаните се прегледи на страници, кликови и конверзии. Повеќето барања одат на одредена веб-страница. Ја отворате услугата Yandex.Metrica, имате веб-страница - avito.ru, одете до извештајот и се бара барање за вашата веб-страница.
Но, има и други барања - аналитички и глобални - што ги упатуваат внатрешните аналитичари. За секој случај, забележувам дека внатрешните аналитичари поднесуваат барања само за услугите на Yandex. Но, сепак, дури и услугите на Yandex заземаат значителен дел од сите податоци. Тоа се барања не за конкретни шалтери, туку за пошироко филтрирање.
Како да се организираат податоците на таков начин што сè работи ефикасно за еден бројач, а исто така и глобалните барања? Друга тешкотија е тоа што бројот на барања во ClickHouse за кластерот Metrics е неколку илјади во секунда. Во исто време, еден ClickHouse сервер не може да се справи со нетривијални барања, на пример, неколку илјади во секунда.
Големината на кластерот е сервери од шестотини. Ако едноставно повлечете Дистрибуирана табела над овој кластер и испратите неколку илјади барања таму, ќе стане уште полошо отколку да ги испратите на еден сервер. Од друга страна, веднаш се отфрла опцијата податоците да се шират рамномерно, а ние да одиме и да бараме од сите сервери.
Постои опција која е дијаметрално спротивна. Замислете ако ги делиме податоците на страниците, а барањето за една локација оди на еден дел. Сега кластерот ќе може да се справи со десет илјади барања во секунда, но на еден дел секое барање ќе работи премногу бавно. Веќе нема да се зголемува во однос на пропусната моќ. Особено ако ова е страницата avito.ru. Нема да ја откријам тајната ако кажам дека Avito е една од најпосетуваните сајтови во RuNet. И да се обработи на една фрагмента би било лудост.
Затоа, шемата за сечење е дизајнирана на полукав начин. Целиот кластер е поделен на голем број кластери, кои ги нарекуваме слоеви. Секој кластер содржи од десетина до неколку десетици парчиња. Вкупно има триесет и девет такви кластери.
Како се размерува сето ова? Бројот на кластери не се менува - како што беше пред триесет и девет години, така и останува. Но, во секоја од нив, ние постепено го зголемуваме бројот на парчиња како што акумулираме податоци. А шемата за раздвојување како целина е вака: овие кластери се поделени на веб-локации, а за да се разбере која веб-локација на кој кластер е, се користи посебна метабаза во MySQL. Еден сајт - на еден кластер. И внатре во него се случува шеринг според идентификациите на посетителите.
При снимањето ги делиме со остатокот од поделбата на ID на посетителот. Но, кога се додава нов фрагмент, се менува шемата за сечење; ние продолжуваме да се делиме, но со остаток од делењето со друг број. Ова значи дека еден посетител веќе се наоѓа на неколку сервери и не можете да се потпрете на ова. Ова е направено исклучиво за да се осигура дека податоците се подобро компресирани. И кога правиме барања, одиме до табелата Distributed, која го гледа кластерот и пристапува до десетици сервери. Ова е толку глупава шема.
Но, мојата приказна ќе биде нецелосна ако не кажам дека ја напуштивме оваа шема. Во новата шема, сменивме сè и ги копиравме сите податоци користејќи clickhouse-copier.
Во новата шема, сите локации се поделени во две категории - големи и мали. Не знам како е избран прагот, но резултатот беше дека големите страници се снимаат на еден кластер, каде што има 120 парчиња со по три реплики - односно 360 сервери. И шемата за сечење е таква што секое барање оди до сите парчиња одеднаш. Ако сега отворите која било страница за извештаи за avito.ru во Yandex.Metrica, барањето ќе оди на 120 сервери. Има неколку големи локации во RuNet. А барањата не се илјада во секунда, туку и помалку од сто. Сето тоа тивко го џвака табелата Distributed, која секој од нив ја обработува со 120 сервери.
И вториот кластер е за мали локации. Еве шема за споделување базирана на ID на страницата, и секое барање оди до точно еден фрагмент.
ClickHouse има алатка за копирање clickhouse. Можете ли да ни кажете за неа?
Веднаш ќе кажам дека ова решение е понезгодно и нешто помалку продуктивно. Предноста е што целосно ги размачкува податоците според шаблонот што ќе го наведете. Но, недостатокот на алатката е тоа што воопшто не се ослабува. Ги копира податоците од една кластер шема на друга кластер шема.
Ова значи дека за да работи мора да имате два кластери. Тие можат да бидат лоцирани на истите сервери, но, сепак, податоците нема да се преместуваат постепено, туку ќе се копираат.
На пример, имаше четири сервери, сега има осум. Креирате нова Дистрибуирана табела на сите сервери, нови локални табели и стартувате clickhouse-copier, означувајќи ја работната шема што треба да ја чита од таму, да ја прифати новата шема за споделување и да ги пренесе податоците таму. А на старите сервери ќе ви треба еден и пол пати повеќе простор отколку што има сега, бидејќи старите податоци мора да останат на нив, а врз нив ќе пристигне половина од истите стари податоци. Ако однапред мислевте дека податоците треба да се преобредат и има простор, тогаш овој метод е погоден.
Како работи clickhouse-copier внатре? Ја разложува целата работа во збир на задачи за обработка на една партиција од една табела на еден фрагмент. Сите овие задачи може да се извршуваат паралелно, а clickhouse-copier може да се извршува на различни машини во повеќе примероци, но она што го прави за една партиција не е ништо повеќе од избор на вметнување. Податоците се читаат, декомпресираат, повторно се партиционираат, потоа повторно се компресираат, се пишуваат некаде и повторно се подредуваат. Ова е потешка одлука.
Имавте пилот нешто наречено reshading. Што со неа?
Назад во 2017 година, имавте пилот нешто наречено resharding. Има дури и опција во ClickHouse. Како што разбрав, не полета. Можете ли да ми кажете зошто се случи ова? Се чини дека е многу релевантно.
Целиот проблем е во тоа што ако е неопходно повторно да се обноват податоците на место, потребна е многу сложена синхронизација за да се направи ова атомски. Кога почнавме да гледаме како функционира оваа синхронизација, стана јасно дека има суштински проблеми. И овие фундаментални проблеми не се само теоретски, туку и веднаш почнаа да се покажуваат во пракса во форма на нешто што може да се објасни многу едноставно - ништо не функционира.
Дали е можно да се спојат сите податоци заедно пред да се преместат на бавни дискови?
Прашање за TTL со опцијата преместување на бавен диск во контекст на спојувања. Дали постои начин, освен преку cron, да се спојат сите делови во еден пред да се префрлат на бавни дискови?
Одговорот на прашањето дали е можно некако автоматски да се залепат сите парчиња во едно пред да се префрлат - не. Мислам дека ова не е потребно. Не треба да ги споите сите делови во еден, туку едноставно сметајте на фактот дека тие автоматски ќе бидат префрлени на бавни дискови.
Имаме два критериуми за правила за трансфер. Првиот е како што е исполнет. Ако тековното ниво на складирање има помалку од одреден процент слободен простор, избираме еден дел и го преместуваме во побавно складирање. Или подобро, не побавно, туку следниот - како што го конфигурирате.
Вториот критериум е големината. Станува збор за поместување на големи парчиња. Можете да го прилагодите прагот според слободниот простор на брзиот диск и податоците ќе се префрлат автоматски.
Како да мигрирате на нови верзии на ClickHouse ако не постои начин да се провери компатибилноста однапред?
Оваа тема се дискутира редовно земајќи ги предвид различните верзии, а сепак. Колку е безбедно да се надополни од верзијата 19.11 на 19.16 и, на пример, од 19.16 на 20.3. Кој е најдобриот начин за мигрирање на нови верзии без да може однапред да се провери компатибилноста во песокот?
Тука има неколку „златни“ правила. Прво - . Голем е, но има посебни параграфи за наназад некомпатибилни промени. Не ги третирајте овие точки како црвено знаме. Овие се обично мали некомпатибилности кои вклучуваат некоја функционалност на рабовите што многу веројатно не ги користите.
Второ, ако не постои начин да се провери компатибилноста во песокот и сакате веднаш да се ажурирате во производството, препораката е да не треба да го правите тоа. Прво креирајте песок и тестирајте. Ако нема средина за тестирање, тогаш најверојатно немате многу голема компанија, што значи дека можете да копирате дел од податоците на вашиот лаптоп и да бидете сигурни дека сè работи правилно на него. Можете дури и да подигнете неколку реплики локално на вашата машина. Или можете да земете нова верзија некаде во близина и да испратите некои од податоците таму - односно да создадете импровизирана околина за тестирање.
Друго правило е да не се ажурира една недела по објавувањето на верзијата поради фаќање грешки во производството и последователни брзи поправки. Ајде да го откриеме нумерирањето на верзиите на ClickHouse за да не се збуниме.
Постои верзија 20.3.4. Бројот 20 ја означува годината на производство - 2020. Од гледна точка на она што е внатре, ова не е важно, па затоа нема да обрнуваме внимание на тоа. Следно - 20.3. Го зголемуваме вториот број - во овој случај 3 - секој пат кога објавуваме издание со некоја нова функционалност. Ако сакаме да додадеме некоја функција на ClickHouse, мора да го зголемиме овој број. Тоа е, во верзијата 20.4 ClickHouse ќе работи уште подобро. Третата цифра е 20.3.4. Еве 4 е бројот на изданија на закрпи во кои не додадовме нови функции, туку поправивме некои грешки. А 4 значи дека го направивме тоа четири пати.
Немојте да мислите дека ова е нешто страшно. Обично корисникот може да ја инсталира најновата верзија и таа ќе работи без никакви проблеми со времето на работа годишно. Но, замислете дека во некоја функција за обработка на битмапи, која ја додадоа нашите кинески другари, серверот паѓа при пренесување неточни аргументи. Ние имаме одговорност да го поправиме ова. Ќе објавиме нова верзија на закрпа и ClickHouse ќе стане постабилен.
Ако го имате ClickHouse што работи во производство, а нова верзија на ClickHouse излезе со дополнителни функции - на пример, 20.4.1 е првата, не брзајте да ја ставите во производство уште првиот ден. Зошто е воопшто потребно? Ако веќе не го користите ClickHouse, тогаш можете да го инсталирате, и најверојатно сè ќе биде во ред. Но, ако ClickHouse веќе работи стабилно, тогаш внимавајте на закрпи и ажурирања за да видите какви проблеми ги поправаме.
Кирил Шваков: Би сакал да додадам малку за околините за тестирање. Сите се плашат многу од околините за тестирање и поради некоја причина веруваат дека ако имате многу голем ClickHouse кластер, тогаш околината за тестирање треба да биде ни помалку ни повеќе или барем десет пати помала. Воопшто не е така.
Можам да ви кажам од мојот сопствен пример. Имам проект, а тука е и ClickHouse. Нашата околина за тестирање е само за него - ова е мала виртуелна машина во Хецнер за дваесет евра, каде што е распоредено апсолутно сè. За да го направите ова, имаме целосна автоматизација во Ansible, и затоа, во принцип, нема разлика каде да одиме - до хардверски сервери или само да се распоредиме во виртуелни машини.
Што може да се направи? Би било убаво да се даде пример во документацијата на ClickHouse за тоа како да распоредите мал кластер во вашиот дом - во Docker, во LXC, можеби креирајте книга за игри Ansible, бидејќи различни луѓе имаат различни распоредувања. Ова ќе поедностави многу. Кога ќе земете и распоредите кластер за пет минути, многу е полесно да се обидете да откриете нешто. Ова е многу поудобно, бидејќи превртувањето во производствена верзија што не сте ја тестирале е пат до никаде. Понекогаш функционира, а понекогаш не. И затоа, да се надеваме на успех е лошо.
Максим Котјаков, постар инженер за поддршка Авито: Ќе додадам малку за тест околините од низата проблеми со кои се соочуваат големите компании. Имаме полноправно кластер за прифаќање ClickHouse; во однос на шемите и поставките за податоци, тоа е точна копија на она што е во производство. Овој кластер е распореден во прилично застарени контејнери со минимум ресурси. Таму пишуваме одреден процент од податоците за производството, за среќа е можно да се реплицира стримот во Кафка. Таму сè е синхронизирано и скалирано - и во однос на капацитетот и протокот, и, теоретски, сите други нешта се еднакви, треба да се однесува како производство во однос на метриката. Сè што е потенцијално експлозивно прво се тркала на овој штанд и се остава таму неколку дена додека не се подготви. Но, природно, ова решение е скапо, тешко и има ненула трошоци за поддршка.
Алексеј Миловидов: Ќе ви кажам каква е околината за тестирање на нашите пријатели од Yandex.Metrica. Еден кластер имаше 600 непарни сервери, друг имаше 360, а има и трет и неколку кластери. Тестната средина за еден од нив е едноставно две парчиња со две реплики во секоја. Зошто две парчиња? За да не сте сами. И треба да има и реплики. Само одредена минимална сума што можете да си ја дозволите.
Ова опкружување за тестирање ви овозможува да проверите дали вашите прашања работат и дали нешто големо е скршено. Но, честопати се јавуваат проблеми од сосема поинаква природа, кога сè функционира, но има некои мали промени во товарот.
Дозволете ми да ви дадам пример. Решивме да инсталираме нова верзија на ClickHouse. Објавено е на тест средина, автоматизираните тестови се завршени во самата Yandex.Metrica, кои ги споредуваат податоците за старата и новата верзија, извршувајќи го целиот гасовод. И, се разбира, зелени тестови на нашиот CI. Во спротивно немаше ниту да ја предложиме оваа верзија.
Се е во ред. Почнуваме да преминуваме во производство. Добивам порака дека оптоварувањето на графиконите се зголемило неколку пати. Ја враќаме верзијата назад. Гледам во графиконот и гледам: оптоварувањето всушност се зголеми неколку пати за време на пуштањето во употреба и се намали назад кога се појавија. Потоа почнавме да ја враќаме верзијата. И товарот се зголеми на ист начин и падна назад на ист начин. Значи, заклучокот е овој: товарот се зголеми поради распоредот, ништо не изненадува.
Тогаш беше тешко да се убедат колегите да ја инсталираат новата верзија. Јас велам: „Во ред е, истурете. Држете ги прстите вкрстени, сè ќе работи. Сега оптоварувањето на графиконите се зголеми, но сè е во ред. Издржи." Во принцип, го направивме ова, и тоа е тоа - верзијата беше пуштена во производство. Но, речиси со секој распоред се појавуваат слични проблеми.
Kill query треба да ги убие барањата, но тоа не го прави. Зошто?
Еден корисник, некој вид аналитичар, дојде кај мене и создаде барање што го стави мојот кластер ClickHouse. Некој јазол или цел кластер, во зависност од тоа до која реплика или фрагмент отиде барањето. Гледам дека сите ресурси на процесорот на овој сервер се на полица, се е црвено. Во исто време, самиот ClickHouse одговара на барањата. И јас пишувам: „Ве молам покажи ми, списоци за процеси, кое барање го генерирало ова лудило“.
Го наоѓам ова барање и пишувам kill to it. И гледам дека ништо не се случува. Мојот сервер е на полица, ClickHouse потоа ми дава некои команди, покажува дека серверот е жив и се е супер. Но, имам деградација во сите барања на корисниците, деградацијата започнува со записите во ClickHouse, а моето барање за убиство не функционира. Зошто? Мислев дека убиството барање требаше да ги убие барањата, но тоа не го прави.
Сега ќе има прилично чуден одговор. Поентата е дека барањето за убивање не ги убива барањата.
Kill query проверува мало поле наречено „Сакам ова барање да биде убиено“. И самото барање го гледа ова знаменце при обработка на секој блок. Ако е поставено, барањето престанува да работи. Излегува дека никој не го убива барањето, тој самиот мора да провери сè и да престане. И ова треба да работи во сите случаи кога барањето е во состојба на обработка на блокови на податоци. Ќе го обработи следниот блок на податоци, ќе го провери знамето и ќе престане.
Ова не функционира во случаи кога барањето е блокирано при некоја операција. Точно, најверојатно ова не е ваш случај, бидејќи, според вас, користи еден тон ресурси на серверот. Можно е тоа да не функционира во случај на надворешно сортирање и во некои други детали. Но, генерално, ова не треба да се случи, тоа е грешка. И единственото нешто што можам да препорачам е ажурирање на ClickHouse.
Како да се пресмета времето на одговор при оптоварување за читање?
Има табела во која се чуваат агрегати на ставки - разни бројачи. Бројот на линии е приближно сто милиони. Дали е можно да се смета на предвидливо време на одговор ако истурите 1K RPS за 1K ставки?
Судејќи според контекстот, зборуваме за оптоварување со читање, бидејќи нема проблеми со пишувањето - може да се вметнат дури илјада, дури сто илјади, а понекогаш и неколку милиони редови.
Барањата за читање се многу различни. Во изберете 1, ClickHouse може да изврши околу десетици илјади барања во секунда, така што дури и барањата за еден клуч веќе ќе бараат одредени ресурси. И таквите прашања за точки ќе бидат потешки отколку во некои бази на податоци со клучни вредности, бидејќи за секое читање е неопходно да се прочита блок од податоци по индекс. Нашиот индекс не се однесува на секој запис, туку на секој опсег. Тоа е, ќе мора да го прочитате целиот опсег - ова е стандардно 8192 линии. И ќе треба да го декомпресирате блокот за компресирани податоци од 64 KB на 1 MB. Вообичаено, на таквите насочени прашања им требаат неколку милисекунди за да се завршат. Но, ова е наједноставната опција.
Ајде да пробаме едноставна аритметика. Ако помножите неколку милисекунди со илјада, ќе добиете неколку секунди. Како да е невозможно да се остане во чекор со илјада барања во секунда, но всушност тоа е можно, бидејќи имаме неколку процесорски јадра. Значи, во принцип, ClickHouse понекогаш може да држи 1000 RPS, но за кратки барања, конкретно насочени.
Ако треба да го размерите кластерот на ClickHouse според бројот на едноставни барања, тогаш ја препорачувам наједноставната работа - зголемете го бројот на реплики и испраќајте барања до случајна реплика. Ако една реплика содржи петстотини барања во секунда, што е сосема реално, тогаш три реплики ќе одговорат на една и пол илјади.
Понекогаш, се разбира, можете да го конфигурирате ClickHouse за максимален број отчитувања на точките. Што е потребно за ова? Првиот е да се намали грануларноста на индексот. Во овој случај, не треба да се намали на еден, туку врз основа на тоа дека бројот на записи во индексот ќе биде неколку милиони или десетици милиони по сервер. Ако табелата има сто милиони редови, тогаш грануларноста може да се постави на 64.
Можете да ја намалите големината на компримираниот блок. Постојат поставки за ова мин. големина на блок за компресија, максимална големина на блок за компресија. Тие можат да се намалат, повторно да се полнат со податоци, а потоа насочените прашања ќе бидат побрзи. Но, сепак, ClickHouse не е база на податоци со клучна вредност. Голем број на мали барања е антишаблон за оптоварување.
Кирил Шваков: Ќе дадам совет во случај да има обични сметки таму. Ова е прилично стандардна ситуација кога ClickHouse складира некој вид бројач. Имам корисник, тој е од таква и таква земја, и некое трето поле, и треба постепено да зголемувам нешто. Земете MySQL, направете единствен клуч - во MySQL е дупликат клуч, а во PostgreSQL е конфликт - и додадете знак плус. Ова ќе работи многу подобро.
Кога немате многу податоци, нема многу смисла да користите ClickHouse. Постојат редовни бази на податоци и тие го прават тоа добро.
Што можам да дотерувам во ClickHouse за да има повеќе податоци во кешот?
Ајде да замислиме ситуација - серверите имаат 256 GB RAM, во секојдневната рутина ClickHouse трае околу 60-80 GB, на врвот - до 130. Што може да се овозможи и дотера за да има повеќе податоци во кешот и, соодветно, има помалку патувања на дискот?
Вообичаено, кешот на страници на оперативниот систем добро го прави ова. Ако само го отворите горниот дел, погледнете таму кеширано или бесплатно - пишува и колку е кеширана - тогаш ќе забележите дека целата слободна меморија се користи за кешот. И кога ги читате овие податоци, тие ќе се читаат не од дискот, туку од RAM меморијата. Во исто време, можам да кажам дека кешот се користи ефективно, бидејќи тоа се компресираните податоци што се кешираат.
Меѓутоа, ако сакате уште повеќе да ги забрзате некои едноставни прашања, можно е да овозможите кеш во декомпресираните податоци во ClickHouse. Тоа се нарекува некомпресиран кеш. Во конфигурациската датотека config.xml, поставете ја големината на некомпресираниот кеш на вредноста што ви треба - препорачувам не повеќе од половина од бесплатната RAM меморија, бидејќи остатокот ќе оди под кешот на страницата.
Покрај тоа, постојат две поставки за ниво на барање. Прво поставување - користете некомпресиран кеш - ја вклучува неговата употреба. Препорачливо е да се овозможи за сите барања, освен тешките, кои можат да ги читаат сите податоци и да го исчистат кешот. И втората поставка е нешто како максималниот број на линии за користење на кешот. Тој автоматски ги ограничува големите барања, така што тие го заобиколуваат кешот.
Како можам да конфигурирам storage_configuration за складирање во RAM меморија?
Во новата документација на ClickHouse го прочитав делот поврзан . Описот содржи пример со брз SSD.
Се прашувам како може истото да се конфигурира со топла меморија за волумен. И уште едно прашање. Како функционира Select со оваа организација на податоци, дали ќе го чита целиот сет или само оној што е на дискот и дали овие податоци се компресирани во меморијата? И како функционира делот prewhere со таква организација на податоци?
Оваа поставка влијае на складирањето на делови од податоци и нивниот формат не се менува на кој било начин.
Ајде да погледнеме подетално.
Можете да конфигурирате складирање податоци во RAM меморијата. Сè што е конфигурирано за дискот е неговата патека. Вие креирате tmpfs партиција која е монтирана на некоја патека во датотечниот систем. Оваа патека ја одредувате како патека за складирање податоци за најжешката партиција, делови од податоци почнуваат да пристигнуваат и да се запишуваат таму, сè е во ред.
Но, не препорачувам да го правите ова поради мала доверливост, иако ако имате најмалку три реплики во различни центри за податоци, тогаш тоа е можно. Ако нешто се случи, податоците ќе бидат вратени. Да замислиме дека серверот одеднаш бил исклучен и повторно вклучен. Партицијата беше повторно монтирана, но таму немаше ништо. Кога ќе се стартува серверот ClickHouse, гледа дека ги нема овие парчиња, иако, според метаподатоците на ZooKeeper, тие треба да бидат таму. Гледа кои реплики ги имаат, ги бара и ги презема. На овој начин податоците ќе бидат обновени.
Во оваа смисла, складирањето податоци во RAM меморијата не е фундаментално различно од нивното складирање на дискот, бидејќи кога податоците се запишуваат на дискот, тие исто така прво завршуваат во кешот на страниците и физички се запишуваат подоцна. Ова зависи од опцијата за монтирање на датотечниот систем. Но, за секој случај, ќе кажам дека ClickHouse не се синхронизира при вметнување.
Во овој случај, податоците во RAM меморијата се складираат во истиот формат како и на дискот. Барањето за избор на ист начин ги избира парчињата што треба да се прочитаат, ги избира потребните опсези на податоци во парчињата и ги чита. И prewhere работи потполно исто, без разлика дали податоците биле во RAM или на диск.
До колку уникатни вредности е ефективна Ниската кардиналност?
Ниската кардиналност е умно дизајнирана. Составува речници со податоци, но тие се локални. Прво, постојат различни речници за секое парче, и второ, дури и во еден дел тие можат да бидат различни за секој опсег. Кога бројот на единствени вредности ќе достигне праг - еден милион, мислам - речникот едноставно се става на полицата и се создава нов.
Одговорот е генерално: за секој локален опсег - да речеме, за секој ден - некаде до милион уникатни вредности. Ниската кардиналност е ефективна. Потоа ќе има едноставно резервна копија, во која ќе се користат многу различни речници, а не само еден. Ќе работи приближно исто како и обична колона со низа, можеби малку помалку ефикасна, но нема да има сериозно влошување на перформансите.
Кои се најдобрите практики за пребарување на целосен текст на табела со пет милијарди редови?
Има различни одговори. Првиот е да се каже дека ClickHouse не е пребарувач со целосен текст. Постојат специјални системи за ова, на пример, и . Сепак, сè почесто гледам луѓе кои велат дека се префрлаат од Elasticsearch на ClickHouse.
Зошто се случува ова? Тие го објаснуваат ова со фактот дека Elasticsearch престанува да се справува со оптоварувањето на некои волумени, почнувајќи од изградбата на индекси. Индексите стануваат премногу незгодни и ако едноставно ги префрлите податоците во ClickHouse, излегува дека тие се складираат неколку пати поефикасно во однос на обемот. Во исто време, прашањата за пребарување честопати не беа такви што беше неопходно да се најде некоја фраза во целиот обем на податоци, земајќи ја предвид морфологијата, но сосема различни. На пример, најдете некоја последователна секвенца од бајти во дневниците во последните неколку часа.
Во овој случај, креирате индекс во ClickHouse, чие прво поле ќе биде датумот и времето. И најголемиот прекин на податоци ќе се заснова на временскиот опсег. Во рамките на избраниот опсег на датуми, по правило, веќе е можно да се изврши пребарување на целосен текст, дури и со користење на методот на брутална сила користејќи слично. Сличен оператор во ClickHouse е најефикасниот оператор за лајк што можете да го најдете. Ако најдеш нешто подобро, кажи ми.
Но, сепак, како да е целосно скенирање. И целосното скенирање може да биде бавно не само на процесорот, туку и на дискот. Ако одеднаш имате еден терабајт податоци дневно, а барате збор во текот на денот, тогаш ќе треба да го скенирате терабајтот. И веројатно е на обични хард дискови и на крајот тие ќе бидат вчитани на таков начин што нема да можете да пристапите до овој сервер преку SSH.
Во овој случај, јас сум подготвен да понудам уште еден мал трик. Тоа е експериментално - може да работи, можеби не. ClickHouse има индекси со целосен текст во форма на триграмски филтри Блум. Нашите колеги од Arenadata веќе ги испробаа овие индекси и тие често работат точно како што е предвидено.
За да ги користите правилно, треба да имате добро разбирање за тоа како точно функционираат: што е триграм Блум филтер и како да ја изберете неговата големина. Можам да кажам дека ќе помогнат за прашања за некои ретки фрази, поднизи кои ретко се наоѓаат во податоците. Во овој случај, подопсезите ќе се избираат по индекси и ќе се читаат помалку податоци.
Неодамна, ClickHouse додаде уште понапредни функции за пребарување на целосен текст. Ова е, прво, пребарување на куп поднизи одеднаш во едно поминување, вклучувајќи опции кои се чувствителни на големи букви, неосетливи на големи букви, со поддршка за UTF-8 или само за ASCII. Изберете го најефективниот што ви треба.
Се појави и пребарување за повеќе правилни изрази во едно поминување. Не треба да пишувате X како една подниза или X како друга подниза. Веднаш пишуваш, и се е направено максимално ефикасно.
Трето, сега има приближно пребарување за regexps и приближно пребарување за поднизи. Ако некој погрешно напишал збор, тој ќе се бара за максимално совпаѓање.
Кој е најдобриот начин да се организира пристап до ClickHouse за голем број корисници?
Кажете ни како најдобро да го организираме пристапот за голем број потрошувачи и аналитичари. Како да формирате редица, да дадете приоритет на максималните истовремени барања и со кои алатки?
Ако кластерот е доволно голем, тогаш добро решение би било да се подигнат уште два сервери, кои ќе станат влезна точка за аналитичарите. Односно, не дозволувајте аналитичарите да пристапуваат до одредени делови во кластерот, туку едноставно креирајте два празни сервери, без податоци и конфигурирајте ги правата за пристап на нив. Во овој случај, корисничките поставки за дистрибуирани барања се пренесуваат на оддалечени сервери. Односно, конфигурирате сè на овие два сервери, а поставките имаат ефект врз целиот кластер.
Во принцип, овие сервери немаат податоци, но количината на RAM меморија на нив е многу важна за извршување на барањата. Дискот може да се користи и за привремени податоци доколку е овозможено надворешно собирање или надворешно сортирање.
Важно е да ги погледнете поставките кои се поврзани со сите можни ограничувања. Ако сега отидам во кластерот Yandex.Metrica како аналитичар и побарам барање изберете број од хитови, тогаш веднаш ќе ми се даде исклучок дека не можам да го извршам барањето. Максималниот број на редови што ми е дозволено да ги скенирам е сто милијарди, а вкупно има педесет трилиони во една табела на кластерот. Ова е првото ограничување.
Да речеме дека го отстранив ограничувањето на редот и повторно го извршив барањето. Потоа ќе го видам следниов исклучок - поставката е овозможена индекс на сила по датум. Не можам да го пополнам барањето ако не сум навела опсег на датуми. Не треба да се потпирате на аналитичарите за да го наведете рачно. Типичен случај е кога е напишан опсег на датуми каде датумот на настанот е помеѓу недела. И тогаш тие едноставно наведоа заграда на погрешно место, и наместо и се покажа дека се совпаѓа или - или URL-адреса. Ако нема ограничување, ќе ја индексира колоната URL и само ќе потроши еден тон ресурси.
Покрај тоа, ClickHouse има две приоритетни поставки. За жал, тие се многу примитивни. Едноставно се нарекува приоритет. Ако приоритет ≠ 0, и барања со одреден приоритет се извршуваат, но се извршува барање со приоритетна вредност помала од, што значи повисок приоритет, тогаш барање со приоритетна вредност поголема, што значи помал приоритет , едноставно е суспендиран и нема да работи воопшто во ова време.
Ова е многу груба поставка и не е погодна за случаи кога кластерот има постојано оптоварување. Но, ако имате кратки, напнати барања кои се важни, а кластерот е главно неактивен, ова поставување е соодветно.
Се нарекува следното поставување на приоритети Приоритет на нишката на ОС. Едноставно ја поставува убавата вредност за сите нишки за извршување барања за распоредувачот на Линукс. Работи така-така, но сепак функционира. Ако ја поставите минималната убава вредност - таа е најголема по вредност, а со тоа и најнизок приоритет - и поставите -19 за барања со висок приоритет, тогаш процесорот ќе троши барања со низок приоритет околу четири пати помалку од оние со висок приоритет.
Исто така, треба да го конфигурирате максималното време за извршување на барањето - да речеме, пет минути. Минималната брзина на извршување на барањето е најкул работа. Оваа поставка постои долго време, и потребно е не само да се тврди дека ClickHouse не забавува, туку и да се присили.
Замислете, поставивте: ако некое барање обработува помалку од еден милион редови во секунда, не можете да го направите тоа. Ова го посрамоти нашето добро име, нашата добра база на податоци. Само да го забраниме ова. Всушност, постојат две поставки. Еден се нарекува мин брзина на извршување - во линии во секунда, а вториот се нарекува тајмаут пред да се провери мин брзината на извршување - стандардно петнаесет секунди. Тоа е, можни се петнаесет секунди, а потоа, ако е бавно, тогаш само фрли исклучок и прекинете го барањето.
Исто така, треба да поставите квоти. ClickHouse има вградена функција за квота која ја брои потрошувачката на ресурси. Но, за жал, не хардверски ресурси како што се процесорот, дисковите, туку логичните - бројот на обработени барања, линии и бајти прочитани. И можете да конфигурирате, на пример, максимум сто барања во рок од пет минути и илјада барања на час.
Зошто е важно? Бидејќи некои аналитички прашања ќе се вршат рачно директно од клиентот ClickHouse. И се ќе биде добро. Но, ако имате напредни аналитичари во вашата компанија, тие ќе напишат скрипта и може да има грешка во сценариото. И оваа грешка ќе предизвика барањето да се изврши во бесконечна јамка. Ова е она од што треба да се заштитиме.
Дали е можно да се дадат резултатите од едно барање на десет клиенти?
Имаме неколку корисници кои сакаат да доаѓаат со многу големи барања во исто време. Барањето е големо и, во принцип, брзо се извршува, но поради фактот што има многу такви барања во исто време, станува многу болно. Дали е можно истото барање, кое пристигнало десет пати по ред, еднаш да се изврши и да се даде резултат на десет клиенти?
Проблемот е што ги немаме резултатите од кешот или кешот на средните податоци. Има кеш на страници на оперативниот систем, што ќе ве спречи повторно да читате податоци од дискот, но, за жал, податоците сепак ќе бидат декомпресирани, десеријализирани и повторно обработени.
Би сакал некако да го избегнам ова, или со кеширање на средни податоци, или со редење слични прашања во некој вид редица и додавање кеш за резултати. Во моментов имаме едно барање за повлекување во развој што додава кеш за барања, но само за подпрашања во секциите во и приклучување - односно, решението е нецелосно.
Но, и ние се соочуваме со таква ситуација. Посебно канонски пример се пагинираните прашања. Има извештај, има неколку страници, и има барање за лимит 10. Потоа истото, но лимит 10,10. Потоа друга следна страница. И прашањето е зошто сето ова го броиме секој пат? Но, сега нема решение, и нема начин да се избегне.
Постои алтернативно решение кое е поставено како споредна кола до ClickHouse - .
Кирил Шваков: ClickHouse Proxy има вграден ограничувач на стапката и вграден кеш за резултати. Таму беа направени многу поставки бидејќи се решаваше сличен проблем. Прокси ви овозможува да ги ограничите барањата со тоа што ќе ги поставите во редица и ќе конфигурирате колку долго ќе живее кешот на барањата. Ако барањата беа навистина исти, Proxy ќе ги испраќа многу пати, но ќе оди во ClickHouse само еднаш.
Nginx исто така има кеш во бесплатната верзија, и ова исто така ќе работи. Nginx има дури и поставки кои ако барањата пристигнат во исто време, ќе ги забави другите додека не се заврши едното. Но, во ClickHouse Proxy поставувањето е направено многу подобро. Направен е специјално за ClickHouse, специјално за овие барања, па затоа е посоодветен. Па, лесно е да се инсталира.
Што е со асинхроните операции и материјализираните погледи?
Има проблем што операциите со моторот за повторување се асинхрони - прво се пишуваат податоците, а потоа се колабира. Ако материјализирана таблета со некои агрегати живее под знакот, тогаш на неа ќе бидат напишани дупликати. И ако нема сложена логика, тогаш податоците ќе се дуплираат. Што можете да направите за тоа?
Постои очигледно решение - да се имплементира активирач на одредена класа на matviews при асинхрона операција на колапс. Дали има некои сребрени куршуми или планови за спроведување на слична функционалност?
Вреди да се разбере како функционира дедупликацијата. Она што ќе ви го кажам сега не е релевантно за прашањето, но за секој случај вреди да се запамети.
При вметнување во реплицирана табела, постои дедупликација на целиот вметнат блокови. Ако повторно го вметнете истиот блок кој содржи ист број на исти редови по ист редослед, тогаш податоците се отпишуваат. Ќе добиете „Ок“ како одговор на вметнување, но всушност ќе биде напишан еден пакет податоци и нема да се дуплира.
Ова е неопходно за сигурност. Ако при вметнувањето примите „Ok“, тогаш вашите податоци се вметнати. Ако добиете грешка од ClickHouse, тоа значи дека тие не се вметнати и треба да го повторите вметнувањето. Но, ако врската е прекината за време на вметнувањето, тогаш не знаете дали податоците се вметнати или не. Единствената опција е повторно да се повтори вметнувањето. Ако податоците се всушност вметнати и вие повторно ги вметнавте, постои блок дедупликација. Ова е потребно за да се избегнат дупликати.
И, исто така, важно е како тоа функционира за материјализирани погледи. Ако податоците се дедупликат кога се вметнати во главната табела, тогаш тие нема да одат ниту во материјализираниот приказ.
Сега за прашањето. Вашата ситуација е посложена затоа што снимате дупликати на поединечни линии. Односно, не се дуплира целиот пакет, туку специфични линии и тие пропаѓаат во позадина. Навистина, податоците ќе се срушат во главната табела, но несобраните податоци ќе одат во материјализираниот приказ, а при спојувањата ништо нема да се случи со материјализираните прикази. Бидејќи материјализираниот поглед не е ништо повеќе од вметнување активирач. За време на други операции, ништо дополнително не се случува со него.
И не можам да те направам среќен овде. Само треба да барате конкретно решение за овој случај. На пример, дали е можно повторно да се репродуцира во материјализиран приказ, а методот на дедупликација може да работи на ист начин. Но, за жал, не секогаш. Ако се агрегира, нема да работи.
Кирил Шваков: Имавме и изградба на патерици во минатото. Имаше проблем што има рекламни впечатоци, а има некои податоци што можеме да ги прикажеме во реално време - тоа се само импресии. Тие ретко се дуплираат, но ако тоа се случи, сепак ќе ги срушиме подоцна. И имаше работи што не можеше да се дуплираат - кликови и целата оваа приказна. Но, исто така сакав да ги покажам речиси веднаш.
Како беа направени материјализираните ставови? Имаше ставови каде што беше директно напишано - беше напишано на необработени податоци, а напишано на прегледи. Таму во одреден момент податоците не се многу точни, се дуплираат итн. И има втор дел од табелата, каде што изгледаат сосема исто како материјализираните погледи, односно се апсолутно идентични по структура. Одвреме-навреме ги пресметуваме податоците, ги броиме податоците без дупликати, пишуваме на тие табели.
Поминавме преку API - ова нема да работи рачно во ClickHouse. А API-то изгледа: кога го имам датумот на последното додавање на табелата, каде што се гарантира дека точните податоци се веќе пресметани и тој испраќа барање до една табела и до друга табела. Од едниот барањето избира до одредено време, а од другото го добива она што сè уште не е пресметано. И работи, но не само преку ClickHouse.
Ако имате некој вид API - за аналитичари, за корисници - тогаш, во принцип, ова е опција. Секогаш сметате, секогаш сметате. Ова може да се направи еднаш дневно или во некое друго време. За себе избирате опсег што не ви треба и не е критичен.
ClickHouse има многу дневници. Како можам да видам сè што се случува со серверот на прв поглед?
ClickHouse има многу голем број на различни дневници и овој број се зголемува. Во новите верзии, некои од нив се стандардно овозможени; во постарите верзии тие мора да бидат овозможени при ажурирање. Сепак, ги има се повеќе и повеќе. На крајот на краиштата, би сакал да видам што се случува со мојот сервер сега, можеби на некој вид контролна табла за резиме.
Дали имате во вашиот тим на ClickHouse или во тимовите на вашите пријатели, кои поддржуваат одредена функционалност на готови контролни табли кои би ги прикажувале овие дневници како готов производ? На крајот на краиштата, само гледањето на дневниците во ClickHouse е одлично. Но, би било многу кул ако веќе е подготвено во форма на контролна табла. Јас би добил удар од тоа.
Има контролни табли, иако не се стандардизирани. Во нашата компанија, околу 60 тимови користат ClickHouse, а најчудното е што многу од нив имаат контролни табли кои сами си ги направиле и малку поинакви. Некои тимови користат внатрешна инсталација Yandex.Cloud. Има некои готови извештаи, иако не сите потребни. Други имаат свои.
Моите колеги од Metrica имаат своја контролна табла во Графана, а јас имам своја за нивниот кластер. Гледам работи како кеш хит за сериф кешот. А уште потешко е што користиме различни алатки. Ја создадов мојата контролна табла користејќи многу стара алатка наречена Graphite-web. Тој е целосно грд. И сè уште го користам на овој начин, иако Графана веројатно би била поудобна и поубава.
Основната работа во контролните табли е иста. Ова се системски метрики за кластерот: процесор, меморија, диск, мрежа. Други - број на истовремени барања, број на симултани спојувања, број на барања во секунда, максимален број парчиња за партиции на табелата MergeTree, доцнење на репликацијата, големина на редот за репликација, број на вметнати редови во секунда, број на вметнати блокови во секунда. Ова е сè што се добива не од дневници, туку од метрика.
Владимир Колобаев: Алексеј, би сакал малку да го поправам. Таму е Графана. Графана има извор на податоци, кој е ClickHouse. Односно, можам да поднесам барања од Графана директно до ClickHouse. ClickHouse има табела со логови, истата е за сите. Како резултат на тоа, сакам да пристапам до оваа табела за дневници во Графана и да ги видам барањата што ги прави мојот сервер. Би било одлично да се има ваква контролна табла.
Сам го возев велосипедот. Но, имам прашање - ако сето тоа е стандардизирано, а Grafana ја користат сите, зошто Yandex нема таква официјална контролна табла?
Кирил Шваков: Всушност, изворот на податоци што оди во ClickHouse сега поддржува Altinity. И само сакам да дадам вектор каде да се копа и кој да се турка. Можете да ги прашате, бидејќи Yandex сè уште го прави ClickHouse, а не приказната околу него. Altinity е главната компанија која моментално го промовира ClickHouse. Нема да го напуштат, туку ќе го поддржат. Бидејќи, во принцип, за да поставите контролна табла на веб-страницата на Графана, треба само да се регистрирате и да ја поставите - нема посебни проблеми.
Алексеј Миловидов: Во текот на изминатата година, ClickHouse додаде многу можности за профилирање на прашања. Постојат метрика за секое барање за користење на ресурсите. Неодамна, додадовме уште понизок профил за пребарување за да видиме каде ја троши барањето секоја милисекунда. Но, за да ја користам оваа функционалност, морам да го отворам клиентот на конзолата и да напишам барање, кое секогаш го заборавам. Го зачував некаде и заборавам каде точно.
Посакувам да има алатка која штотуку рече, еве ги вашите тешки прашања, групирани по класа на прашања. Притиснав на еден и ми рекоа дека затоа е тежок. Такво решение сега нема. И навистина е многу чудно што кога луѓето ме прашуваат: „Кажи ми, дали има готови контролни табли за Графана?“, јас велам: „Оди на веб-страницата на Графана, има заедница „Даштабла“ и има контролна табла. од Димка има контролна табла од Костјан. Не знам што е тоа, јас самиот не го користев“.
Како да се влијае на спојувањата за серверот да не се сруши во OOM?
Имам табела, има само една партиција во табелата, тоа е ReplacingMergeTree. Четири години пишувам податоци во него. Требаше да направам промена во него и да избришам некои податоци.
Го направив ова, и при обработката на ова барање, целата меморија на сите сервери во кластерот беше потрошена и сите сервери во кластерот отидоа во OOM. Потоа сите станаа заедно, почнаа да ја спојуваат истата операција, овој блок на податоци и повторно паднаа во OOM. Потоа повторно станаа и повторно паднаа. И оваа работа не престана.
Потоа се покажа дека ова е всушност грешка што момците ја поправија. Ова е многу кул, ви благодарам многу. Но, остана остаток. И сега, кога размислувам да направам некакво спојување во табелата, имам прашање - зошто не можам некако да влијаам на овие спојувања? На пример, ограничете ги со количината на потребната RAM меморија или, во принцип, со количината што ќе ја обработи оваа конкретна табела.
Имам табела наречена „Метрика“, ве молам обработете ја за мене во две нишки. Нема потреба да се создаваат десет или пет спојувања паралелно, направете го тоа во две. Мислам дека имам доволно меморија за двајца, но можеби нема да биде доволно да обработам десет. Зошто стравот останува? Затоа што табелата расте, и еден ден ќе се соочам со ситуација која, во принцип, повеќе не е поради баг, туку затоа што податоците ќе се променат во толку голема количина што едноставно нема да имам доволно меморија на сервер. И тогаш серверот ќе се сруши во OOM при спојување. Згора на тоа, можам да ја откажам мутацијата, но Мерџи веќе го нема.
Знаете, при спојување, серверот нема да падне во OOM, бидејќи при спојување, количината на RAM се користи само за еден мал опсег на податоци. Така, се ќе биде во ред без оглед на количината на податоци.
Владимир Колобаев: Добро. Овде моментот е таков што откако се поправи баг си симнав нова верзија за себе, а на друга табела помала каде што има многу партиции направив слична операција. И за време на спојувањето, на серверот беа изгорени околу 100 GB RAM. Имав 150 окупирани, 100 изедени и оставен прозорец од 50 GB, така што не паднав во ООМ.
Што во моментов ме штити да не паднам во OOM ако всушност троши 100 GB RAM? Што да направите ако одеднаш RAM меморијата на спојувањата истече?
Алексеј Миловидов: Има таков проблем што потрошувачката на RAM меморија специјално за спојување не е ограничена. И вториот проблем е што ако е доделен некој вид на спојување, тогаш тоа мора да се изврши бидејќи е заведено во дневникот за репликација. Дневникот за репликација е дејствијата што се потребни за да се доведе репликата во конзистентна состојба. Ако не направите рачни манипулации кои ќе го вратат овој дневник за репликација, спојувањето ќе мора да се изврши на еден или друг начин.
Се разбира, не би било излишно да се има ограничување на RAM меморијата што „за секој случај“ штити од OOM. Нема да помогне спојувањето да заврши, ќе започне повторно, ќе достигне одреден праг, ќе фрли исклучок и потоа ќе започне повторно - ништо добро нема да дојде од ова. Но, во принцип, би било корисно да се воведе ова ограничување.
Како ќе се развие двигателот Golang за ClickHouse?
Возачот на Голанг, кој го напиша Кирил Шваков, сега е официјално поддржан од тимот на ClickHouse. Тој , тој сега е голем и реален.
Мала забелешка. Постои прекрасно и сакано складиште на нормални форми на бесконечен ред - ова е Вертика. Тие имаат и свој официјален драјвер за питон, кој е поддржан од програмерите на Vertica. И неколку пати се случи верзиите за складирање и верзиите на драјверите да се разминат доста драматично, а возачот во одреден момент престана да работи. И втората точка. Поддршката за овој официјален возач, ми се чини, ја врши системот „брадавица“ - вие им пишувате проблем и тоа виси засекогаш.
Имам две прашања. Сега возачот Golang на Кирил е речиси стандардниот начин за комуникација од Golang со ClickHouse. Освен ако некој сè уште комуницира преку http интерфејсот бидејќи така му се допаѓа. Како ќе продолжи развојот на овој двигател? Дали ќе се синхронизира со какви било промени во самото складиште? И која е процедурата за разгледување на прашање?
Кирил Шваков: Првата е како се е бирократски организирано. Оваа точка не беше дискутирана, така што немам што да одговорам.
За да одговориме на прашањето за проблемот, ни треба малку историја на возачот. Работев за компанија која имаше многу податоци. Тоа беше рекламен спинер со огромен број настани што требаше да се складираат некаде. И во одреден момент се појави ClickHouse. Го наполнивме со податоци, и на почетокот се беше во ред, но потоа се урна ClickHouse. Во тој момент решивме дека не ни треба.
Една година подоцна, се вративме на идејата да користиме ClickHouse и требаше некако да напишеме податоци таму. Воведната порака беше оваа: хардверот е многу слаб, има малку ресурси. Но, ние отсекогаш сме работеле на овој начин, и затоа гледавме кон мајчин протокол.
Бидејќи работевме во Го, беше јасно дека ни треба возач на Го. Го правев тоа речиси со полно работно време - тоа беше моја работна задача. Го доведовме до одредена точка и во принцип никој не претпоставуваше дека некој друг освен нас ќе го користи. Потоа дојде CloudFlare со потполно истиот проблем и извесно време работевме со нив многу непречено, бидејќи тие ги имаа истите задачи. Покрај тоа, ние го направивме ова и во ClickHouse самите и во возачот.
Во одреден момент, едноставно престанав да го правам тоа, бидејќи мојата активност во однос на ClickHouse и работата малку се промени. Затоа прашањата не се затворени. Периодично, луѓето на кои им треба нешто самите се обврзуваат на складиштето. Потоа го гледам барањето за повлекување и понекогаш дури и уредувам нешто сам, но ова се случува ретко.
Сакам да се вратам кај возачот. Пред неколку години, кога започна целата оваа работа, ClickHouse исто така беше различен и со различни можности. Сега имаме разбирање за тоа како да го преправиме драјверот за да работи добро. Ако тоа се случи, тогаш верзијата 2 ќе биде некомпатибилна во секој случај поради акумулираните патерици.
Не знам како да го организирам ова прашање. Јас самиот немам многу време. Ако некои луѓе го завршат возачот, можам да им помогнам и да им кажам што да прават. Но, активното учество на Yandex во развојот на проектот сè уште не е дискутирано.
Алексеј Миловидов: Всушност, сè уште нема бирократија за овие возачи. Единственото нешто е што тие се доставуваат до официјална организација, односно овој возач е препознаен како официјално стандардно решение за Go. Има уште некои возачи, но тие доаѓаат одделно.
Немаме внатрешен развој за овие двигатели. Прашањето е дали можеме да вработиме индивидуално лице, не за овој конкретен возач, туку за развој на сите возачи во заедницата, или можеме да најдеме некој однадвор.
Надворешниот речник не се вчитува по рестартирање со овозможена поставка lazy_load. Што да се прави?
Ја имаме овозможено поставката lazy_load и откако ќе се рестартира серверот, речникот не се вчитува сам. Се подига само откако корисникот ќе пристапи до овој речник. И првиот пат кога пристапувам ми дава грешка. Дали е можно некако автоматски да се вчитаат речниците користејќи ClickHouse или треба секогаш сами да ја контролирате нивната подготвеност за корисниците да не добиваат грешки?
Можеби имаме стара верзија на ClickHouse, па речникот не се вчита автоматски. Дали ова може да биде случај?
Прво, речниците може принудно да се вчитаат со помош на барање системски превчитај речници. Второ, во врска со грешката - ако речникот е веќе вчитан, тогаш барањата ќе работат врз основа на податоците што биле вчитани. Ако речникот сè уште не е вчитан, тој ќе се вчита директно за време на барањето.
Ова не е многу погодно за тешки речници. На пример, треба да повлечете милион редови од MySQL. Некој прави едноставно избирање, но овој избор ќе чека ист милион редови. Тука има две решенија. Првиот е да го исклучите lazy_load. Второ, кога серверот е во функција, пред да го ставите товарот на него, направете речник за повторно вчитување на системот или само направете барање што користи речник. Потоа речникот ќе се вчита. Треба да ја контролирате достапноста на речниците со овозможена поставка lazy_load, бидејќи ClickHouse не ги вчитува автоматски.
Одговорот на последното прашање е или верзијата е стара или треба да се дебагира.
Што да се прави со фактот дека речниците за повторно вчитување на системот не вчитува ниту еден од многуте речници ако барем еден од нив падне со грешка?
Има уште едно прашање за речниците за повторно вчитување на системот. Имаме два речници - едниот не е вчитан, вториот е вчитан. Во овој случај, речниците за повторно вчитување на системот не вчитуваат никаков речник и треба точка-по-точка да вчитате одреден по неговото име користејќи речник за повторно вчитување на системот. Дали ова е поврзано и со верзијата на ClickHouse?
Сакам да те направам среќен. Ова однесување се менуваше. Ова значи дека ако го ажурирате ClickHouse, тој исто така ќе се промени. Ако не сте задоволни со вашето сегашно однесување системски превчитај речници, ажурирај, и да се надеваме дека ќе се промени на подобро.
Дали постои начин да се конфигурираат деталите во конфигурацијата ClickHouse, но да не се прикажуваат во случај на грешки?
Следното прашање е за грешки поврзани со речникот, имено детали. Ги наведовме деталите за врската во конфигурацијата ClickHouse за речникот и ако има грешка, ги добиваме овие детали и лозинка како одговор.
Ја решивме оваа грешка со додавање детали на конфигурацијата на двигателот ODBC. Дали постои начин да се конфигурираат деталите во конфигурацијата ClickHouse, но да не се прикажуваат овие детали во случај на грешки?
Вистинското решение овде е да ги наведете овие ингеренции во odbc.ini, а во самиот ClickHouse да го наведете само Името на изворот на податоци ODBC. Ова нема да се случи за други извори на речник - ниту за речникот со MySQL, ниту за другите, не треба да ја видите лозинката кога ќе примите порака за грешка. За ODBC, исто така ќе погледнам - ако постои, само треба да го отстраните.
Бонус: позадини за Зумирање од собири
Со кликнување на сликата, бонус позадините од собирите ќе се отворат за најупорните читатели. Го гаснеме пожарот заедно со маскотите на технологијата Avito, разговараме со колегите од просторијата на администраторот на системот или компјутерскиот клуб од старата школа и одржуваме секојдневни состаноци под мостот на позадината на графитите.
Извор: www.habr.com