Ефикасно коришћење ЦлицкХоусе-а. Алексеј Миловидов (Иандек)

Пошто је ЦлицкХоусе специјализован систем, приликом његовог коришћења важно је узети у обзир карактеристике његове архитектуре. У овом извештају, Алексеј ће говорити о примерима уобичајених грешака при коришћењу ЦлицкХоусе-а, што може довести до неефикасног рада. Практични примери ће показати како избор једне или друге шеме обраде података може променити перформансе по редоследу величине.

Здраво свима! Моје име је Алексеј, правим ЦлицкХоусе.

Прво, журим да вас одмах задовољим, данас вам нећу рећи шта је ЦлицкХоусе. Да будем искрен, уморан сам од тога. Сваки пут кад ти кажем шта је то. И вероватно сви већ знају.

Уместо тога, рећи ћу вам које су могуће грешке, односно како можете погрешно да користите ЦлицкХоусе. У ствари, нема потребе да се плашите, јер ми развијамо ЦлицкХоусе као систем који је једноставан, згодан и функционише без употребе. Инсталирао сам га, нема проблема.

Али ипак морате узети у обзир да је овај систем специјализован и да лако можете наићи на необичан случај употребе који ће овај систем избацити из зоне удобности.

Дакле, какве су грабуље ту? Углавном ћу причати о очигледним стварима. Свима је све очигледно, сви све разумеју и може им бити драго што су тако паметни, а ко не разуме научиће нешто ново.

Први и најједноставнији пример, који се, нажалост, често јавља, је велики број уметака са малим серијама, односно велики број малих уметака.

Ако узмемо у обзир како ЦлицкХоусе врши уметање, онда можете послати најмање терабајт података у једном захтеву. То није проблем.

И да видимо каква би била типична изведба. На пример, имамо табелу из података Иандек.Метрица. Хитови. 105 неке колоне. 700 бајтова некомпримовано. И убацићемо на добар начин у серијама од милион редова.

Убацимо МергеТрее у табелу, испада пола милиона редова у секунди. Велики. У реплицираној табели биће мало мањи, отприлике 400 редова у секунди.

А ако омогућите уметање кворума, добијате мало мање, али ипак пристојне перформансе, 250 термина у секунди. Уметање кворума је недокументована функција у ЦлицкХоусе*.

* од 2020. већ документовано.

Шта се дешава ако урадиш нешто лоше? Убацујемо један ред у табелу МергеТрее и добијамо 59 редова у секунди. То је 10 пута спорије. У РеплицатедМергеТрее – 000 редова у секунди. А ако је кворум укључен, онда се испоставља 6 реда у секунди. По мом мишљењу, ово је нека врста апсолутног срања. Како можеш тако да успориш? Чак имам написано на мајици да ЦлицкХоусе не би требало да успорава. Али ипак се то понекад дешава.

У ствари, то је наш недостатак. Могли смо лако да све урадимо како треба, али нисмо. И нисмо то урадили јер наш сценарио то није захтевао. Већ смо имали бутцхес. Управо смо примили серије на нашем улазу, и без проблема. Убацимо га и све ради како треба. Али, наравно, могући су разни сценарији. На пример, када имате гомилу сервера на којима се генеришу подаци. И не убацују податке тако често, али ипак завршавају честим уметањима. И то морамо некако да избегнемо.

Са техничке тачке гледишта, поента је да када урадите уметање у ЦлицкХоусе, подаци не завршавају ни у једној мемтабле. Немамо чак ни праву структуру дневника МергеТрее, већ само МергеТрее, јер не постоји ни дневник ни мемТабле. Једноставно одмах уписујемо податке у систем датотека, већ поређане у колоне. А ако имате 100 колона, онда ће више од 200 датотека морати да се упише у посебан директоријум. Све ово је веома гломазно.

И поставља се питање: "Како то учинити како треба?" Ако је ситуација таква да и даље морате некако да снимите податке у ЦлицкХоусе.

Метод 1. Ово је најлакши начин. Користите неку врсту дистрибуираног реда. На пример, Кафка. Једноставно извлачите податке из Кафке и групишете их једном у секунди. И све ће бити у реду, снимаш, све ради како треба.

Недостаци су што је Кафка још један гломазан дистрибуирани систем. Такође разумем да ли већ имате Кафку у свом друштву. Добро је, згодно је. Али ако не постоји, требало би да размислите три пута пре него што превучете још један дистрибуирани систем у свој пројекат. И зато је вредно размислити о алтернативама.

Метод 2. Ово је алтернатива старе школе и у исто време веома једноставна. Да ли имате неку врсту сервера који генерише ваше дневнике. И само записује ваше евиденције у датотеку. И једном у секунди, на пример, преименујемо ову датотеку и откидамо нову. И посебна скрипта, било преко црон-а или неког демона, узима најстарију датотеку и записује је у ЦлицкХоусе. Ако снимате дневнике једном у секунди, онда ће све бити у реду.

Али недостатак ове методе је у томе што ако ваш сервер на коме се генеришу евиденције негде нестане, онда ће и подаци нестати.

Метод 3. Постоји још један занимљив метод, који уопште не захтева привремене датотеке. На пример, имате неку врсту рекламног спинера или неког другог занимљивог демона који генерише податке. И можете акумулирати гомилу података директно у РАМ-у, у баферу. А када прође довољно времена, овај бафер одложите, направите нови и у посебну нит убаците оно што се већ накупило у ЦлицкХоусе.

