ЦлицкХоусе за напредне кориснике у питањима и одговорима

Авито инжењери су се у априлу окупили на онлајн састанцима са главним ЦлицкХоусе програмером Алексејем Миловидовим и Кирилом Шваковим, Голанг програмером из Интегроса. Разговарали смо о томе како користимо систем за управљање базом података и на какве потешкоће наилазимо.

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

Пазите, испод реза има доста текста. Надамо се да ће вам садржај са питањима помоћи да се снађете.

Садржина

• ЦлицкХоусе се стално ажурира, али наши подаци нису. Шта учинити поводом тога?
• Које су тренутне најбоље праксе за прављење резервних копија података са ЦлицкХоусе-а?
• Да ли ће бити могуће организовати контролисано заостајање реплика у шахтовима?
• Шта ако се структура табеле променила?
• Које су тренутне најбоље праксе за поновно дељење података?
• ЦлицкХоусе има услужни програм цлицкхоусе-цопиер. Можете ли нам рећи нешто о њој?
• Имали сте пилот ствар која се зове ресхардинг. Шта са њом?
• Да ли је могуће спојити све делове података заједно пре него што их преместите на споре дискове?
• Како прећи на нове верзије ЦлицкХоусе-а ако не постоји начин да се унапред провери компатибилност?
• Килл куери би требало да убије упите, али не. Зашто?
• Како израчунати време одзива под оптерећењем читања?
• Шта могу да подесим у ЦлицкХоусе-у тако да више података буде у кешу?
• Како могу да конфигуришем стораге_цонфигуратион за складиштење у РАМ-у?
• До ког броја јединствених вредности је ниска кардиналност ефективна?
• Које су најбоље праксе за претраживање целог текста табеле са пет милијарди редова?
• Који је најбољи начин да организујете приступ ЦлицкХоусе-у за велики број корисника?
• Да ли је могуће дати резултате једног упита на десет клијената?
• Шта је са асинхроним операцијама и материјализованим погледима?
• ЦлицкХоусе има много дневника. Како могу да видим све што се тренутно дешава са сервером?
• Како утицати на спајања да се сервер не сруши у ООМ?
• Како ће се развити Голанг драјвер за ЦлицкХоусе?
• Спољни речник се не учитава након поновног покретања са омогућеном поставком лази_лоад. Шта да радим?
• Шта урадити са чињеницом да системски речник за поновно учитавање не учитава ниједан од многих речника ако се бар један од њих сруши са грешком?
• Постоји ли начин да се конфигуришу детаљи у ЦлицкХоусе конфигурацији, али да се не приказују у случају грешака?
• Бонус: позадине за Зоом са скупова

Ако не желите да читате текст, можете погледати снимак скупова на нашем ИоуТубе каналу. Временски кодови су у првом коментару испод видеа.

ЦлицкХоусе се стално ажурира, али наши подаци нису. Шта учинити поводом тога?

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

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

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

Које су тренутне најбоље праксе за прављење резервних копија података са ЦлицкХоусе-а?

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

Можемо направити сопствено решење и написати на басх-у: прикупити ове резервне копије на такав и такав начин. Можда нема потребе за штакама, а бицикл је давно измишљен?

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

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

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

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

1. Сачувај дефиницију табеле, тј. метаподатке − прикажи креирање табеле.
2. Направите думп користећи ЦлицкХоусе клијент - одабрати * са стола да поднесе. Подразумевано ћете добити датотеку у формату ТабСепаратед. Ако желите да будете ефикаснији, можете то учинити у изворном формату.

Ако је количина података већа, резервна копија ће трајати више времена и много простора. Ово се зове логичка резервна копија; није везана за формат података ЦлицкХоусе. Ако јесте, онда као последње средство можете направити резервну копију и отпремити је у МиСКЛ ради опоравка.

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

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

Враћање такве резервне копије је прилично лако. Прво, креирајте табеле користећи постојеће дефиниције табела. Затим копирајте сачуване снимке партиција у „Дирецтори-Детацхед“ за ове табеле и покрените упит причврстите партицију. Ово решење је сасвим погодно за најозбиљније количине података.

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