С друге стране, подаци такође нестају са килл -9. Ако се ваш сервер сруши, изгубићете ове податке. Још један проблем је што ако нисте били у могућности да пишете у базу података, онда ће се ваши подаци акумулирати у РАМ-у. И или ће РАМ-а понестати, или ћете једноставно изгубити податке.

Метода 4. Још једна занимљива метода. Да ли имате неку врсту серверског процеса. И може одмах да пошаље податке у ЦлицкХоусе, али то уради у једној вези. На пример, послао сам хттп захтев са трансфер-кодирањем: у комадима са уметнутим. И генерише делове не превише ретко, можете послати сваку линију, иако ће бити додатних трошкова за уоквиривање ових података.

Међутим, у овом случају подаци ће одмах бити послати ЦлицкХоусе-у. И ЦлицкХоусе ће их сам баферовати.

Али се јављају и проблеми. Сада ћете изгубити податке, укључујући када је ваш процес убијен и ако је процес ЦлицкХоусе убијен, јер ће то бити непотпуни уметак. А у ЦлицкХоусе уметци су атомични до одређеног одређеног прага у величини редова. У принципу, ово је занимљив начин. Такође се може користити.

Метод 5. Ево још једне занимљиве методе. Ово је нека врста сервера који је развила заједница за прикупљање података. Нисам га лично погледао, тако да не могу ништа да гарантујем. Међутим, за сам ЦлицкХоусе нису дате гаранције. Ово је такође отвореног кода, али с друге стране, можда сте навикли на неки стандард квалитета који покушавамо да обезбедимо. Али за ову ствар - не знам, идите на ГитХуб, погледајте код. Можда су написали нешто нормално.

* од 2020. такође треба додати у разматрање КиттенХоусе.

Метод 6. Други метод је коришћење Табела бафера. Предност ове методе је у томе што је врло лако почети користити. Направите табелу бафера и уметните је у њу.

Недостатак је што проблем није у потпуности решен. Ако, у брзини као што је МергеТрее, морате да групишете податке за једну групу у секунди, онда у стопи у табели бафера, морате да групишете најмање до неколико хиљада у секунди. Ако је више од 10 у секунди, и даље ће бити лоше. А ако га убаците у серијама, онда сте видели да се испоставља да је то сто хиљада редова у секунди. А ово је већ на прилично тешким подацима.

Такође, табеле бафера немају дневник. А ако нешто није у реду са вашим сервером, подаци ће бити изгубљени.

И као бонус, недавно смо добили прилику у ЦлицкХоусе-у да преузмемо податке од Кафке. Постоји стони мотор - Кафка. Ви само стварате. И на њега можете окачити материјализоване представе. У овом случају, он ће сам извући податке из Кафке и уметнути их у табеле које су вам потребне.

А оно што посебно радује у овој прилици је да то нисмо ми урадили. Ово је карактеристика заједнице. А када кажем „одлика заједнице“, мислим то без икаквог презира. Прочитали смо код, урадили преглед, требало би да ради добро.

* од 2020. појавила се слична подршка за РаббитМК.

Шта би још могло бити незгодно или неочекивано приликом уметања података? Ако направите захтев за уметање вредности и напишете неке израчунате изразе у вредностима. На пример, нов() је такође израчунати израз. И у овом случају, ЦлицкХоусе је приморан да покрене интерпретатор ових израза на свакој линији, а перформансе ће пасти за редове величине. Боље је ово избегавати.

* тренутно је проблем потпуно решен, више нема регресије перформанси када се користе изрази у ВАЛУЕС.

Други пример је када може доћи до проблема када имате податке о једној групи која припада гомили партиција. Подразумевано, ЦлицкХоусе партиције су по месецима. А ако убаците групу од милион редова, а постоје подаци за неколико година, онда ћете тамо имати неколико десетина партиција. А то је еквивалентно чињеници да ће постојати серије неколико десетина пута мањих, јер су унутра увек прво подељене на партиције.

* Недавно, у експерименталном режиму, ЦлицкХоусе је додао подршку за компактни формат цхунк-а и цхунк-ова у РАМ-у са записом унапред, што скоро у потпуности решава проблем.

Погледајмо сада другу врсту проблема - куцање података.

Унос података може бити строг или стринг. Стринг је када сте га управо узели и изјавили да су сва ваша поља типа стринг. Ово је срање. Нема потребе да се ово ради.

Хајде да смислимо како то да урадимо исправно у оним случајевима када желите да кажете да имамо неко поље, стринг, и нека ЦлицкХоусе то сам схвати, а ја се нећу мучити. Али ипак вреди уложити мало труда.

На пример, имамо ИП адресу. У једном случају смо га сачували као стринг. На пример, 192.168.1.1. А у другом случају, то ће бити број типа УИнт32*. 32 бита је довољно за ИПв4 адресу.

Прво, колико је чудно, подаци ће бити компримовани приближно подједнако. Биће разлике, наравно, али не толико. Дакле, нема посебних проблема са диск И/О.

Али постоји озбиљна разлика у времену процесора и времену извршења упита.

Хајде да избројимо број јединствених ИП адреса ако су сачуване као бројеви. То ради на 137 милиона линија у секунди. Ако је исти у облику стрингова, онда 37 милиона редова у секунди. Не знам зашто је дошло до ове случајности. Сам сам извршио ове захтеве. Али и даље око 4 пута спорије.

А ако израчунате разлику у простору на диску, онда постоји и разлика. А разлика је око једне четвртине, јер има доста јединствених ИП адреса. А када би постојали редови са малим бројем различитих значења, онда би се лако сабили према речнику у приближно исту запремину.

А четворострука временска разлика не лежи на путу. Можда те није брига, наравно, али када видим такву разлику, растужим се.

Погледајмо различите случајеве.

1. Један случај када имате неколико различитих јединствених вредности. У овом случају користимо једноставну праксу коју вероватно знате и коју можете користити за било који ДБМС. Све ово има смисла не само за ЦлицкХоусе. Само упишите нумеричке идентификаторе у базу података. И можете конвертовати у стрингове и назад са стране ваше апликације.

На пример, имате регион. И покушавате да га сачувате као стринг. И тамо ће бити написано: Москва и Московска област. И кад видим да пише „Москва“, није ништа, али када је Москва, некако постане потпуно тужно. Ово је колико бајтова.

Уместо тога, једноставно запишемо број Улнт32 и 250. Имамо 250 у Иандек-у, али ваш може бити другачији. За сваки случај, рећи ћу да ЦлицкХоусе има уграђену могућност рада са геобазом. Једноставно запишете директоријум са регионима, укључујући и хијерархијски, односно биће Москва, Московска област и све што вам треба. И можете конвертовати на нивоу захтева.

Друга опција је приближно иста, али са подршком унутар ЦлицкХоусе-а. Ово је тип података Енум. Једноставно уписујете све вредности које су вам потребне унутар Енума. На пример, тип уређаја и напишите: десктоп, мобилни, таблет, ТВ. Укупно постоје 4 опције.

Недостатак је што га морате периодично мењати. Додата је само једна опција. Хајде да променимо табелу. У ствари, алтер табле у ЦлицкХоусе-у је бесплатна. Посебно бесплатно за Енум јер се подаци на диску не мењају. Али ипак, алтер добија закључавање* на табели и мора да сачека док се не изврше сви избори. И тек након што ће ова измена бити извршена, тј. и даље постоје неке непријатности.

* у најновијим верзијама ЦлицкХоусе-а, АЛТЕР је потпуно неблокирајући.

Друга опција која је прилично јединствена за ЦлицкХоусе је повезивање екстерних речника. Можете писати бројеве у ЦлицкХоусе-у и држати своје именике у било ком систему који вам одговара. На пример, можете користити: МиСКЛ, Монго, Постгрес. Можете чак и да креирате сопствену микросервис која ће слати ове податке преко хттп. А на нивоу ЦлицкХоусе пишете функцију која ће ове податке претворити из бројева у низове.

Ово је специјализован, али веома ефикасан начин да се изврши спајање на спољној табели. И постоје две опције. У једном аспекту, ови подаци ће бити потпуно кеширани, потпуно присутни у РАМ-у и ажурирани са одређеном фреквенцијом. И у другој опцији, ако се ови подаци не уклапају у РАМ, можете их делимично кеширати.

Ево примера. Постоји Иандек.Дирецт. А ту је и рекламна компанија и банери. Вероватно постоји око десетине милиона рекламних компанија. И отприлике се уклапају у РАМ. И постоје милијарде банера, они се не уклапају. И користимо кеширани речник из МиСКЛ-а.

Једини проблем је што ће кеширани речник радити добро ако је стопа погодака близу 100%. Ако је мањи, онда када обрађујете упите за сваку групу података, заправо ћете морати да узмете кључеве који недостају и да преузмете податке из МиСКЛ-а. Што се тиче ЦлицкХоусе-а, то и даље могу да гарантујем - да, не успорава, нећу да причам о другим системима.

И као бонус, речници су веома лак начин за ретроактивно ажурирање података у ЦлицкХоусе-у. То јест, имали сте извештај о рекламним компанијама, корисник је једноставно променио рекламну компанију и у свим старим подацима, у свим извештајима, и ови подаци су се променили. Ако редове упишете директно у табелу, биће немогуће ажурирати их.

Други начин када не знате где да добијете идентификаторе за своје стрингове. можете га једноставно хеширати. Штавише, најједноставнија опција је да узмете 64-битни хеш.

Једини проблем је што ако је хеш 64-битни, онда ћете скоро сигурно имати колизије. Јер ако тамо има милијарду линија, онда вероватноћа већ постаје приметна.

И не би било добро да се на овај начин хеширају имена рекламних компанија. Ако су рекламне кампање различитих компанија помешане, онда ће бити нешто несхватљиво.

И постоји једноставан трик. Истина, није баш погодан за озбиљне податке, али ако нешто није јако озбиљно, онда само додајте идентификатор клијента кључу речника. И тада ћете имати колизије, али само унутар једног клијента. И ми користимо овај метод за мапе веза у Иандек.Метрици. Тамо имамо УРЛ-ове, чувамо хеш. А знамо да, наравно, има судара. Али када се страница прикаже, вероватноћа да су на једној страници једног корисника неки УРЛ-ови заглављени и да ће се то приметити може се занемарити.

Као бонус, за многе операције су довољни сами хешови и сами низови не морају нигде да се чувају.