Прво морате да направите неколико сервера са великим дисковним полицама. Затим, на овим серверима, подигните неколико ЦлицкХоусе сервера и конфигуришите их тако да раде као друга реплика за исте делове. Затим користите систем датотека или неки алат на овим серверима који вам омогућава да креирате снимке. Овде постоје две опције. Прва опција су ЛВМ снимци, друга опција је ЗФС на Линук-у.

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

Да ли ће бити могуће организовати контролисано заостајање реплика у шахтовима?

Ове године планирате да направите окна у ЦлицкХоусе-у. Да ли ће у њима бити могуће организовати контролисано заостајање реплика? Желели бисмо да га искористимо да се заштитимо од негативних сценарија изменама и другим променама.

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

Ако је команда дошла у наш кластер и покварила га, онда имамо условну реплику са сат времена кашњења, где можемо рећи да је користимо у овом тренутку, али нећемо примењивати промене на њој последњих десет минута?

Прво, о контролисаном заостајању реплика. Постојао је такав захтев корисника, а ми смо направили издање на Гитхубу са захтевом: „Ако некоме треба ово, лајкујте га, ставите срце.“ Нико није доставио и питање је затворено. Међутим, ову прилику већ можете добити тако што ћете поставити ЦлицкХоусе. Истина, само почевши од верзије 20.3.

ЦлицкХоусе стално врши спајање података у позадини. Када се спајање заврши, одређени скуп података се замењује већим делом. У исто време, делови података који су били тамо и даље остају на диску неко време.

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

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

Сада се поставља питање како се то штити од промена. Овде вреди дубље погледати, јер је у старијим верзијама ЦлицкХоусе-а алтер функционисао на такав начин да је једноставно директно мењао делове. Постоји део података са неким датотекама, а ми радимо нпр. алтер дроп цолумн. Затим се ова колона физички уклања из свих делова.

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

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

Шта ако се структура табеле променила?

Како вратити резервну копију која је направљена са старом шемом? А друго питање се односи на случај са снимцима и алатима система датотека. Да ли је Бтрфс овде добар уместо ЗФС-а на Линук ЛВМ-у?

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

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

Које су тренутне најбоље праксе за поновно дељење података?

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

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

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

Пренос се може извршити само за оне партиције које се не мењају током снимања. За свеже партиције, снимање ће морати да буде онемогућено, јер њихов пренос није атомски. У супротном, на крају ћете имати дупликате или празнине у подацима. Међутим, овај метод је практичан и делује прилично ефикасно. Готове компресоване партиције се преносе преко мреже, односно подаци се не компримују или поново кодирају.

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

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

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

Дакле, ово је метод број један. И чекам ваш одговор, да ли је метода прикладна, или идемо даље.

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

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

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

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

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

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

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

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

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

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

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

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

Постоји главни кластер са догађајима Иандек.Метрица. Догађаји су прикази страница, кликови и конверзије. Већина захтева иде на одређену веб локацију. Отворите услугу Иандек.Метрица, имате веб локацију - авито.ру, идите на извештај и направљен је захтев за вашу веб локацију.

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

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

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

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

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

Како се све ово скалира? Број кластера се не мења – како је пре неколико година било тридесет девет, тако је и остало. Али у оквиру сваког од њих постепено повећавамо број фрагмената како акумулирамо податке. А шема шардирања у целини је оваква: ови кластери су подељени на веб локације, а да би се разумело која веб локација се налази на ком кластеру, користи се посебна метабаза у МиСКЛ-у. Један сајт - на једном кластеру. А унутар њега се дељење дешава према ИД-овима посетилаца.

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

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

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

А други кластер је за мале локације. Овде је шема за дељење заснована на ИД-у сајта, а сваки захтев иде на тачно један шард.

ЦлицкХоусе има услужни програм цлицкхоусе-цопиер. Можете ли нам рећи нешто о њој?

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

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

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

Како кликхоусе-копирна машина ради унутра? Разбија сав посао у скуп задатака за обраду једне партиције једне табеле на једном шарду. Сви ови задаци се могу извршавати паралелно, а цлицкхоусе-цопиер се може покренути на различитим машинама у више инстанци, али оно што ради за једну партицију није ништа друго до одабир уметања. Подаци се читају, декомпримују, поново партиционишу, затим поново компримују, негде записују и поново сортирају. Ово је тежа одлука.

Имали сте пилот ствар која се зове ресхардинг. Шта са њом?

Још 2017. године имали сте пилот ствар под називом поновно шардирање. Постоји чак и опција у ЦлицкХоусе-у. Колико сам разумео, није полетело. Можете ли ми рећи зашто се то догодило? Чини се да је веома релевантно.

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

Да ли је могуће спојити све делове података заједно пре него што их преместите на споре дискове?

Питање о ТТЛ-у са опцијом преласка на спори диск у контексту спајања. Постоји ли начин, осим преко црон-а, да спојите све делове у један пре него што их преместите на споре дискове?

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

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

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

Како прећи на нове верзије ЦлицкХоусе-а ако не постоји начин да се унапред провери компатибилност?

О овој теми се редовно расправља у ЦлицкХоусе телеграм ћаскању узимајући у обзир различите верзије, и даље. Колико је безбедно надоградити са верзије 19.11 на 19.16 и, на пример, са 19.16 на 20.3. Који је најбољи начин за прелазак на нове верзије без могућности да унапред проверите компатибилност у сандбок-у?

Овде постоји неколико „златних“ правила. Први - прочитајте дневник промена. Велик је, али постоје одвојени параграфи о назад некомпатибилним променама. Не третирајте ове тачке као црвену заставу. То су обично мање некомпатибилности које укључују неке ивице функционалности које врло вероватно не користите.

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

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

Постоји верзија 20.3.4. Број 20 означава годину производње - 2020. Са становишта онога што је унутра, ово није битно, тако да нећемо обраћати пажњу на то. Следеће - 20.3. Повећавамо други број - у овом случају 3 - сваки пут када објавимо издање са неком новом функционалношћу. Ако желимо да додамо неку функцију ЦлицкХоусе-у, морамо повећати овај број. То јест, у верзији 20.4 ЦлицкХоусе ће радити још боље. Трећа цифра је 20.3.4. Овде 4 је број издања закрпа у којима нисмо додали нове функције, али смо поправили неке грешке. А 4 значи да смо то урадили четири пута.

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

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

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

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

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

Максим Котјаков, виши бацкенд инжењер Авито: Додаћу нешто о тестним окружењима из низа проблема са којима се суочавају велике компаније. Имамо потпуни ЦлицкХоусе кластер прихватања; у смислу шема података и подешавања, то је тачна копија онога што је у производњи. Овај кластер је распоређен у прилично исцрпљеним контејнерима са минималним ресурсима. Тамо пишемо одређени проценат производних података, на срећу је могуће реплицирати стреам у Кафки. Тамо је све синхронизовано и скалирано – и по капацитету и по протоку, и, у теорији, под свим осталим једнаким стварима, требало би да се понаша као производња у смислу метрике. Све што је потенцијално експлозивно прво се котрља на овај штанд и оставља тамо неколико дана док се не припреми. Али наравно, ово решење је скупо, тешко и има трошкове подршке који нису нула.

Алексеј Миловидов: Рећи ћу вам какво је тестно окружење наших пријатеља из Иандек.Метрица. Један кластер је имао 600 и више сервера, други 360, а постоји трећи и неколико кластера. Тестно окружење за један од њих су једноставно два шарда са две реплике у свакој. Зашто две крхотине? Тако да нисте сами. А требало би да постоје и реплике. Само одређени минимални износ који можете приуштити.

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

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

Све је у реду. Почињемо да се крећемо у производњу. Добијам поруку да је оптерећење на графовима повећано неколико пута. Враћамо верзију. Погледам графикон и видим: оптерећење се заправо повећало неколико пута током увођења, а смањило се када су се појавили. Онда смо почели да враћамо верзију. И оптерећење се повећавало на исти начин и на исти начин падало назад. Дакле, закључак је следећи: оптерећење се повећало због распореда, ништа изненађујуће.