Други пример је ако су стрингови кратки, на пример, домени веб локације. Могу се чувати онаквима какви јесу. Или, на пример, језик претраживача ру – 2 бајта. Наравно, заиста ми је жао бајтова, али не брините, 2 бајта нису штета. Молим вас да остане како јесте, не брините.

Други случај је када, напротив, има много линија и има много јединствених у њима, а чак је и скуп потенцијално неограничен. Типичан пример су фразе за претрагу или УРЛ адресе. Фразе за претрагу, укључујући грешке у куцању. Хајде да видимо колико јединствених фраза за претрагу има дневно. И испоставило се да су они скоро половина свих догађаја. И у овом случају, можда мислите да морате нормализовати податке, пребројати идентификаторе и ставити их у засебну табелу. Али не морате то да радите. Само задржите ове линије онакве какве јесу.

Боље је не измишљати ништа, јер ако га складиштите одвојено, мораћете да извршите спајање. А ово спајање је, у најбољем случају, случајни приступ меморији, ако се још уклапа у меморију. Ако се не уклапа, онда ће бити проблема.

А ако су подаци ускладиштени на месту, онда се једноставно читају у траженом редоследу из система датотека и све је у реду.

Ако имате УРЛ адресе или неки други сложени дуги низ, онда је вредно размислити да можете унапред израчунати неку врсту екстракта и написати га у посебну колону.

За УРЛ адресе, на пример, можете засебно да складиштите домен. А ако вам је заиста потребан домен, само користите ову колону и УРЛ-ови ће лежати тамо, а нећете их ни додирнути.

Да видимо у чему је разлика. ЦлицкХоусе има специјализовану функцију која израчунава домен. Веома је брз, оптимизовали смо га. И, да будем искрен, није чак ни у складу са РФЦ-ом, али ипак узима у обзир све што нам треба.

А у једном случају ћемо једноставно добити УРЛ адресе и израчунати домен. То ради до 166 милисекунди. А ако узмете готов домен, онда се испостави да је само 67 милисекунди, односно скоро три пута брже. И то је брже не зато што морамо да урадимо неке прорачуне, већ зато што читамо мање података.

Зато један захтев, који је спорији, има већу брзину од гигабајта у секунди. Зато што чита више гигабајта. Ово су потпуно непотребни подаци. Изгледа да захтев ради брже, али је потребно више времена да се заврши.

А ако погледате количину података на диску, испоставља се да је УРЛ 126 мегабајта, а домен само 5 мегабајта. Испада 25 пута мање. Али ипак, захтев се извршава само 4 пута брже. Али то је зато што су подаци врући. А да је хладно, вероватно би било 25 пута брже због диска И/О.

Иначе, ако процените колико је домен мањи од УРЛ-а, испоставиће се да је око 4 пута мањи.Али из неког разлога подаци заузимају 25 пута мање на диску. Зашто? Због компресије. И УРЛ је компримован, а домен је компримован. Али често УРЛ садржи гомилу смећа.

И, наравно, исплати се користити праве типове података који су дизајнирани посебно за жељене вредности или који су прикладни. Ако сте у ИПв4, сачувајте УИнт32*. Ако је ИПв6, онда ФикедСтринг(16), јер је ИПв6 адреса 128 бита, односно ускладиштена директно у бинарном формату.

Али шта ако понекад имате ИПв4 адресе, а понекад ИПв6? Да, можете сачувати оба. Једна колона за ИПв4, друга за ИПв6. Наравно, постоји опција за приказ ИПв4 у ИПв6. Ово ће такође функционисати, али ако вам је често потребна ИПв4 адреса у захтевима, онда би било лепо да је ставите у посебну колону.

* ЦлицкХоусе сада има одвојене ИПв4, ИПв6 типове података који складиште податке ефикасно као бројеви, али их представљају згодно као стрингови.

Такође је важно напоменути да је вредно унапред обрадити податке. На пример, добијате неке необрађене дневнике. И можда не бисте требали одмах да их ставите у ЦлицкХоусе, иако је веома примамљиво не радити ништа и све ће функционисати. Али ипак вреди извршити прорачуне који су могући.

На пример, верзија претраживача. У неком оближњем одељењу, на које не желим да упирем прстом, верзија претраживача се чува овако, односно као стринг: 12.3. А онда, да би направили извештај, узимају овај низ и деле га на низ, а затим на први елемент низа. Наравно, све се успорава. Питао сам зашто то раде. Рекли су ми да не воле преурањену оптимизацију. И не волим преурањену песимизацију.

Дакле, у овом случају би било исправније поделити у 4 колоне. Не бојте се овде, јер ово је ЦлицкХоусе. ЦлицкХоусе је колонаста база података. И што је уреднијих малих колона, то боље. Биће 5 верзија претраживача, направите 5 колона. Ово је добро.

Хајде сада да погледамо шта да радимо ако имате много веома дугих низова, веома дугих низова. Уопште их не треба чувати у ЦлицкХоусе-у. Уместо тога, идентификатор можете сачувати само у ЦлицкХоусе-у. И ставите ове дугачке редове у неки други систем.

На пример, једна од наших аналитичких услуга има неке параметре догађаја. А ако има много параметара за догађаје, једноставно сачувамо првих 512 на које наиђемо. Јер 512 није штета.

А ако не можете да одлучите о својим типовима података, онда можете и да снимите податке у ЦлицкХоусе, али у привремену табелу типа Лог, посебно за привремене податке. Након тога, можете анализирати коју дистрибуцију вредности имате тамо, шта уопште постоји и креирати исправне типове.