Тада је било тешко убедити колеге да инсталирају нову верзију. Кажем: „У реду је, извуците. Држите палчеве, све ће успети. Сада се оптерећење на графиконима повећало, али све је у реду. Држи се." Генерално, урадили смо ово, и то је то - верзија је пуштена за производњу. Али скоро са сваким распоредом се јављају слични проблеми.

Килл куери би требало да убије упите, али не. Зашто?

Дошао ми је корисник, нека врста аналитичара, и направио захтев који је ставио мој ЦлицкХоусе кластер. Неки чвор или цео кластер, у зависности од тога на коју реплику или део је захтев отишао. Видим да су сви ЦПУ ресурси на овом серверу на полици, све је црвено. Истовремено, сам ЦлицкХоусе одговара на захтеве. И пишем: „Молим вас, покажите ми, процесну листу, који захтев је изазвао ово лудило.

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

Сада ће бити прилично чудан одговор. Поента је да упит за убијање не убија упите.

Килл куери означава мали оквир под називом „Желим да овај упит буде убијен“. И сам захтев гледа ову заставицу приликом обраде сваког блока. Ако је подешен, захтев престаје да ради. Испоставља се да нико не убија захтев, он сам мора све да провери и престане. И ово би требало да функционише у свим случајевима када је захтев у стању обраде блокова података. Обрадиће следећи блок података, провериће заставицу и зауставити се.

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

Како израчунати време одзива под оптерећењем читања?

Постоји табела у којој се чувају агрегати ставки – разни бројачи. Број линија је око сто милиона. Да ли је могуће рачунати на предвидљиво време одговора ако сипате 1К РПС за 1К ставки?

Судећи по контексту, реч је о оптерећењу читања, јер нема проблема са писањем – може да се убаци и хиљаду, па и сто хиљада, а понекад и неколико милиона редова.

Захтеви за читање су веома различити. У избору 1, ЦлицкХоусе може да изврши око десетине хиљада захтева у секунди, тако да ће чак и захтеви за један кључ већ захтевати неке ресурсе. А такви тачки упити ће бити тежи него у неким базама података кључ-вредност, јер је за свако читање потребно прочитати блок података по индексу. Наш индекс се не односи на сваки запис, већ на сваки опсег. То јест, мораћете да прочитате цео опсег - ово је подразумевано 8192 реда. И мораћете да декомпресујете блок компримованих података са 64 КБ на 1 МБ. Обично је потребно неколико милисекунди да се заврше такви циљани упити. Али ово је најједноставнија опција.

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

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

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

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

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

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

Шта могу да подесим у ЦлицкХоусе-у тако да више података буде у кешу?

Хајде да замислимо ситуацију - сервери имају 256 ГБ РАМ-а, у дневној рутини ЦлицкХоусе заузима око 60-80 ГБ, на врхунцу - до 130. Шта се може омогућити и подесити тако да више података буде у кешу и, сходно томе, има мање путовања до диска?

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

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

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

Како могу да конфигуришем стораге_цонфигуратион за складиштење у РАМ-у?

У новој ЦлицкХоусе документацији прочитао сам одељак који се односи са складиштем података. Опис садржи пример са брзим ССД-ом.

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

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

Можете да конфигуришете складиштење података у РАМ-у. Све што је конфигурисано за диск је његова путања. Ви креирате тмпфс партицију која је монтирана на неку путању у систему датотека. Ову путању наведете као путању за складиштење података за најтоплију партицију, делови података почињу да стижу и тамо се уписују, све је у реду.

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

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

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

До ког броја јединствених вредности је ниска кардиналност ефективна?

Лов Цардиналити је паметно дизајниран. Саставља речнике података, али они су локални. Прво, постоје различити речници за сваки комад, а друго, чак и унутар једног дела могу бити различити за сваки опсег. Када број јединствених вредности достигне гранични број — милион, мислим — речник се једноставно одлаже и прави се нови.

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

Које су најбоље праксе за претраживање целог текста табеле са пет милијарди редова?

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

Зашто се то дешава? Они то објашњавају чињеницом да Еластицсеарцх престаје да се носи са оптерећењем на неким запреминама, почевши од изградње индекса. Индекси постају превише гломазни, а ако једноставно пренесете податке у ЦлицкХоусе, испоставиће се да се складиште неколико пута ефикасније у смислу обима. При томе, упити за претрагу често нису били такви да је у целом обиму података било потребно пронаћи неку фразу, узимајући у обзир морфологију, већ сасвим друге. На пример, пронађите неки низ бајтова у евиденцији у последњих неколико сати.

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

Али ипак, лике је потпуно скенирање. А потпуно скенирање може бити споро не само на ЦПУ-у, већ и на диску. Ако одједном имате један терабајт података дневно, а током дана тражите реч, онда ћете морати да скенирате терабајт. И вероватно је на редовним чврстим дисковима, и на крају ће бити учитани на такав начин да нећете моћи да приступите овом серверу преко ССХ-а.

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

Да бисте их правилно користили, требало би да добро разумете како тачно функционишу: шта је триграмски Блум филтер и како да изаберете његову величину. Могу да кажем да ће помоћи за упите о неким ретким фразама, подстринговима који се ретко налазе у подацима. У овом случају, подопсези ће бити изабрани индексима и мање података ће бити прочитано.

Недавно је ЦлицкХоусе додао још напредније функције за претрагу целог текста. Ово је, прво, претрага за гомилом подстрингова одједном у једном пролазу, укључујући опције које су осетљиве на велика и мала слова, са подршком за УТФ-8 или само за АСЦИИ. Изаберите најефикаснији који вам је потребан.

Појавила се и претрага више регуларних израза у једном пролазу. Не морате да пишете Кс као један подниз или Кс као други подниз. Пишете одмах, и све је урађено што је могуће ефикасније.

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

Који је најбољи начин да организујете приступ ЦлицкХоусе-у за велики број корисника?

Реците нам како најбоље организовати приступ за велики број потрошача и аналитичара. Како формирати ред, дати приоритет максималном броју истовремених упита и помоћу којих алата?

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

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

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

Рецимо да уклоним ограничење реда и поново покренем упит. Тада ћу видети следећи изузетак - подешавање омогућено индекс силе по датуму. Не могу да довршим упит ако нисам навео период. Не морате да се ослањате на аналитичаре да то наведу ручно. Типичан случај је када је написан период где је датум догађаја између недеље. А онда су једноставно навели заграду на погрешном месту, а уместо и испоставило се да је или - или УРЛ подударање. Ако нема ограничења, он ће пописати УРЛ колону и само потрошити гомилу ресурса.

Поред тога, ЦлицкХоусе има две поставке приоритета. Нажалост, они су веома примитивни. Једно се једноставно зове приоритет. Ако је приоритет = 0, а захтеви са неким приоритетом се извршавају, али се извршава захтев са вредношћу приоритета мањом од, што значи виши приоритет, онда захтев са вредношћу приоритета већи, што значи нижи приоритет , је једноставно суспендован и неће радити уопште током овог времена.

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

Позива се следећа поставка приоритета Приоритет нити за ОС. Једноставно поставља лепу вредност за све нити извршавања захтева за Линук планер. Ради тако-тако, али и даље ради. Ако поставите минималну лепу вредност – она је највећа по вредности, а самим тим и најнижи приоритет – и поставите -19 за захтеве са високим приоритетом, онда ће ЦПУ трошити захтеве ниског приоритета око четири пута мање од оних са високим приоритетом.

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

Замислите, поставили сте: ако неки упит обрађује мање од милион редова у секунди, не можете то да урадите. Ово срамоти наше добро име, нашу добру базу података. Само да забранимо ово. Заправо постоје два подешавања. Један се зове мин. брзина извршења - у редовима у секунди, а други се зове тимеоут пре провере мин. брзине извршавања - петнаест секунди подразумевано. То јест, петнаест секунди је могуће, а онда, ако је споро, онда само баците изузетак и поништите захтев.

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

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

Да ли је могуће дати резултате једног упита на десет клијената?

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

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

Желео бих да то некако избегнем, било кеширањем међуподатака, или поређањем сличних упита у неку врсту реда и додавањем кеша резултата. Тренутно имамо један захтев за повлачење у развоју који додаје кеш захтева, али само за подупите у одељцима за унос и придруживање – то јест, решење је непотпуно.