*ЦлицкХоусе сада има тип података Ниска кардиналност што вам омогућава да ефикасно складиштите жице уз мање напора.

Погледајмо сада још један занимљив случај. Понекад ствари функционишу чудно за људе. Уђем и видим ово. И одмах се чини да је то урадио неки веома искусан, паметан администратор који има велико искуство у постављању МиСКЛ верзије 3.23.

Овде видимо хиљаду табела, од којих свака бележи остатак дељења ко зна шта са хиљаду.

У принципу, поштујем туђа искуства, укључујући и разумевање патње која се може стећи кроз ово искуство.

А разлози су мање-више јасни. То су стари стереотипи који су се можда накупили током рада са другим системима. На пример, МиИСАМ табеле немају груписани примарни кључ. А овај начин поделе података може бити очајнички покушај да се добије иста функционалност.

Други разлог је тај што је тешко извршити било какве промене на великим столовима. Све ће бити блокирано. Иако у модерним верзијама МиСКЛ-а овај проблем више није тако озбиљан.

Или, на пример, микрошардинг, али о томе касније.

Нема потребе да се то ради у ЦлицкХоусе-у, јер је, прво, примарни кључ груписан, подаци су поређани по примарном кључу.

Понекад ме људи питају: „Како се перформансе упита опсега у ЦлицкХоусе-у разликују у зависности од величине табеле?“ Ја кажем да се то уопште не мења. На пример, имате табелу са милијарду редова и читате опсег од милион редова. Све је у реду. Ако у табели постоји трилион редова, а ви прочитате милион редова, биће скоро исто.

И, друго, све врсте ствари као што су ручне партиције нису потребне. Ако уђете и погледате шта је у систему датотека, видећете да је табела прилично велика ствар. А унутра је нешто попут преграда. То јест, ЦлицкХоусе ради све за вас и не морате да патите.

Измена у ЦлицкХоусе-у је бесплатна ако промените колону за додавање/испуштање.

И не би требало да правите мале табеле, јер ако имате 10 редова или 10 редова у табели, онда то уопште није важно. ЦлицкХоусе је систем који оптимизује проток, а не кашњење, тако да нема смисла обрађивати 000 линија.

Исправно је користити један велики сто. Ослободите се старих стереотипа, све ће бити у реду.

И као бонус, у најновијој верзији сада имамо могућност да креирамо произвољни кључ за партиционисање како бисмо извршили све врсте операција одржавања на појединачним партицијама.

На пример, потребно вам је много малих табела, на пример, када постоји потреба за обрадом неких међуподатака, добијате делове и треба да извршите трансформацију на њима пре него што упишете у коначну табелу. За овај случај постоји диван стони мотор - СтрипеЛог. То је као ТиниЛог, само боље.

* сада има и ЦлицкХоусе унос функције табеле.

Још један антиузорак је микрошардинг. На пример, потребно је да поделите податке и имате 5 сервера, а сутра ће бити 6 сервера. И размислите о томе како да ребалансирате ове податке. И уместо тога разбијате се не на 5 комада, већ на 1 комада. И онда мапирате сваку од ових микрошардова на посебан сервер. И добићете, на пример, 000 ЦлицкХоусе-а на једном серверу, на пример. Одвојене инстанце на одвојеним портовима или одвојеним базама података.

Али ово није баш добро у ЦлицкХоусе-у. Зато што чак и једна ЦлицкХоусе инстанца покушава да искористи све доступне ресурсе сервера за обраду једног захтева. То јест, имате неку врсту сервера и он има, на пример, 56 процесорских језгара. Покрећете упит који траје једну секунду и користиће 56 језгара. А ако поставите 200 ЦлицкХоусе-а тамо на један сервер, онда се испостави да ће се покренути 10 нити. Генерално, све ће бити веома лоше.

Други разлог је тај што ће расподела посла на овим инстанцама бити неуједначена. Неки ће завршити раније, неки ће завршити касније. Ако би се све ово догодило у једној инстанци, онда би ЦлицкХоусе сам схватио како правилно дистрибуирати податке међу нитима.

И други разлог је тај што ћете имати међупроцесорску комуникацију преко ТЦП-а. Подаци ће морати да се серијализују, десериализују, а ради се о огромном броју микрошардова. Једноставно неће функционисати ефикасно.

Још један антиузорак, иако се тешко може назвати антишаблом. Ово је велика количина претходног здруживања.

Генерално, претходно здруживање је добро. Имали сте милијарду редова, агрегирали сте то и постало је 1 редова, а сада се упит извршава тренутно. Све је супер. Можете да урадите ово. А за ово, чак и ЦлицкХоусе има посебан тип табеле, АггрегатингМергеТрее, који врши инкрементално агрегирање како се подаци убацују.

Али има тренутака када мислите да ћемо агрегирати податке овако и овако. А у неком суседном одељењу, такође не желим да кажем у ком, користе табеле СуммингМергеТрее за сумирање по примарном кључу, а око 20 колона се користи као примарни кључ. За сваки случај, променио сам називе неких колона ради тајности, али то је углавном то.

И такви проблеми настају. Прво, обим ваших података се не смањује превише. На пример, смањује се за три пута. Три пута би била добра цена да приуштите неограничене аналитичке могућности које настају ако ваши подаци нису агрегирани. Ако су подаци агрегирани, онда уместо аналитике добијате само јадну статистику.