Међутим, и ми се суочавамо са таквом ситуацијом. Посебно канонски пример су пагинирани упити. Постоји извештај, има неколико страница, и постоји захтев за лимит 10. Онда исто, али лимит 10,10. Затим још једна следећа страница. И поставља се питање зашто сваки пут све ово рачунамо? Али сада нема решења, а ни начина да се избегне.

Постоји алтернативно решење које се поставља као приколица поред ЦлицкХоусе-а - ЦлицкХоусе Проки.

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

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

Шта је са асинхроним операцијама и материјализованим погледима?

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

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

Вреди разумети како функционише дедупликација. Оно што ћу вам сада рећи није релевантно за питање, али за сваки случај вреди запамтити.

Приликом уметања у реплицирану табелу, постоји дедупликација целих уметнутих блокова. Ако поново уметнете исти блок који садржи исти број истих редова у истом редоследу, тада се подаци укидају. Добићете „У реду“ као одговор на уметање, али ће у ствари бити уписан један пакет података и неће бити дуплиран.

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

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

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

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

Кирил Шваков: Такође смо имали конструкцију штака у то време. Постојао је проблем што постоје утисци оглашавања, а постоје и неки подаци које можемо приказати у реалном времену – то су само утисци. Ретко се дуплирају, али ако се то догоди, ионако ћемо их касније срушити. А било је ствари које се нису могле дуплирати – кликови и цела ова прича. Али такође сам желео да их покажем скоро одмах.

Како су направљени материјализовани погледи? Било је погледа где је написано директно - писано је на необрађене податке, а писано на погледе. Тамо у неком тренутку подаци нису баш тачни, дуплирани су и тако даље. А постоји и други део табеле, где они изгледају потпуно исто као материјализовани погледи, односно апсолутно су идентични по структури. С времена на време прерачунамо податке, пребројимо податке без дупликата, упишемо у те табеле.

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

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

ЦлицкХоусе има много дневника. Како могу једним погледом да видим све што се дешава са сервером?

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

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

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

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

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

Владимир Колобаев: Алексеј, хтео бих мало да исправим. Ту је Графана. Графана има извор података, а то је ЦлицкХоусе. То јест, могу да упутим захтеве од Графане директно ЦлицкХоусе-у. ЦлицкХоусе има табелу са логовима, иста је за све. Као резултат тога, желим да приступим овој табели евиденције у Графани и видим захтеве које мој сервер поставља. Било би сјајно имати овакву контролну таблу.

Сам сам возио бицикл. Али имам питање - ако је све стандардизовано, а Графану сви користе, зашто Иандек нема такву званичну контролну таблу?

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

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

Волео бих да постоји алатка која управо каже, ево ваших тешких упита, груписаних по класама упита. Притиснуо сам једну, а они би ми рекли да је зато тежак. Сада таквог решења нема. И заиста је прилично чудно да када ме људи питају: „Реците ми да ли постоје готове контролне табле за Графану?“, ја кажем: „Идите на веб страницу Графане, постоји заједница „Дасхбоардс“ и постоји контролна табла од Димке, ту је контролна табла од Костјана. Не знам шта је то, нисам га лично користио."

Како утицати на спајања да се сервер не сруши у ООМ?

Имам табелу, постоји само једна партиција у табели, то је РеплацингМергеТрее. Четири године уписујем податке у њега. Морао сам да изменим и избришем неке податке.

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

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

Имам табелу под називом „Метрике“, молим вас да је обрадите за мене у две нити. Нема потребе да креирате десет или пет спајања паралелно, урадите то у два. Мислим да имам довољно меморије за двоје, али можда неће бити довољно за обраду десет. Зашто страх остаје? Јер табела расте, и једног дана ћу се суочити са ситуацијом која, у принципу, више није због грешке, већ зато што ће се подаци променити у толикој количини да једноставно нећу имати довољно меморије на сервер. А онда ће се сервер срушити у ООМ приликом спајања. Штавише, могу да откажем мутацију, али Мерји више није ту.

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

Владимир Колобаев: У реду. Овде је тренутак такав да сам након отклањања грешке преузео нову верзију за себе, а на другом столу, мањем, где има много партиција, извршио сам сличну операцију. А током спајања, око 100 ГБ РАМ-а је спаљено на серверу. Имао сам 150 заузетих, 100 поједених и остао прозор од 50 ГБ, тако да нисам упао у ООМ.

Шта ме тренутно штити од пада у ООМ ако заправо троши 100 ГБ РАМ-а? Шта учинити ако изненада понестане РАМ меморије на стапањима?

Алексеј Миловидов: Постоји такав проблем да потрошња РАМ-а посебно за спајање није ограничена. А други проблем је у томе што ако је додељена нека врста спајања, онда она мора да се изврши јер је забележена у дневнику репликације. Дневник репликације је радња која је потребна да се реплика доведе у конзистентно стање. Ако не извршите ручне манипулације које ће вратити овај дневник репликације, спајање ће морати да се изврши на овај или онај начин.

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

Како ће се развити Голанг драјвер за ЦлицкХоусе?

Возач Голанг, који је написао Кирил Шваков, сада је званично подржан од стране ЦлицкХоусе тима. Он у ЦлицкХоусе спремишту, он је сада велики и стваран.

Мала напомена. Постоји дивно и вољено складиште нормалних облика бесконачног поретка - ово је Вертица. Они такође имају свој званични управљачки програм за питхон, који подржавају Вертица програмери. Неколико пута се догодило да су се верзије за складиштење и верзије драјвера прилично драматично разишле, а драјвер је у неком тренутку престао да ради. И друга тачка. Подршку овом званичном драјверу, чини ми се, спроводи систем „брадавица“ - напишете им проблем и он заувек виси.

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

Кирил Шваков: Први је како је све бирократски организовано. О овој тачки није било речи, тако да немам шта да одговорим.

Да бисмо одговорили на питање о проблему, потребно нам је мало историје возача. Радио сам за компанију која је имала много података. Био је то рекламни спиннер са огромним бројем догађаја које је требало негде похранити. И у неком тренутку се појавио ЦлицкХоусе. Попунили смо га подацима и у почетку је све било у реду, али онда се ЦлицкХоусе срушио. У том тренутку смо одлучили да нам то не треба.

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

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

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

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

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

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

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

Спољни речник се не учитава након поновног покретања са омогућеном поставком лази_лоад. Шта да радим?

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

Можда имамо стару верзију ЦлицкХоусе-а, па се речник није аутоматски учитао. Да ли би то могао бити случај?

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

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

Одговор на последње питање је или је верзија стара или је потребно отклонити грешке.

Шта урадити са чињеницом да системски речник за поновно учитавање не учитава ниједан од многих речника ако се бар један од њих сруши са грешком?

Постоји још једно питање о системским речницима за поновно учитавање. Имамо два речника – један није учитан, други је учитан. У овом случају речници за поновно учитавање система не учитавају ниједан речник и морате тачку по тачку учитати одређени по његовом имену користећи системски речник за поновно учитавање. Да ли је ово такође повезано са верзијом ЦлицкХоусе?

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

Постоји ли начин да се конфигуришу детаљи у ЦлицкХоусе конфигурацији, али да се не приказују у случају грешака?

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

Ову грешку смо решили додавањем детаља у конфигурацију ОДБЦ драјвера. Да ли постоји начин да се конфигуришу детаљи у конфигурацији ЦлицкХоусе, али да се ти детаљи не приказују у случају грешака?

Право решење овде је да наведете ове акредитиве у одбц.ини, ау самом ЦлицкХоусе наведете само ОДБЦ име извора података. Ово се неће десити за друге изворе речника - ни за речник са МиСКЛ, нити за остале, не би требало да видите лозинку када добијете поруку о грешци. За ОДБЦ, такође ћу погледати - ако постоји, само треба да га уклоните.

Бонус: позадине за Зоом са скупова

Кликом на слику отварају се бонус позадине са скупова за најупорније читаоце. Гасимо ватру заједно са маскотама Авито технологије, саветујемо се са колегама из собе администратора система или компјутерског клуба старе школе и свакодневно водимо састанке испод моста у позадини графита.

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