И шта је ту тако посебно? Чињеница је да ови људи из суседног одељења понекад оду и траже да додају још једну колону примарном кључу. Односно, овако смо агрегирали податке, али сада желимо мало више. Али ЦлицкХоусе нема алтер примарни кључ. Због тога морамо да напишемо неке скрипте у Ц++. И не волим скрипте, чак и ако су на Ц++.

А ако погледате за шта је ЦлицкХоусе створен, онда су неагрегирани подаци управо сценарио за који су рођени. Ако користите ЦлицкХоусе за неагрегиране податке, онда то радите како треба. Ако збројите, ово се понекад може опростити.

Још један занимљив случај су упити у бесконачној петљи. Понекад одем на неки производни сервер и тамо погледам листу процеса. И сваки пут када откријем да се дешава нешто страшно.

На пример, овако. Одмах је јасно да се све може урадити у једном захтеву. Само упишите УРЛ и листу тамо.

Зашто је много таквих упита у бескрајној петљи лоше? Ако се индекс не користи, имаћете много прелазака преко истих података. Али ако се користи индекс, на пример, имате примарни кључ за ру и тамо пишете урл = нешто. И мислите да ако се из табеле прочита само један УРЛ, све ће бити у реду. Али заправо не. Зато што ЦлицкХоусе ради све у серијама.

Када треба да прочита одређени опсег података, чита мало више, јер је индекс у ЦлицкХоусе-у оскудан. Овај индекс вам не дозвољава да пронађете један појединачни ред у табели, само неки опсег. И подаци су компримовани у блоковима. Да бисте прочитали један ред, потребно је да узмете цео блок и отпустите га. А ако радите гомилу упита, имаћете много преклапања и имаћете много посла да радите изнова и изнова.

И као бонус, можете приметити да се у ЦлицкХоусе-у не треба плашити да пренесете чак и мегабајте, па чак и стотине мегабајта у одељак ИН. Сећам се из наше праксе да ако у МиСКЛ-у пренесемо гомилу вредности у ИН секцију, на пример, тамо пренесемо 100 мегабајта неких бројева, онда МиСКЛ поједе 10 гигабајта меморије и ништа му се више не дешава, све ради лоше.

А друго је да у ЦлицкХоусе-у, ако ваши упити користе индекс, онда то увек није спорије од потпуног скенирања, односно ако треба да прочитате скоро целу табелу, она ће ићи узастопно и читати целу табелу. Генерално, он ће то сам схватити.

Али ипак постоје неке потешкоће. На пример, чињеница да ИН са потупитом не користи индекс. Али ово је наш проблем и морамо га поправити. Овде нема ничег фундаменталног. Поправићемо то*.

И још једна занимљива ствар је да ако имате веома дуг захтев и обрада дистрибуираног захтева је у току, онда ће овај веома дуг захтев бити послат на сваки сервер без компресије. На пример, 100 мегабајта и 500 сервера. И, сходно томе, имаћете 50 гигабајта пренетих преко мреже. Биће пренето и онда ће све бити успешно завршено.

* већ користи; Све је поправљено како је обећано.

А прилично чест случај је када захтеви долазе из АПИ-ја. На пример, направили сте неку врсту сопствене услуге. А ако некоме треба ваша услуга, онда отворите АПИ и буквално два дана касније видите да се дешава нешто несхватљиво. Све је преоптерећено и стижу неки страшни захтеви који никада нису смели да се десе.

И постоји само једно решење. Ако сте отворили АПИ, мораћете да га исечете. На пример, увести неку врсту квота. Нема других нормалних опција. У супротном, одмах ће написати сценарио и биће проблема.

А ЦлицкХоусе има посебну функцију - обрачун квота. Штавише, можете пренети свој кључ квоте. Ово је, на пример, интерни кориснички ИД. А квоте ће се израчунавати независно за сваку од њих.

Сада још једна занимљива ствар. Ово је ручна репликација.

Знам за многе случајеве у којима, упркос томе што ЦлицкХоусе има уграђену подршку за репликацију, људи ручно реплицирају ЦлицкХоусе.

Шта је принцип? Имате цев за обраду података. И ради независно, на пример, у различитим центрима података. Исте податке пишете на исти начин у ЦлицкХоусе-у. Истина, пракса показује да ће се подаци и даље разликовати због неких карактеристика у вашем коду. Надам се да је у твом.

А с времена на време и даље ћете морати ручно да синхронизујете. На пример, једном месечно администратори раде рсинц.

У ствари, много је лакше користити репликацију уграђену у ЦлицкХоусе. Али могу постојати неке контраиндикације, јер за ово морате користити ЗооКеепер. Нећу рећи ништа лоше о ЗооКееперу, у принципу систем ради, али се дешава да га људи не користе због јава-фобије, јер је ЦлицкХоусе тако добар систем, написан на Ц++, који можете користити и све ће бити у реду. А ЗооКеепер је у Јави. И некако не желите ни да гледате, али онда можете користити ручну репликацију.

ЦлицкХоусе је практичан систем. Она узима у обзир ваше потребе. Ако имате ручну репликацију, онда можете креирати дистрибуирану табелу која гледа ваше ручне реплике и врши пребацивање између њих. А постоји чак и посебна опција која вам омогућава да избегнете неуспехе, чак и ако се ваше линије систематски разилазе.

Даљи проблеми могу настати ако користите примитивне машине за таблице. ЦлицкХоусе је конструктор који има гомилу различитих машина за таблице. За све озбиљне случајеве, како пише у документацији, користите табеле из породице МергеТрее. А све остало - то је тако, за појединачне случајеве или за тестове.

У табели МергеТрее, не морате да имате датум и време. Још увек можете да га користите. Ако нема датума и времена, напишите да је подразумевано 2000. Ово ће радити и неће захтевати ресурсе.

А у новој верзији сервера можете чак да наведете да имате прилагођено партиционисање без партиционог кључа. Биће исто.

С друге стране, можете користити примитивне машине за таблице. На пример, једном попуните податке и погледајте, уврните и избришите. Можете користити Лог.

Или складиштење малих количина за међуобраду је СтрипеЛог или ТиниЛог.

Меморија се може користити ако је количина података мала и можете једноставно нешто да изврћете у РАМ-у.

ЦлицкХоусе баш и не воли ренормализоване податке.

Ево типичног примера. Ово је огроман број УРЛ адреса. Ставите их у следећу табелу. И онда су одлучили да ураде ЈОИН са њима, али то по правилу неће радити, јер ЦлицкХоусе подржава само Хасх ЈОИН. Ако нема довољно РАМ-а за много података које треба повезати, ЈОИН неће радити*.

Ако су подаци високе кардиналности, онда не брините, чувајте их у денормализованом облику, УРЛ адресе су директно на месту у главној табели.

* и сада ЦлицкХоусе такође има спајање спајања, и ради у условима у којима се средњи подаци не уклапају у РАМ. Али ово је неефикасно и препорука остаје на снази.

Још пар примера, али већ сумњам да ли су анти-паттерн или не.

ЦлицкХоусе има једну познату ману. Не зна како да се ажурира*. На неки начин, ово је чак и добро. Ако имате неке важне податке, на пример, рачуноводство, онда нико неће моћи да их пошаље, јер нема ажурирања.

* подршка за ажурирање и брисање у групном режиму је одавно додата.

Али постоје неки посебни начини који омогућавају ажурирање као у позадини. На пример, табеле попут РеплацеМергеТрее. Они праве ажурирања током спајања у позадини. Ово можете присилити користећи табелу оптимизације. Али немојте то радити пречесто, јер ће то потпуно преписати партицију.

Планер упита такође лоше управља дистрибуираним ЈОИН-овима у ЦлицкХоусе-у.

Лоше, али понекад ок.

Коришћење ЦлицкХоусе само за читање података помоћу селецт*.

Не бих препоручио да користите ЦлицкХоусе за гломазне прорачуне. Али то није сасвим тачно, јер се већ удаљавамо од ове препоруке. И недавно смо додали могућност примене модела машинског учења у ЦлицкХоусе - Цатбоост. И смета ми јер мислим: „Какав ужас. Ово је колико циклуса по бајту испада! Заиста мрзим трошење сатова на бајтове.

Али не бојте се, инсталирајте ЦлицкХоусе, све ће бити у реду. Ако ништа друго, имамо заједницу. Иначе, заједница сте ви. А ако имате било каквих проблема, можете барем отићи на наш разговор, и надамо се да ће вам помоћи.

pitanja

Хвала на извештају! Где могу да се жалим на рушење ЦлицкХоусе-а?

Можете се одмах жалити мени лично.

Недавно сам почео да користим ЦлицкХоусе. Одмах сам испустио Цли интерфејс.

Имате среће.

Мало касније сам срушио сервер са малим одабиром.

Имаш таленат.

Отворио сам грешку на ГитХуб-у, али је игнорисана.

Видећемо.

Алексеј ме је преварио да присуствујем извештају, обећавајући да ће ми рећи како приступате подацима који су унутра.

Врло једноставно.

Схватио сам ово јуче. Више појединости.

Ту нема страшних трикова. Постоји само компресија блок по блок. Подразумевано је ЛЗ4, можете омогућити ЗСТД*. Блокира од 64 килобајта до 1 мегабајта.

* постоји и подршка за специјализоване кодеке за компресију који се могу користити у ланцу са другим алгоритмима.

Да ли су блокови само необрађени подаци?

Није потпуно сирово. Постоје низови. Ако имате нумеричку колону, бројеви у реду се постављају у низ.

То је јасно.

Алексеј, пример који је био са уникЕкацт-ом преко ИП-ова, односно чињеница да је уникЕкацт-у потребно више времена да се израчуна по линијама него по бројевима итд. Шта ако употребимо финту са ушима и гипс у време лектуре? То јест, чини се да сте рекли да на нашем диску није много другачије. Ако читамо линије са диска и бацамо, да ли ће наши агрегати бити бржи или не? Или ћемо ипак мало добити овде? Чини ми се да сте ово тестирали, али из неког разлога то нисте навели у бенчмарку.

Мислим да ће бити спорије него без бацања. У овом случају, ИП адреса мора бити рашчлањена из стринга. Наравно, у ЦлицкХоусе-у, наша анализа ИП адреса је такође оптимизована. Много смо се трудили, али ето вам бројке написане у десетхиљадитом облику. Веома непријатно. С друге стране, функција уникЕкацт ће радити спорије на стринговима, не само зато што су то стрингови, већ и зато што је изабрана другачија специјализација алгоритма. Стрингови се једноставно обрађују другачије.

Шта ако узмемо примитивнији тип података? На пример, записали смо ИД корисника, који имамо у, записали га као ред, а затим га кодирали, да ли ће бити забавније или не?

Сумњам. Мислим да ће бити још тужније, јер је ипак рашчлањивање бројева озбиљан проблем. Чини ми се да је овај колега чак дао извештај о томе колико је тешко рашчланити бројеве у десетхиљадитом облику, али можда и није.

Алексеј, хвала ти пуно на извештају! И пуно вам хвала за ЦлицкХоусе! Имам питање у вези планова. Да ли постоје планови за функцију за непотпуно ажурирање речника?

То јест, делимично поновно покретање?

Да да. Попут могућности да се тамо постави МиСКЛ поље, односно ажурирање после тако да се само ови подаци учитавају ако је речник веома велики.

Веома занимљива карактеристика. И мислим да је нека особа то предложила у нашем ћаскању. Можда си чак и ти.

Ја не мислим тако.

Одлично, сад се испоставило да постоје два захтева. И можете полако почети то да радите. Али желим да вас одмах упозорим да је ова функција прилично једноставна за имплементацију. То јест, у теорији, само треба да упишете број верзије у табелу, а затим напишете: верзија мање од такве и такве. То значи да ћемо, највероватније, ово понудити ентузијастима. Јесте ли ентузијаста?

Да, али, нажалост, не у Ц++.

Да ли ваше колеге знају да пишу на Ц++?

Наћи ћу некога.

Велики*.

* функција је додата два месеца након извештаја - аутор питања га је развио и послао своје повуци захтев.

Хвала!

Здраво! Хвала на извештају! Споменули сте да је ЦлицкХоусе веома добар у конзумирању свих ресурса који су му доступни. А говорник поред Лукофта говорио је о свом решењу за руску пошту. Рекао је да им се ЦлицкХоусе веома допао, али га нису користили уместо свог главног конкурента управо зато што је јео сав ЦПУ. И нису могли да га укључе у своју архитектуру, у свој ЗооКеепер са докерима. Да ли је могуће некако ограничити ЦлицкХоусе да не троши све што му постане доступно?

Да, могуће је и врло лако. Ако желите да потрошите мање језгара, само напишите set max_threads = 1. И то је то, извршиће захтев у једном језгру. Штавише, можете одредити различите поставке за различите кориснике. Дакле, нема проблема. И реците својим колегама из Лукофта да није добро што ову поставку нису нашли у документацији.

Алексеј, здраво! Хтео бих да поставим питање о овом питању. Ово није први пут да чујем да многи људи почињу да користе ЦлицкХоусе као складиште за евиденцију. У извештају сте рекли да то не радите, тј. не морате да чувате дугачке низове. Шта мислите о томе?

Прво, трупци по правилу нису дуги низови. Постоје, наравно, изузеци. На пример, неки сервис написан у Јави избацује изузетак, он се евидентира. И тако у бескрајној петљи, а простор на чврстом диску понестаје. Решење је врло једноставно. Ако су линије веома дугачке, онда их исеците. Шта значи дуго? Десетине килобајта су лоше*.

* у најновијим верзијама ЦлицкХоусе-а омогућена је „прилагодљива грануларност индекса“, што највећим делом елиминише проблем складиштења дугих редова.

Да ли је килобајт нормалан?

Нормално је.

Здраво! Хвала на извештају! Већ сам питао о томе у ћаскању, али се не сећам да ли сам добио одговор. Има ли у плану да се део СА некако прошири на начин ЦТЕ?

Још није. Наш одељак СА је помало неозбиљан. То је за нас као мала карактеристика.

Разумем. Хвала вам!

Хвала на извештају! Веома занимљиво! Глобално питање. Да ли постоје планови за измену брисања података, можда у облику неке врсте стубова?

Неопходно. Ово је наш први задатак у реду. Сада активно размишљамо о томе како све учинити исправно. И требало би да почнете да притискате тастатуру*.

* притиснуо дугмад на тастатури и урадио све.

Хоће ли то некако утицати на перформансе система или не? Да ли ће уметање бити брзо као што је сада?

Можда ће сама брисања и сама ажурирања бити веома тешка, али то неће утицати на перформансе избора или уметања.

И још једно мало питање. На презентацији сте говорили о примарном кључу. Сходно томе, имамо партиционисање, које је подразумевано месечно, зар не? А када поставимо период који се уклапа у месец, онда се чита само ова партиција, зар не?

Да.

Питање. Ако не можемо да изаберемо ниједан примарни кључ, да ли је исправно да то урадимо посебно према пољу „Датум“ како би у позадини било мање преуређивања ових података како би се уклопили на уреднији начин? Ако немате упите за опсег и не можете чак ни да изаберете ниједан примарни кључ, да ли је вредно ставити датум у примарни кључ?

Да.

Можда има смисла ставити поље у примарни кључ које ће боље компримовати податке ако се сортирају по овом пољу. На пример, ИД корисника. Корисник, на пример, иде на исти сајт. У овом случају унесите ИД корисника и време. И тада ће ваши подаци бити боље компримовани. Што се тиче датума, ако заиста немате и никада немате упите о опсегу за датуме, онда не морате да стављате датум у примарни кључ.

ОК хвала Вам пуно!

Извор: ввв.хабр.цом