ClickHouse за напреднали потребители във въпроси и отговори

През април инженерите на Avito се събраха за онлайн срещи с Алексей Миловидов, главен разработчик на ClickHouse, и Кирил Шваков, разработчик на Golang от Integros. Обсъдихме как използваме системата за управление на бази данни и какви трудности срещаме.

Въз основа на срещата, ние съставихме статия с отговорите на експертите на нашите въпроси и на въпросите на публиката относно архивирането, повторното споделяне на данни, външните речници, драйвера Golang и актуализациите на версията на ClickHouse. Може да бъде полезно за разработчици, които вече активно работят с СУБД Yandex и се интересуват от нейното настояще и бъдеще. Отговорите на Алексей Миловидов по подразбиране, освен ако не е отбелязано друго.

Внимавайте, има много текст под изрязването. Надяваме се, че съдържанието с въпроси ще ви помогне да се ориентирате.

Съдържание

• ClickHouse се актуализира постоянно, но нашите данни не са. Какво да правя с него?
• Какви са настоящите най-добри практики за архивиране на данни от ClickHouse?
• Ще може ли да се организира контролирано натрупване на реплики в шахтите?
• Ами ако структурата на таблицата се е променила?
• Какви са настоящите най-добри практики за повторно споделяне на данни?
• ClickHouse има помощна програма за копирна машина clickhouse. Можете ли да разкажете за нея?
• Имахте пилотно нещо, наречено повторно споделяне. Какво с нея?
• Възможно ли е да обедините всички части на данните заедно, преди да преминете към бавни дискове?
• Как да мигрирам към нови версии на ClickHouse, ако няма начин да проверите съвместимостта предварително?
• Kill query трябва да убива заявки, но не го прави. Защо?
• Как да изчислим времето за реакция при натоварване при четене?
• Какво да промените в ClickHouse, така че повече данни да има в кеша?
• Как мога да конфигурирам storage_configuration за съхранение в RAM?
• До какъв брой уникални стойности ниската кардиналност е ефективна?
• Какви са най-добрите практики за пълнотекстово търсене в таблица с пет милиарда реда?
• Какъв е най-добрият начин за организиране на достъп до ClickHouse за голям брой потребители?
• Възможно ли е да се дадат резултати от една заявка на десет клиента?
• Какво ще кажете за асинхронните операции и материализираните изгледи?
• ClickHouse има много регистрационни файлове. Как мога да видя всичко, което се случва със сървъра в даден момент?
• Как да повлияем на мерджи, така че сървърът да не изпадне в OOM?
• Как ще се осъществи разработването на драйвера Golang за ClickHouse?
• Външният речник не се повдига след рестартиране с активиран lazy_load. Какво да правя?
• Какво ще кажете за факта, че речниците за презареждане на системата не зареждат нито един от многото речници, ако поне един от тях се срине с грешка?
• Има ли начин да конфигурирате подробностите в конфигурацията на ClickHouse, но да не ги светвате при грешки?
• Бонус: фонове за Zuma от събирания

Ако не искате да четете текста, можете да гледате записа на събиранията в нашия youtube канал. Часовете са в първия коментар под видеото.

ClickHouse се актуализира постоянно, но нашите данни не са. Какво да правя с него?

ClickHouse се обновява постоянно и нашите данни, които са обработени от optimize final, не се обновяват и са в резервно копие.

Да предположим, че имаме някакъв проблем и данните са загубени. Решихме да възстановим и се оказа, че старите дялове, които се съхраняват в резервните сървъри, са много различни от версията на ClickHouse, която се използва в момента. Какво да направите в такава ситуация и възможно ли е?

Ситуацията, в която сте възстановили данни от архив в стария формат, но в новата версия те не са свързани, е невъзможна. Уверяваме се, че форматът на данните в ClickHouse винаги остава обратно съвместим. Това е много по-важно от обратната съвместимост във функционалността, ако поведението на някои рядко използвани функции се е променило. Данните, които се съхраняват на диск, новата версия на ClickHouse трябва винаги да може да чете. Това е законът.

Какви са настоящите най-добри практики за архивиране на данни от ClickHouse?

Как да направим резервни копия, като имаме предвид, че имаме оптимизирани крайни операции, огромна база данни от терабайти и данни, които се актуализират, да речем, за последните три дни и след това не се случват процедури с тях?

Можем да съставим собствено решение и да напишем на главата: съберете тези резервни копия по такъв и такъв начин. Може би не е нужно да носите нищо, а велосипедът е изобретен отдавна?

Да започнем с най-добрите практики. Моите колеги винаги съветват в отговор на въпроси относно архивирането да им напомнят за услугата Yandex.Cloud, където тази задача вече е решена. Така че използвайте го, ако е възможно.

Няма цялостно решение, сто процента вградено в ClickHouse, за архивиране. Има някои заготовки, които можете да използвате. За да получите цялостно решение, ще трябва или да побъркате малко ръчно, или да направите обвивки под формата на скриптове.

Ще започна с най-простите решения и ще завърша с най-сложните, в зависимост от количеството данни и размера на клъстера. Колкото по-голям е клъстерът, толкова по-трудно става решението.

Ако таблицата с данни заема само няколко гигабайта, архивирането може да се направи по следния начин:

1. Запазете дефиницията на таблици, т.е. метаданни − покажи създаване на таблица.
2. Направете дъмп с помощта на клиента ClickHouse − изберете * от масата да подаде. По подразбиране ще получите файл във формат TabSeparated. Ако искате да сте по-ефективни, можете да използвате Native формата.

Ако обемът на данните е по-голям, тогава архивирането ще отнеме повече време и много място. Това се нарича логическо архивиране, то не е свързано с формата на данните на ClickHouse. Ако е така, тогава в краен случай можете да направите резервно копие и да го качите в MySQL за възстановяване.

За по-напреднали случаи, ClickHouse има вградена възможност за създаване на моментна снимка на дялове в локалната файлова система. Тази функция е достъпна като заявка. промяна на дяла за замразяване на таблицата. Или просто промяна на замразяването на масата е моментна снимка на цялата таблица.

Моментната снимка ще бъде създадена последователна за една таблица на един шард, т.е. невъзможно е да се създаде последователна моментна снимка на целия клъстер по този начин. Но за повечето задачи няма такава нужда и е достатъчно да изпълните заявка за всеки шард и да получите последователна моментна снимка. Създаден е под формата на твърди връзки и следователно не заема допълнително място. След това копирате тази моментна снимка на сървъра за архивиране или в хранилището, което използвате за архивиране.

Възстановяването на такъв архив е доста лесно. Първо създавате таблици според съществуващите дефиниции на таблици. След това копирайте запазените моментни снимки на дялове в Directory-Detached за тези таблици и изпълнете заявката прикрепете дял. Това решение е доста подходящо за най-сериозни количества данни.

Понякога имате нужда от нещо още по-готино - в случаите, когато имате десетки или дори стотици терабайти на всеки сървър и стотици сървъри. Тук има решение, което шпионирах от колеги от Yandex.Metrica. Не бих го препоръчал на всеки - прочетете го и преценете сами дали е подходящ или не.

Първо трябва да създадете няколко сървъра с големи дискови рафтове. След това издигнете няколко сървъра ClickHouse на тези сървъри и ги конфигурирайте така, че да работят като друга реплика за същите шардове. И след това използвайте файловата система на тези сървъри или някакъв инструмент, който ви позволява да създавате моментни снимки. Тук има два варианта. Първата опция е моментни снимки на LVM, втората опция е ZFS на Linux.

След това всеки ден трябва да създавате моментна снимка, тя ще лежи и ще заема малко място. Естествено, ако данните се променят, тогава с течение на времето количеството пространство ще се увеличи. Можете да получите тази моментна снимка по всяко време и да възстановите данните, толкова странно решение. Освен това все още трябва да ограничите тези реплики в конфигурацията, така че да не се опитват да станат лидери.

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

Тази година планирате да правите шахти в ClickHouse. Ще бъде ли възможно да се организира контролирано изоставане от реплики в тях? Бихме искали да го използваме, за да се предпазим от негативни сценарии с промени и други промени.

Възможно ли е да се направи някакъв вид връщане назад за промени? Например в съществуваща шахта вземете и кажете, че до този момент прилагайте промените и от този момент нататък спрете прилагането на промените?

Ако команда дойде в нашия клъстер и го счупи, тогава имаме условна реплика с един час закъснение, където можем да кажем, че нека я използваме в момента, но няма да приложим промените в нея за последните десет минути?

Като начало за контролираното изоставане от реплики. Имаше такова искане от потребители и ние създадохме проблем в Github с искане: „Ако някой има нужда от това, сложете харесване, сложете сърце.“ Никой не заложи и въпросът беше приключен. Въпреки това вече можете да получите тази възможност, като настроите ClickHouse. Вярно, само от версия 20.3.

ClickHouse постоянно обединява данни във фонов режим - обединяване. Когато се направи сливане, някои набори от части от данни се заменят с по-голяма част. В същото време части от данни, които са били преди, продължават да остават на диска за известно време.

Първо, те продължават да се съхраняват, докато има заявки за избор, които ги използват, за да се осигури неблокираща операция. Заявките за избор се четат тихо от стари парчета.

Второ, има и времеви праг - стари данни лежат на диска в продължение на осем минути. Тези осем минути могат да бъдат персонализирани и превърнати дори в един ден. Това ще струва дисково пространство: в зависимост от потока от данни ще се окаже, че през последния ден данните не само ще се удвоят, но могат да станат пет пъти повече. Но в случай на сериозен проблем можете да спрете сървъра на ClickHouse и да се справите с всичко.

Сега въпросът е как това предпазва от промени. Струва си да погледнете по-задълбочено тук, защото в по-старите версии на ClickHouse промяната работеше по такъв начин, че просто директно променяше частите. Има част от данните с някои файлове и ние правим, например, алтер капка колона. След това тази колона се премахва физически от всички парчета.

Но от версия 20.3 механизмът за промяна е напълно променен и сега частите от данни винаги са неизменни. Те изобщо не се променят - промените вече работят почти по същия начин като сливания. Вместо да променяме част на място, ние създаваме нова. В новата част файловете, които не са променени, стават твърди връзки и ако изтрием колона, тя просто ще липсва в новата част. Старото парче ще бъде изтрито по подразбиране след осем минути и тук можете да промените настройките, споменати по-горе.

Същото важи и за промени като мутации. Когато го направите промяна изтриване или промяна на актуализацията, не променя парчето, а създава ново. И след това изтрива стария.

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

Как да вдигна бекъп, който е направен със старата схема? И вторият въпрос е за случая с моментните снимки и инструментите на файловата система. Btrfs подходящ ли е тук вместо ZFS на Linux LVM?

Ако го направиш прикрепете дял дялове с различна структура, тогава ClickHouse ще ви каже, че това не е възможно. Решението е това. Първият е да създадете временна таблица от типа MergeTree със старата структура, да прикачите данни там с помощта на прикачване и да издадете заявка за промяна. След това можете да копирате или прехвърлите тези данни и да ги прикачите отново или да използвате заявката промяна на таблицата преместване на дял.

Сега вторият въпрос е дали е възможно да се използва Btrfs. Като за начало, ако имате LVM, тогава LVM снимките са достатъчни и файловата система може да бъде ext4, няма значение. С Btrts всичко зависи от вашия опит с него. Това е зряла файлова система, но все още има някои подозрения за това как всичко ще работи на практика в конкретен сценарий. Не бих препоръчал да използвате това, освен ако нямате Btrfs в производство.

Какви са настоящите най-добри практики за повторно споделяне на данни?

Въпросът за повторното споделяне е сложен и многостранен. Тук можете да отговорите на няколко опции наведнъж. Можете да влезете от едната страна и да кажете това - в ClickHouse няма вградена опция за повторно споделяне. Но се страхувам, че този отговор няма да угоди на никого. Следователно можете да отидете от другата страна и да кажете, че ClickHouse има много начини за повторно споделяне на данни.

Ако клъстерът няма място или не може да поеме натоварването, добавяте нови сървъри. Но тези сървъри са празни по подразбиране, няма данни за тях, няма натоварване. Трябва да преместите данните, така че да се разпределят равномерно в новия, по-голям клъстер.

Първият начин да направите това е да копирате част от дяловете на нови сървъри с помощта на заявката промяна на дяла за извличане на таблица. Например, имахте дялове по месеци и вземете първия месец от 2017 г. и го копирате на нов сървър, след което копирате третия месец на друг нов сървър. И така, докато стане горе-долу равномерно.

Миграцията може да се извърши само за онези дялове, които не се променят по време на запис. За нови дялове записът ще трябва да бъде деактивиран, защото прехвърлянето им не е атомарно. В противен случай ще получите дубликати или пропуски в данните. Този метод обаче е практичен и работи доста ефективно. Готовите компресирани дялове се предават по мрежата, т.е. данните не се компресират или прекодират.

Този метод има един недостатък и зависи от схемата за шардинг, дали сте се ангажирали с тази схема за шардинг, какъв ключ за шардинг сте имали. Във вашия пример за случая с показатели ключът за шардинг е хеш на пътя. Когато изберете разпределена таблица, тя отива към всички сегменти на клъстера наведнъж и взема данни от там.

Това означава, че за вас всъщност няма значение кои данни на кой шард ще попаднат. Основното е, че данните по един път завършват на един шард, но не е важно кой. В този случай прехвърлянето на готови дялове е идеално, защото при селектирани заявки ще получите и пълни данни - както преди resharding, така и след това, схемата няма особено значение.

Но има случаи, които са по-сложни. Ако на нивото на логиката на приложението разчитате на специална схема за шардинг, този клиент се намира на такъв и такъв шард и заявката може да бъде изпратена веднага там, а не към разпределената таблица. Или използвате сравнително нова версия на ClickHouse и сте активирали настройката оптимизирайте пропускане на неизползвани фрагменти. В този случай, по време на заявката за избор, изразът в секцията where ще бъде анализиран и ще бъде изчислено към кои шардове да се премине според схемата за шардинг. Това работи при условие, че данните са декомпозирани точно в съответствие с тази схема за шардинг. Ако сте ги преместили ръчно, кореспонденцията може да се промени.

Така че това е начин номер едно. И чакам отговора ти методът подходящ ли е или продължавам напред.

Владимир Колобаев, водещ системен администратор в Avito: Алексей, методът, който споменахте, не се вписва много добре, когато трябва да разпределите товара, включително четенето. Можем да вземем дял, който е месечен, и можем да пренесем предходния месец в друг възел, но когато дойде заявка за тези данни, ще заредим само тях. Но бих искал да заредя целия клъстер, защото в противен случай за известно време цялото натоварване при четене ще се обработва от два шарда.

Алексей Миловидов: Отговорът тук е странен - ​​да, лошо е, но може да работи. Ще обясня как точно. Струва си да разгледате сценария на натоварване, който идва с вашите данни. Ако това са данни от мониторинг, тогава е почти сигурно, че по-голямата част от заявките са за свежи данни.

Инсталирали сте нови сървъри, мигрирали сте стари дялове, но също сте променили начина, по който се записват свежи данни. И свежи данни ще бъдат разпространени в целия клъстер. По този начин, след пет минути, заявките за последните пет минути ще натоварят равномерно клъстера, след един ден, заявките за един ден ще натоварят равномерно клъстера. И заявките за предходния месец, за съжаление, ще отидат само до част от клъстерните сървъри.

Но често няма да имате заявки за февруари 2019 г. Най-вероятно, ако заявките стигнат до 2019 г., те ще бъдат за цялата 2019 г. - за голям интервал от време, а не за някакъв малък диапазон. И такива заявки също ще могат да натоварват равномерно клъстера. Но като цяло забележката ви е съвсем правилна, че това е ad hoc решение, което не разпространява данните напълно равномерно.

Имам още няколко точки, за да отговоря на въпроса. Един от тях е за това как първоначално да направите схемата за шардинг така, че да има по-малко болка от повторно шардинг. Това не винаги е възможно.

Например, имате данни за наблюдение. Данните от мониторинга нарастват поради три причини. Първият е натрупването на исторически данни. Второто е нарастването на трафика. И третото е увеличаване на броя на нещата, които подлежат на наблюдение. Има нови микроуслуги и показатели, които трябва да бъдат запазени.

Възможно е от тях най-голямото увеличение да се дължи на третата причина - това е увеличаване на използването на мониторинг. И в този случай си струва да разгледаме естеството на товара, какви са основните искания за избор. Основните заявки за избор е вероятно да следват някои подмножества от показателите.

Например, използването на процесора на някои сървъри от някаква услуга. Оказва се, че има някакво подмножество от ключове, чрез които получавате тези данни. А самата заявка за тези данни най-вероятно е доста проста и се изпълнява за десетки милисекунди. Използва се за услуги за наблюдение, за табла. Надявам се, че разбирам това правилно.

Владимир Колобаев: Факт е, че много често се обръщаме към исторически данни, тъй като сравняваме текущата позиция с историческата в реално време. И за нас е важно да имаме бърз достъп до голямо количество данни и ClickHouse се справя чудесно с това.

Вие сте напълно прав, повечето от заявките за четене, които получаваме през последния ден, като всяка система за наблюдение. Но в същото време натоварването върху исторически данни също е доста голямо. Това е предимно от система за предупреждение, която обикаля на всеки тридесет секунди и казва на ClickHouse: „Дайте ми данните за последните шест седмици. А сега ми изградете някаква подвижна средна от тях и нека сравним текущата стойност с историческата стойност.

Бих искал да кажа, че за такива много свежи заявки имаме друга малка таблица, в която съхраняваме само два дни данни и основните заявки летят в нея. Ние изпращаме само големи исторически заявки към голяма шардирана таблица.

Алексей Миловидов: За съжаление се оказва, че е слабо приложим за вашия сценарий, но ще опиша две лоши и сложни схеми за шардинг, които не е необходимо да се използват, но се използват в моята услуга за приятели.

Има основен клъстер със събития Yandex.Metrics. Събитията са показвания на страници, кликвания и преходи. Повечето заявки отиват към конкретен уебсайт. Отваряте услугата Yandex.Metrica, имате уебсайт - avito.ru, отивате на отчета и се прави заявка за вашия уебсайт.

Но има и други заявки – аналитични и глобални, които се правят от вътрешни анализатори. За всеки случай отбелязвам, че вътрешните анализатори правят заявки само за услуги на Yandex. Но въпреки това дори услугите на Yandex заемат значителен дял от всички данни. Това са заявки не за конкретни броячи, а за по-широко филтриране.

Как да организираме данните по такъв начин, че всичко да работи ефективно за един брояч, както и глобалните заявки? Друга трудност се крие във факта, че броят на заявките в ClickHouse за клъстера Metrics е няколко хиляди в секунда. В същото време един сървър на ClickHouse не обработва нетривиални заявки, например няколко хиляди в секунда.

Размерът на клъстера е шестстотин и нещо сървъра. Ако просто разтегнете разпределена таблица върху този клъстер и изпратите няколко хиляди заявки там, ще стане дори по-лошо, отколкото да ги изпратите на един сървър. От друга страна, опцията, че данните се разпределят равномерно и ние отиваме и изискваме от всички сървъри, веднага се отхвърля.

Има и диаметрално противоположен вариант. Представете си, ако разделяме данни по сайт и заявка за един сайт отива към един шард. Сега клъстерът ще може да изтегли десет хиляди заявки в секунда, но на един шард една заявка ще работи твърде бавно. Вече няма да мащабира честотната лента. Особено ако това е сайт avito.ru. Няма да разкрия тайна, ако кажа, че Avito е един от най-посещаваните сайтове в Runet. И да го обработваме на един шард би било лудост.

Следователно схемата за шардинг е подредена по по-сложен начин. Целият клъстер е разделен на няколко клъстера, които наричаме слоеве. Във всеки клъстер има от десет до няколко дузини парчета. Има общо тридесет и девет такива клъстера.

Как се мащабира всичко? Броят на клъстерите не се променя - както преди тридесет и девет години, той остава същият. Но в рамките на всеки от тях ние постепенно увеличаваме броя на фрагментите с натрупването на данни. А схемата за шардинг като цяло е следната - разделянето на тези клъстери минава по уебсайтове и за да се разбере кой сайт на кой клъстер е, обикновено се използва отделна метабаза в MySQL. Един сайт - на един клъстер. И вътре в него се извършва шардинг според идентификаторите на посетителите.

Когато записваме, ние ги разделяме на остатъка от ID на посетителя. Но когато се добави нов шард, схемата за шардинг се променя, ние продължаваме да разделяме, но с остатъка от делене на друго число. Това означава, че един посетител вече се намира на няколко сървъра и не можете да залагате на него. Това се прави единствено, за да се гарантира, че данните са по-добре компресирани. И когато правим заявки, отиваме в таблицата Distributed, която разглежда клъстера и има достъп до десетки сървъри. Това е толкова глупава схема.

Но моята история ще бъде непълна, ако не кажа, че сме изоставили тази схема. В новата схема променихме всичко и копирахме всички данни с помощта на clickhouse-copier.

В новата схема всички обекти са разделени на две категории – големи и малки. Не знам как е избран прагът там, но в резултат на това се оказа, че големи сайтове са записани на един клъстер, където има 120 шарда с три реплики във всяка - тоест 360 сървъра. И схемата за шардинг е такава, че всяка заявка отива към всички шардове наведнъж. Ако сега отворите която и да е страница с отчет за avito.ru в Yandex.Metrica, заявката ще отиде до 120 сървъра. В Runet има няколко големи сайта. И заявките не са хиляда в секунда, а дори по-малко от сто. Всичко това тихо се дъвче от таблицата Distributed, която всеки от тях обработва по 120 сървъра.

А вторият клъстер е за малки сайтове. Ето схема за шардинг по идентификатор на сайт и всяка заявка отива точно до един шард.

ClickHouse има помощна програма за копирна машина clickhouse. Можете ли да разкажете за нея?

Веднага трябва да кажа, че това решение е по-тромаво и малко по-малко продуктивно. Предимството е, че размазва данните изцяло според зададената от вас схема. Но недостатъкът на помощната програма е, че тя изобщо не решардира. Той копира данни от една клъстерна схема в друга клъстерна схема.

Това означава, че за да работи, трябва да имате два клъстера. Те могат да бъдат разположени на едни и същи сървъри, но въпреки това данните няма да се преместват постепенно, а ще се копират.

Например, имаше четири сървъра, сега са осем. Създавате нова Distributed таблица на всички сървъри, нови локални таблици и стартирате clickhouse-copier, като в нея посочвате схемата на работа, която трябва да чете от там, приема новата схема за шардинг и прехвърля данните там. И ще ви трябва един път и половина повече място на старите сървъри, отколкото имате сега, защото старите данни трябва да останат върху тях и половината от същите стари данни ще дойдат върху тях. Ако сте смятали предварително, че данните трябва да бъдат повторно разпределени и има място, тогава този метод е подходящ.

Как работи Clickhouse-copier вътре? Той разделя цялата работа на набор от задачи за обработка на един дял от една таблица на един шард. Всички тези задачи могат да се изпълняват паралелно и clickhouse-copier може да изпълнява множество копия на различни машини, но това, което прави за един дял, не е нищо повече от избор на вмъкване. Данните се четат, декомпресират, преразпределят, след това отново се компресират, записват се някъде, сортират се отново. Това е по-трудно решение.

Имахте пилотно нещо, наречено повторно споделяне. Какво с нея?

През 2017 г. имахте пилотно нещо, наречено повторно споделяне. Дори има опция в ClickHouse. Разбирам, че не е излетяло. Можете ли да кажете защо се случи? Изглежда, че е много уместно.

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

Възможно ли е да обедините всички части на данните заедно, преди да преминете към бавни дискове?

Въпрос относно TTL с опцията за преминаване към бавен диск в контекста на сливания. Има ли начин освен cron да обедините всички части в едно, преди да преминете към бавни дискове?

Отговорът на въпроса дали е възможно по някакъв начин автоматично да се слепят всички части в едно, преди да се прехвърлят, е не. Струва ми се, че това не е необходимо. Не можете да обедините всички части в едно, а просто разчитате на факта, че те автоматично ще бъдат прехвърлени на бавни дискове.

Имаме два критерия за правилата за трансфер. Първият е като се напълни. Ако текущото ниво на съхранение има по-малко от определен процент свободно пространство, ние избираме един блок и го преместваме в по-бавно хранилище. Или по-скоро не по-бавно, а следното - как го настройвате.

Вторият критерий е размерът. Той говори за прехвърляне на големи парчета. Можете да коригирате прага въз основа на свободното място на бърз диск и данните ще бъдат мигрирани автоматично.

Как да мигрирам към нови версии на ClickHouse, ако няма начин да проверите съвместимостта предварително?

Тази тема се обсъжда редовно в чата на Telegram ClickHouse като се вземат предвид различни версии и все пак. Колко безопасно е надграждането от версия 19.11 на 19.16 и например от 19.16 на 20.3. Кой е най-добрият начин да преминете към нови версии, без да можете предварително да проверите съвместимостта в пясъчника?

Тук има няколко златни правила. първо - прочетете регистъра на промените. Голям е, но има отделни точки за обратно несъвместими промени. Не третирайте тези елементи като червен флаг. Това обикновено са незначителни несъвместимости, които са свързани с някаква крайна функционалност, която вероятно не използвате.

Второ, ако няма начин да проверите съвместимостта в пясъчната среда и искате да надстроите незабавно в производството, препоръката е да не правите това. Първо създайте пясъчник и тествайте. Ако няма тестова среда, тогава най-вероятно нямате много голяма компания, което означава, че можете да копирате част от данните на вашия лаптоп и да се уверите, че всичко работи правилно на него. Можете дори да изведете няколко реплики локално на вашата машина. Или можете да създадете нова версия някъде наблизо и да качите някои данни там - тоест да направите импровизирана тестова среда.

Друго правило е да не се актуализира в рамките на една седмица след пускането на версията поради улавяне на грешки в производството и последващи бързи корекции. Нека разберем номерирането на версиите на ClickHouse, за да не се объркаме.

Има версия 20.3.4. Числото 20 показва годината на производство - 2020. От гледна точка на това какво има вътре, това няма значение, така че няма да му обръщаме внимание. По-нататък - 20.3. Второто число - в този случай 3 - увеличаваме всеки път, когато пуснем издание с някаква нова функционалност. Ако искаме да добавим някаква функция към ClickHouse, трябва да увеличим този брой. Тоест във версия 20.4 ClickHouse ще работи още по-добре. Третата цифра е 20.3.4. Тук 4 е броят на изданията на корекции, в които не добавихме нови функции, но поправихме някои грешки. А 4 означава, че сме го направили четири пъти.

Не си мислете, че е нещо ужасно. Обикновено потребителят може да инсталира най-новата версия и тя ще работи без никакви проблеми с продължителност на работа на година. Но представете си, че в някаква функция за обработка на растерни изображения, която беше добавена от нашите китайски другари, при предаване на неправилни аргументи сървърът се срива. Трябва да поправим това. Ще пуснем нова версия на корекцията и ClickHouse ще стане по-стабилен.

Ако имате ClickHouse, работещ в производство, и е пусната нова версия на ClickHouse с допълнителни функции - например 20.4.1 е първата, не бързайте да го пуснете в производство на първия ден. Защо изобщо е необходима? Ако все още не използвате ClickHouse, можете да го инсталирате и най-вероятно всичко ще бъде наред. Но ако ClickHouse вече работи стабилно, тогава следете за корекции и актуализации - какви проблеми коригираме.

Кирил Шваков: Искам да добавя малко относно тестовите среди. Всички се страхуват много от тестови среди и по някаква причина вярват, че ако имате много голям клъстер ClickHouse, тогава тестовата среда не трябва да бъде по-малка или поне десет пъти по-малка. Изобщо не е така.

Мога да кажа с моя пример. Имам проект и има ClickHouse. Нашата тестова среда за него е малка виртуална машина в Hetzner за двадесет евро, където е разположено абсолютно всичко. За да направим това, имаме пълна автоматизация в Ansible и следователно по принцип няма разлика къде да се търкаля - на железни сървъри или просто да се разположи във виртуални машини.

Какво може да се направи? Би било хубаво да направите пример в документацията на ClickHouse за това как да разположите малък клъстер самостоятелно - в Docker, в LXC, може би създайте Ansible playbook, защото различните хора имат различни внедрявания. Това ще улесни много неща. Когато вземете и разположите клъстер за пет минути, е много по-лесно да се опитате да разберете нещо. По този начин е много по-удобно, защото пускането на версия, която не сте тествали, е път към никъде. Понякога работи, а понякога не. И така да се надяваме на успех е лошо.

Максим Котяков, старши бекенд инженер Avito: Ще добавя малко за тестови среди от поредица от проблеми за големи компании. Имаме пълноценен клъстер за приемане на ClickHouse, според схеми на данни и настройки, точно копие на това, което се произвежда. Този клъстер е разположен в доста гнили контейнери с минимум ресурси. Ние записваме там определен процент от производствените данни, тъй като има възможност за копиране на потока в Kafka. Там всичко е синхронизирано и мащабирано - и като капацитет, и като поток, и на теория, при равни други условия, трябва да се държи като производство като показатели. Всичко, което е потенциално експлозивно, първо се търкаля върху тази стойка и се влива там няколко дни, докато бъде готово. Но разбира се, това решение е скъпо, тежко и с ненулеви разходи за поддръжка.

Алексей Миловидов: Ще ви кажа каква е тестовата среда на нашите приятели от Yandex.Metrica. Един клъстер беше за 600 и нещо сървъра, друг за 360, а има трети и няколко клъстера. Тестовата среда за един от тях е само два шарда с две реплики във всеки. Защо две парчета? За да не съм сам. И реплики също да бъдат. Просто някаква минимална сума, която можете да си позволите.

Тази тестова среда ви позволява да проверявате изправността на заявките и дали нещо е счупено в голяма степен. Но често възникват проблеми от съвсем различно естество, когато всичко работи, но има някои малки промени с натоварването.

Ще ви дам пример. Решихме да инсталираме нова версия на ClickHouse. Той е изложен в тестова среда, автоматизираните тестове се предават в самата Yandex.Metrica, които сравняват данните на старата версия и на новата, изпълнявайки целия конвейер. И разбира се, екологични тестове на нашия CI. В противен случай дори нямаше да предложим тази версия.

Всичко е наред. Започваме да пускаме в производство. Получавам съобщение, че натоварването се е увеличило няколко пъти на графиките. Ние връщаме версията назад. Поглеждам графиката и виждам: натоварването наистина се е увеличило няколко пъти по време на разгръщането и е намаляло обратно при разгръщането. След това започнахме да връщаме версията назад. И товарът се увеличи по същия начин и падна обратно по същия начин. Така че заключението е следното - натоварването се е увеличило във връзка с изчислението, нищо изненадващо.

Тогава беше трудно да убедя колегите да инсталират все пак новата версия. Казвам: „Всичко е наред, разточвай се. Стискайте палци всичко ще се получи. Сега натоварването на класациите се увеличи, но всичко е наред. Дръж се." Като цяло направихме това и това е - версията е публикувана на производствения сайт. Но почти при всяко изчисление възникват подобни проблеми.

Kill query трябва да убива заявки, но не го прави. Защо?

При мен дойде потребител, някакъв вид анализатор, и създаде определена заявка, която постави моя ClickHouse клъстер. Някакъв възел или цял клъстер, в зависимост от това в коя реплика или фрагмент е попаднала заявката. Виждам, че всички процесорни ресурси на този сървър са в рафта, всичко е червено. В същото време самият ClickHouse отговаря на заявките. И пиша: "Моля, покажете ми списъка с процеси, коя заявка генерира тази лудост."

Намирам тази заявка и пиша kill към нея. И виждам, че нищо не се случва. Сървърът ми е в рафта, след това ClickHouse ми дава някои команди, показва, че сървърът е активен и всичко е наред. Но имам влошаване на всички потребителски заявки, влошаване чрез влизане в ClickHouse започва и моята заявка за унищожаване не работи. Защо? Мислех, че kill query трябва да убива заявки, но не е така.

Сега ще има доста странен отговор. Въпросът е, че kill query не убива заявки.

Kill query поставя малка отметка, наречена „Искам тази заявка да бъде унищожена“. И самата заявка, когато обработва всеки блок, гледа този флаг. Ако е зададено, заявката спира да работи. Оказва се, че никой не убива заявката, той сам трябва да провери всичко и да спре. И това трябва да работи във всички случаи, когато заявката е в състояние на блокова обработка. Той ще обработи следващия блок от данни, ще провери флага и ще спре.

Това не работи в случаите, когато заявката е блокирана при някаква операция. Вярно, това най-вероятно не е вашият случай, защото според вас използва куп сървърни ресурси. Възможно е това да не работи в случай на външно сортиране и в някои други подробности. Но като цяло това не трябва да бъде, това е грешка. И единственото, което мога да посъветвам, е да актуализирате ClickHouse.

Как да изчислим времето за реакция при натоварване при четене?

Има таблица, която съхранява агрегати на артикули - различни броячи. Броят на линиите е около сто милиона. Възможно ли е да разчитате на предвидимо време за реакция, ако налеете 1K RPS на 1K артикула?

Съдейки по контекста, говорим за натоварване при четене, защото няма проблеми с писането - могат да се вмъкнат поне хиляда, поне сто хиляди, а понякога и няколко милиона реда.

Заявките за четене са много различни. При избор 1 ClickHouse може да изпълнява около десетки хиляди заявки в секунда, така че дори заявките за един ключ вече ще изискват известни ресурси. И такива заявки за точки ще бъдат по-трудни, отколкото в някои бази данни ключ-стойност, защото за всяко четене е необходимо да се чете блокът от данни по индекс. Нашият индекс не адресира всеки запис, а всеки диапазон. Тоест, трябва да прочетете целия диапазон - това са 8192 реда по подразбиране. И трябва да декомпресирате компресирания блок данни от 64 KB на 1 MB. Обикновено такива заявки за точки отнемат от няколко милисекунди. Но това е най-лесният вариант.

Нека опитаме една проста аритметика. Ако умножите няколко милисекунди по хиляда, ще получите няколко секунди. Сякаш е невъзможно да поддържаме хиляда заявки в секунда, но всъщност е възможно, защото имаме няколко процесорни ядра. Така че по принцип 1000 RPS ClickHouse понякога може да задържи, но при кратки заявки, а именно заявки за точки.

Ако трябва да мащабирате клъстера ClickHouse по броя на простите заявки, тогава препоръчвам най-простото нещо - увеличете броя на репликите и изпращайте заявки към произволна реплика. Ако една реплика побира петстотин заявки в секунда, което е напълно реалистично, то три реплики ще поемат хиляда и половина.

Понякога, разбира се, можете също да конфигурирате ClickHouse за максимален брой отчитания на точки. Какво е необходимо за това? Първият е да се намали детайлността на индекса. В същото време не трябва да се свежда до един, а на базата на това, че броят на записите в индекса ще бъде няколко милиона или десетки милиони на сървър. Ако таблицата има сто милиона реда, тогава 64 могат да бъдат зададени като детайлност.

Можете да намалите размера на компресирания блок. Има настройки за това. мин. компресиран размер на блока, максимален размер на компресиран блок. Можете да ги намалите, да презаредите данните и тогава заявките за точки ще бъдат по-бързи. Но все пак ClickHouse не е база данни ключ-стойност. Голям брой малки заявки е анти-модел за натоварване.

Кирил Шваков: Ще дам съвет, ако има обикновени счетоводители. Това е доста стандартна ситуация, когато в ClickHouse се съхранява някакъв брояч. Имам потребител, той е от тази и тази държава, някаква друга трета област и трябва да увелича нещо постепенно. Вземете MySQL, направете уникален ключ - в MySQL това е дублиран ключ, а в PostgreSQL е конфликт - и добавете знак плюс. Това ще работи много по-добре.

Когато имате малко данни, няма много смисъл да използвате ClickHouse. Има редовни бази данни и те вършат добра работа.

Какво да промените в ClickHouse, така че повече данни да има в кеша?

Нека си представим ситуацията - сървърите имат 256 GB RAM, в ежедневието ClickHouse отнема около 60-80 GB, в пика - до 130. Какво може да се активира и настрои, така че повече данни да има в кеша и съответно , има по-малко пътувания до диска?

Като правило, кешът на страниците на операционната система се справя добре с тази задача. Ако просто отворите горната част, погледнете там кеширана или свободна - там също се казва колко е кеширана - тогава можете да видите, че цялата свободна памет се използва за кеша. И при четенето на тези данни те няма да се четат от диска, а от RAM паметта. В същото време мога да кажа, че кешът се използва ефективно, защото се кешират компресираните данни.

Въпреки това, ако искате да ускорите още повече някои прости заявки, е възможно да активирате кеш в декомпресираните данни в ClickHouse. Нарича се некомпресиран кеш. В конфигурационния файл config.xml задайте размера на некомпресирания кеш на стойността, от която се нуждаете - препоръчвам не повече от половината от свободната RAM, защото останалото ще отиде под кеша на страницата.

Освен това има две настройки за ниво на заявка. Първа настройка - използвайте некомпресиран кеш - включва използването му. Препоръчително е да го активирате за всички заявки, с изключение на тежките, които могат да прочетат всички данни и да изчистят този кеш. И втората настройка е нещо като максимален брой редове за използване на кеша. Той автоматично ограничава големите заявки, така че да са извън кеша.

Как мога да конфигурирам storage_configuration за съхранение в RAM?

В новата документация на ClickHouse прочетох свързания раздел със съхранение на данни. В описанието има пример с бързо SSD.

Чудя се как можете да конфигурирате същото с обемна гореща памет. И още един въпрос. Как select работи с тази организация на данните, дали ще прочете целия набор или само този на диска и тези данни компресирани ли са в паметта? И как работи секцията prewhere при такава организация на данните?

Тази настройка засяга съхранението на части от данни и техният формат не се променя по никакъв начин.
Нека да разгледаме по-отблизо.

Можете да настроите съхранение на данни в RAM. Всичко, което е конфигурирано за диск, е неговият път. Вие създавате tmpfs дял, който е монтиран към някакъв път във файловата система. Посочете този път като път за съхранение на данни за най-горещия дял, части от данни започват да пристигат и да се записват там, всичко е наред.

Но не препоръчвам да правите това поради ниска надеждност, въпреки че ако имате поне три реплики в различни центрове за данни, тогава можете. Ако е така, данните ще бъдат възстановени. Представете си, че сървърът внезапно е бил изключен и включен отново. Секцията е монтирана отново, но има кухина. При стартиране сървърът на ClickHouse вижда, че тези части липсват, въпреки че според метаданните на ZooKeeper би трябвало да липсват. Гледа на кои реплики са, иска ги и ги сваля. Така данните ще бъдат възстановени.

В този смисъл съхраняването на данни в RAM не се различава фундаментално от съхраняването им на диск, тъй като когато данните се записват на диск, те също първо попадат в кеша на страницата и се записват физически по-късно. Зависи как е монтирана файловата система. Но за всеки случай ще кажа, че ClickHouse не fsync при вмъкване.

В този случай данните в RAM се съхраняват в абсолютно същия формат, както на диска. Заявката за избор избира частите, които да бъдат прочетени по същия начин, избира необходимите диапазони от данни в частите и ги чете. И prewhere работи точно по същия начин, независимо дали данните са били в RAM или на диск.

До какъв брой уникални стойности ниската кардиналност е ефективна?

Ниската кардиналност е трудна. Компилира речници на данни, но те са локални. Първо, речниците са различни за всяко парче, и второ, дори в рамките на едно парче те могат да бъдат различни за всеки диапазон. Когато броят на уникалните стойности достигне праг - един милион, мисля - речникът просто се оставя настрана и се създава нов.

Отговорът е най-общо: за всеки локален диапазон - да речем, за всеки ден - някъде до милион уникални стойности, ниската кардиналност е ефективна. След това ще има само резервен вариант, в който ще се използват много различни речници, а не само един. Ще работи почти по същия начин като обикновена колона от типа низ, може би малко по-малко ефективно, но няма да има сериозно влошаване на производителността.

Какви са най-добрите практики за пълнотекстово търсене в таблица с пет милиарда реда?

Има различни отговори. Първият е да се каже, че ClickHouse не е пълнотекстова търсачка. За това има специални системи, напр. Elasticsearch и Сфинкс. Виждам обаче все повече хора, които казват, че преминават от Elasticsearch към ClickHouse.

Защо се случва това? Те обясняват това с факта, че Elasticsearch престава да се справя с натоварването на някои томове, като се започне от изграждането на индекси. Индексите стават твърде тромави и ако просто прехвърлите данните в ClickHouse, се оказва, че те се съхраняват няколко пъти по-ефективно като обем. В същото време заявките за търсене често не бяха такива, че е необходимо да се намери някаква фраза в цялото количество данни, като се вземе предвид морфологията, а съвсем различни. Например, за да намерите последните няколко часа в регистрационните файлове за някаква подпоследователност от байтове.

В този случай вие създавате индекс в ClickHouse, първото поле в което ще бъде дата с час. И най-голямото прекъсване на данните ще бъде точно за периода от време. В рамките на избрания период от време, като правило, вече е възможно да се извърши пълнотекстово търсене дори чрез метода на груба сила, като се използва like. Изявлението за харесване в ClickHouse е най-ефективното изявление за харесване, което можете да намерите. Ако намериш по-добър, кажи.

Но все пак подобно е пълно сканиране. И пълното сканиране може да бъде бавно не само на процесора, но и на диска. Ако изведнъж имате един терабайт данни на ден и търсите дума за един ден, ще трябва да сканирате терабайт. И вероятно е на обикновени твърди дискове и в резултат на това те ще бъдат заредени така, че няма да влезете в този сървър през SSH.

В този случай съм готов да предложа още един малък трик. Той е от категорията на експерименталните - може да работи, може и да не работи. ClickHouse има пълнотекстови индекси под формата на триграмни филтри за разцвет. Нашите колеги от Arenadata вече са изпробвали тези индекси и често те работят точно по предназначение.

За да ги използвате правилно, трябва добре да разберете как точно работят: какво представлява триграмният блум филтър и как да изберете неговия размер. Мога да кажа, че те ще помогнат за заявки за някои редки фрази, поднизове, които рядко се срещат в данните. В този случай поддиапазоните ще бъдат избрани чрез индекси и ще бъдат прочетени по-малко данни.

ClickHouse наскоро добави още по-разширени функции за търсене в пълен текст. Това е, първо, търсенето на куп поднизове наведнъж с едно преминаване, включително опции, чувствителни към малки и главни букви, нечувствителни към главни и малки букви, поддържащи UTF-8 или само ASCII опции. Изберете най-ефективния, от който се нуждаете.

Имаше и търсене на няколко регулярни израза с едно преминаване. Не е необходимо да пишете X като един подниз или X като друг подниз. Пишете веднага и всичко се прави възможно най-ефективно.

Трето, вече има приблизително търсене на регулярни изрази и приблизително търсене на поднизове. Ако някой е написал дума с правописна грешка, тя ще бъде търсена за максимално съвпадение.

Какъв е най-добрият начин за организиране на достъп до ClickHouse за голям брой потребители?

Кажете ни как най-добре да организираме достъпа за голям брой потребители и анализатори. Как да формирате опашка, да дадете приоритет на максималните едновременни заявки и с какви инструменти?

Ако клъстерът е достатъчно голям, тогава добро решение би било да се издигнат още два сървъра, които ще станат входна точка за анализаторите. Тоест, не допускайте анализатори до конкретни клъстерни фрагменти, а просто създайте два празни сървъра, без данни, и вече задайте права за достъп върху тях. В същото време потребителските настройки се прехвърлят към отдалечени сървъри по време на разпределени заявки. Тоест вие конфигурирате всичко на тези два сървъра и настройките имат ефект върху целия клъстер.

По принцип тези сървъри са без данни, но количеството RAM на тях е много важно за изпълнение на заявки. Дискът може да се използва и за временни данни, ако е активирано външно агрегиране или външно сортиране.

Важно е да разгледате настройките, които са свързани с всички възможни ограничения. Ако сега отида в клъстера Yandex.Metrics като анализатор и задам заявка изберете брой от хитове, тогава веднага ще ми бъде дадено изключение, че не мога да изпълня заявката. Максималният брой редове, които ми е позволено да сканирам, е сто милиарда, а в клъстера в една таблица има общо петдесет трилиона. Това е първото ограничение.

Да кажем, че премахна ограничението за броя на редовете и стартирам заявката отново. Тогава ще видя следното изключение - настройката е активирана индекс на силата по дата. Не мога да изпълня заявката, ако не съм посочил период от време. Не е нужно да разчитате на анализатори, за да го въведете ръчно. Типичен случай - период от време е написан, където датата на събитието е между седмица. И тогава те просто не посочиха скоба там и вместо и се оказа или - или URL съвпадение. Ако няма ограничение, ще започне да обхожда колоната с URL адреси и ще загуби много ресурси.

Освен това ClickHouse има две настройки за приоритет. За съжаление те са много примитивни. Едното се нарича просто приоритет. Ако приоритетът е ≠ 0 и се изпълняват заявки с известен приоритет, но се изпълнява заявка с по-ниска приоритетна стойност, което означава по-висок приоритет, тогава заявка с приоритетна стойност, по-голяма от, което означава по-нисък приоритет, е просто е спряно и изобщо няма да работи през това време.

Това е много груба настройка и не е подходяща за ситуации, при които има постоянно натоварване на клъстера. Но ако имате кратки, импулсни заявки, които са важни, и клъстерът е предимно неактивен, тази настройка ще свърши работа.

Извиква се следващата настройка за приоритет Приоритет на нишката на ОС. Той просто излага всички нишки за изпълнение на заявки на хубавата стойност за планировчика на Linux. Работи така, така, но все пак работи. Ако зададете минималната хубава стойност - това е най-голямата стойност и следователно най-ниският приоритет - и зададете -19 за заявки с висок приоритет, тогава процесорът ще консумира заявки с нисък приоритет около четири пъти по-малко от тези с висок приоритет.

Трябва също така да зададете максималното време за изпълнение на заявката - да речем, пет минути. Минималната скорост на изпълнение на заявката е най-якото нещо. Тази настройка съществува от дълго време и е необходима не само за да се гарантира, че ClickHouse не забавя, но и за да го принуди.

Представете си, че настройвате: ако една заявка обработва по-малко от един милион реда в секунда, не можете да направите това. Това позори доброто ни име, добрата ни база данни. Нека просто го забраним. Всъщност има две настройки. Единият се нарича мин. скорост на изпълнение - в редове за секунда, като секундата се нарича таймаут преди проверка на минималната скорост на изпълнение - петнадесет секунди по подразбиране. Тоест, петнадесет секунди са възможни и след това, ако бавно, тогава просто хвърлете изключение - прекратете заявката.

Трябва също да зададете квоти. ClickHouse има вградена функция за квоти, която отчита потреблението на ресурси. Но, за съжаление, не железни ресурси като процесор, дискове, а логически - броят на обработените заявки, прочетените редове и байтове. И можете да настроите, например, максимум сто заявки в рамките на пет минути и хиляда заявки на час.

Защо е важно? Тъй като някои от заявките за анализ ще бъдат изпълнени ръчно директно от клиента на ClickHouse. И всичко ще бъде наред. Но ако имате напреднали анализатори във вашата компания, те ще напишат скрипт и може да има грешка в скрипта. И тази грешка ще доведе до изпълнение на заявката в безкраен цикъл. Това е, което трябва да бъде защитено.

Възможно ли е да се дадат резултати от една заявка на десет клиента?

Имаме няколко потребители, които обичат да идват с много големи заявки едновременно. Заявката е голяма, по принцип се изпълнява бързо, но поради факта, че има много такива заявки едновременно, става много болезнено. Възможно ли е една и съща заявка, пристигнала десет пъти подред, да се изпълни веднъж и да се даде резултат на десет клиента?

Проблемът е, че нямаме кеширани резултати или междинен кеш на данни. Има кеш на страниците на операционната система, който ще ви позволи да не четете отново данни от диска, но, за съжаление, данните все пак ще бъдат декомпресирани, десериализирани и преработени.

Бих искал по някакъв начин да избегна това, или чрез кеширане на междинни данни, или чрез подреждане на подобни заявки в някакъв вид опашка и добавяне на кеш с резултати. Сега имаме една заявка за изтегляне в разработка, която добавя кеш на заявки, но само за подзаявки в секциите in и join - тоест решението е по-лошо.

Имаме обаче и такава ситуация. Особено каноничен пример са заявките с пагинация. Има отчет, има няколко страници и има заявка с лимит 10. След това същото, но с лимит 10,10. След това още една страница. И въпросът е защо го броим всеки път? Но сега няма решение и няма начин да го избегнете.

Има алтернативно решение, което е поставено като странична количка до ClickHouse - ClickHouse прокси.

Кирил Шваков: ClickHouse Proxy има вграден ограничител на скоростта и вграден кеш на резултатите. Там са направени доста настройки, защото е решена подобна задача. Проксито ви позволява да ограничите заявките, като ги поставите на опашка, и да конфигурирате колко дълго да живее кеша на заявките. Ако заявките наистина са еднакви, проксито ще ги даде много пъти и ще отиде в ClickHouse само веднъж.

Nginx също има кеш в безплатната версия и това също ще работи. Nginx дори има настройки, така че ако заявките постъпят по едно и също време, той ще спре други, докато една не завърши. Но в ClickHouse Proxy настройките са направени много по-добре. Направен е специално за ClickHouse, специално за тези заявки, така че е по-подходящ. Е, лесно е да се настрои.

Какво ще кажете за асинхронните операции и материализираните изгледи?

Има такъв проблем, че операциите с подменящия двигател са асинхронни - данните първо се записват, след това се свиват. Ако материализирана таблетка с някои агрегати живее под таблетката, тогава в нея ще бъдат записани дубликати. И ако няма сложна логика, тогава данните ще бъдат дублирани. Какво може да се направи по въпроса?

Има очевидно решение - да се приложи тригер на конкретен клас matview по време на асинхронна операция за свиване. Има ли планове за "сребърни куршуми" за внедряване на такава функционалност?

Струва си да разберете как работи дедупликацията. Това, което ще кажа, не е свързано с въпроса, но си струва да го запомните за всеки случай.

При вмъкване в репликирана таблица има дедупликация на целите вмъкнати блокове. Ако вмъкнете отново същия блок, съдържащ същия брой същите редове в същия ред, тогава данните се дедупликират. Ще получите "Ok" в отговор на вмъкването, но една партида от данни действително ще бъде записана и няма да бъде дублирана.

Това е необходимо за сигурност. Ако получите „Ok“ по време на вмъкването, значи вашите данни са вмъкнати. Ако получите грешка от ClickHouse, те не са вмъкнати и трябва да повторите вмъкването. Но ако връзката е прекъсната по време на вмъкването, тогава не знаете дали данните са вмъкнати или не. Единственият вариант е да повторите вмъкването отново. Ако данните действително са били вмъкнати и сте ги вмъкнали отново, има дедупликация на блокове. Това е необходимо, за да се избегнат дубликати.

И също така е важно как работи за материализирани възгледи. Ако данните са били дедупликирани при вмъкване в главната таблица, те също няма да отидат в материализирания изглед.

Сега относно въпроса. Вашата ситуация е по-сложна, защото пишете дубликати на отделни редове. Тоест дублира се не целият пакет, а конкретни линии и те се свиват на заден план. Наистина, данните ще се свият в главната таблица, а несвитите ще отидат в материализирания изглед и нищо няма да се случи с материализираните изгледи по време на сливането. Тъй като материализираният изглед не е нищо повече от тригер при вмъкване. Нищо друго не се случва с него по време на други операции.

И не мога да бъда щастлив тук. Необходимо е само да се търси конкретно решение за този случай. Например, възможно ли е да го замените в материализиран изглед и методът за дедупликация може би ще работи по същия начин. Но за съжаление, не винаги. Ако се агрегира, тогава няма да работи.

Кирил Шваков: Едно време имахме и костостроене. Имаше проблем, че има рекламни импресии и има някои данни, които можем да покажем в реално време - това са само импресии. Те рядко се дублират, но ако се случи, ние така или иначе ще ги свием. И имаше неща, които не могат да бъдат дублирани - кликове и цялата тази история. Но също така исках да ги покажа почти веднага.

Как са направени материализирани изгледи? Имаше изгледи, където се пише директно - има запис в raw data, а се пише в изгледи. Там по някое време данните не са много коректни, дублират се и т.н. И има втората част на таблицата, където те изглеждат абсолютно същите като материализираните изгледи, тоест те са абсолютно еднакви по структура. От време на време преизчисляваме данните, преброяваме данните без дубликати, записваме в тези таблици.

Минахме през API - това няма да работи в ClickHouse на ръка. И API изглежда: когато имам датата на последното добавяне към таблицата, където е гарантирано, че правилните данни вече са изчислени, и прави заявка към една таблица и към друга таблица. От едната заявка избира до определено време, а от другата получава това, което още не е изчислено. И работи, но не чрез една ClickHouse.

Ако имате някакъв вид API - за анализатори, за потребители - тогава по принцип това е опция. Ти винаги броиш, винаги броиш. Това може да се прави веднъж на ден или по друго време. Вие сами избирате гамата, която не ви е необходима и не е критична.

ClickHouse има много регистрационни файлове. Как мога да видя всичко, което се случва със сървъра в един момент?

ClickHouse има много голям брой различни дневници и този брой се увеличава. В новите версии някои от тях дори са активирани по подразбиране, в по-старите версии те трябва да бъдат активирани при актуализиране. Те обаче стават все повече и повече. Бих искал най-накрая да видя какво се случва сега с моя сървър, може би на някакво обобщено табло.

Имате ли в екипа на ClickHouse или в екипите на ваши приятели, които поддържат някаква функционалност на готови табла, които да показват тези логове като завършен продукт? В крайна сметка просто гледането на регистрационните файлове в ClickHouse е страхотно. Но би било много готино, ако вече беше подготвен под формата на табло. Бих се надрусал от това.

Има табла, но те не са стандартизирани. Имаме около 60 екипа в нашата компания, които използват ClickHouse и най-странното е, че много от тях имат табла за управление, които са направили сами и са малко по-различни. Някои екипи използват вътрешната инсталация на Yandex.Cloud. Има няколко готови отчета, но не всички необходими. Други имат своите.

Колегите ми от Метрика имат свое табло в Графана, а аз имам мое за собствен клъстер. Гледам на нещата като кеш хит за серифен кеш. И още по-трудно е, че използваме различни инструменти. Създадох моето табло за управление на много стар инструмент, наречен Graphite-web. Той е напълно грозен. И все още го използвам така, въпреки че Grafana сигурно щеше да е по-удобен и по-красив.

Основното нещо в таблата за управление е същото. Това са системни показатели за клъстера: CPU, памет, диск, мрежа. Други са броят на едновременните заявки, броят на едновременните сливания, броят на заявките за секунда, максималния брой парчета за дяловете на таблицата MergeTree, забавянето на репликацията, размера на опашката за репликация, броя на редовете, вмъкнати за секунда, броя на блоковете, въведени в секунда. Това е всичко, което се получава не от дневниците, а от метриките.

Владимир Колобаев: Алексей, бих искал да коригирам малко. Има Графана. Grafana има източник на данни, който е ClickHouse. Тоест мога да правя заявки от Grafana директно към ClickHouse. ClickHouse има маса с трупи, тя е еднаква за всички. В резултат на това искам да получа достъп до тази журнална таблица в Grafana и да видя заявките, които моят сървър прилага. Би било чудесно да има такова табло.

Самият аз го карах. Но имам въпрос - ако всичко е стандартизирано и Grafana се използва от всички, защо Yandex няма такова официално табло?

Кирил Шваков: Всъщност източникът на данни, който ClickHouse сега поддържа Altinity. А аз просто искам да дам вектор къде да се копае и кой да се бута. Можете да ги попитате, защото Yandex все пак прави ClickHouse, а не историята около него. Altinity е основната компания, която в момента рекламира ClickHouse. Няма да го изоставят, а ще го подкрепят. Защото по принцип, за да качите табло в сайта на Графана, трябва само да се регистрирате и да го качите - няма особени проблеми.

Алексей Миловидов: През последната година ClickHouse добави много функции за профилиране на заявки. Има показатели за всяка заявка за използване на ресурс. И наскоро беше добавен профилиращ профил на заявки от още по-ниско ниво, за да видите къде прекарва заявката всяка милисекунда. Но за да използвам тази функционалност, трябва да отворя конзолния клиент и да напиша заявка, която постоянно забравям. Записах го някъде и винаги забравям къде точно.

Иска ми се да има инструмент, който просто казва - ето вашите тежки заявки, групирани по клас на заявка. Щракнах върху един и те ми казаха, че е тежък. Сега няма такова решение. И наистина е доста странно, когато хората ме питат: „Кажи ми, има ли готови табла за Графана?“ от Костян. Не знам какво е, аз самият не съм го използвал."

Как да повлияем на мерджи, така че сървърът да не изпадне в OOM?

Имам таблица, има само един дял в таблицата, той е ReplacingMergeTree. Записвам данни в него от четири години. Трябваше да направя промяна в него и да изтрия някои данни.

Направих това и в хода на обработката на тази заявка цялата памет на всички сървъри в клъстера беше изядена и всички сървъри в клъстера преминаха в OOM заедно. След това всички станаха заедно, започнаха да обединяват същата операция, този блок от данни, и отново попаднаха в OOM. След това те отново станаха и отново паднаха. И това нещо не спря.

След това се оказа, че това всъщност е грешка, която момчетата са коригирали. Това е много готино, благодаря ви много. Но остатъкът остана. И сега, когато мисля за необходимостта да направя определено сливане в таблицата, имам въпрос - защо не мога да взема тези сливания и по някакъв начин да им повлияя? Например, ограничете ги от необходимото количество RAM или по принцип от техния брой, който ще обработва тази конкретна таблица.

Имам таблица, наречена „Метрики“, моля, обработете я вместо мен в два потока. Няма нужда да създавате десет или пет сливания паралелно, направете го на две. Мисля, че за две имам достатъчно памет, но може да не стигне за обработка на десет. Защо страхът остава? Тъй като таблицата расте и някой ден ще се натъкна на ситуация, която по принцип вече не се дължи на грешка, а поради факта, че данните ще се променят в толкова голямо количество, че просто нямам достатъчно памет на сървърът. И тогава сървърът ще попадне в OOM по време на сливането. Освен това мога да отменя мутацията, но сливането го няма.

Знаете, че при сливане сървърът няма да попадне в OOM, защото при сливането количеството RAM се използва само за един малък диапазон от данни. Така че всичко ще бъде наред, независимо от количеството данни.

Владимир Колобаев: Глоба. Тук моментът е такъв, че след като направихме корекция на грешка, изтеглих нова версия за себе си и на друга маса, по-малка, където има много дялове, направих подобна операция. И по време на сливането около 100 GB RAM бяха изгорени на сървъра. Имах 150 заети, изядох 100 и оставаше прозорец от 50 GB, така че не попаднах в OOM.

Какво ме предпазва в момента от попадане в OOM, ако наистина консумира 100 GB RAM? Какво да направите в ситуация, ако внезапно RAM на merdzh свърши?

Алексей Миловидов: Има такъв проблем, че консумацията на рам не се ограничава до мерджиите. И вторият проблем е, че ако е зададено сливане, то трябва да се изпълни, защото се записва в регистрационния файл на репликация. Регистърът на репликацията е действията, които са необходими за привеждане на репликата в последователно състояние. Ако не направите ръчни манипулации, че този регистрационен файл за репликация ще се върне назад, сливането ще трябва да се извърши по един или друг начин.

Разбира се, не би било излишно да има ограничение на RAM, което „за всеки случай“ предпазва от OOM. Това няма да помогне на изпълнението на сливането, то ще започне отново, ще достигне някакъв праг, ще хвърли изключение и след това ще започне отново - нищо добро няма да излезе от това. Но по принцип би било полезно да се въведе това ограничение.

Как ще се осъществи разработването на драйвера Golang за ClickHouse?

Драйверът Golang, написан от Кирил Шваков, вече се поддържа официално от екипа на ClickHouse. Той в хранилището на ClickHouse, той вече е голям и истински.

Малка забележка. Има прекрасно и обичано хранилище на нормални форми на безкраен ред - това е Vertica. Те също имат свой собствен официален драйвер за питон, който се поддържа от разработчиците на Vertica. И няколко пъти се случи версиите на хранилището и версиите на драйвера да се разделят доста рязко и драйверът да спре да работи в даден момент. И втората точка. Поддръжката на този официален драйвер, струва ми се, се поддържа от системата „нипел“ - пишете им проблем и той виси завинаги.

Имам два въпроса. Сега Golang драйверът на Кирил е почти стандартен начин за комуникация от Golang с ClickHouse. Освен ако някой все още не общува през http интерфейса, защото много го харесва. Как ще бъде разработен този драйвер? Ще бъде ли синхронизиран с някои разбиващи промени в самото хранилище? И каква е процедурата за разглеждане на въпроса?

Кирил Шваков: Първият е как всичко е подредено бюрократично. Тази точка не е обсъждана, така че няма какво да отговоря.

За да отговорим на въпроса за проблема, имаме нужда от малко история на драйвера. Работех за компания, която имаше много данни. Това беше рекламен спинър с огромен брой събития, които трябваше да се съхраняват някъде. И по някое време се появи ClickHouse. Изсипахме данни в него и в началото всичко беше наред, но след това ClickHouse падна. По това време решихме, че не ни трябва.

Година по-късно се върнахме към идеята да използваме ClickHouse и трябваше по някакъв начин да напишем данни там. Входът беше следният - желязото е много слабо, има малко ресурси. Но ние винаги сме работили по този начин и затова погледнахме към естествения протокол.

Тъй като работехме върху Go, беше ясно, че имаме нужда от драйвер за Go. Правих го почти на пълен работен ден - това беше работната ми задача. До един момент го повдигнахме и по принцип никой не очакваше, че някой друг освен нас ще го използва. След това CloudFlare се появи с точно същия проблем и известно време работихме много гладко с тях, защото имаха същите задачи. И го направихме както в самия ClickHouse, така и в драйвера.

В един момент просто спрях да го правя, защото дейността ми по отношение на ClickHouse и с работата малко се промени. Следователно проблемите не са затворени. Периодично хората, които се нуждаят от нещо, сами се ангажират с хранилището. След това гледам заявката за изтегляне и понякога дори сам редактирам нещо, но това се случва рядко.

Искам да се върна при шофьора. Преди няколко години, когато започна цялото това нещо, ClickHouse също беше различен и с различни функции. Сега има разбиране как да преработите драйвера, така че да е добър. Ако това се случи, тогава версия 2 така или иначе ще бъде несъвместима поради натрупаните патерици.

Не знам как да уредя това. Аз самият нямам много време. Ако някои хора довършат драйвера, мога да им помогна и да им кажа какво да правят. Но активното участие на Yandex в развитието на проекта все още не е обсъждано по никакъв начин.

Алексей Миловидов: Всъщност все още няма бюрокрация за тези драйвери. Единственото нещо е, че те се преместват в официална организация, тоест този драйвер се разпознава като официално решение по подразбиране за Go. Има и други драйвери, но те идват отделно.

Нямаме разработка за тези драйвери вътре. Въпросът е дали можем да наемем индивид, не специално за този драйвер, а за развитието на всички общностни драйвери, или можем да намерим някой външен.

Външният речник не се повдига след рестартиране с активиран lazy_load. Какво да правя?

Имаме активирана настройка lazy_load и след рестартиране на сървъра самият речник не се издига. Повдига се само след като потребителят получи достъп до този речник. И извежда грешка при първото повикване. Възможно ли е по някакъв начин автоматично да зареждате речници с помощта на ClickHouse или винаги трябва сами да контролирате тяхната готовност, така че потребителите да не получават грешки?

Може би имаме стара версия на ClickHouse, така че речникът не се е заредил автоматично. Може ли да бъде?

Първо, речниците могат да бъдат принудително заредени с помощта на заявката речници за презареждане на системата. Второ, за грешката - ако речникът вече е зареден, тогава заявките ще работят върху данните, които са били заредени. Ако речникът все още не е зареден, той ще бъде зареден точно в момента на заявката.

За тежките речници това не е много удобно. Например, трябва да извлечете милион реда от MySQL. Някой прави проста селекция, но тази селекция ще изчака същите милиони редове. Тук има две решения. Първият е да изключите lazy_load. Второто е, когато сървърът се издигне, преди да включите натоварването върху него, направете речник за презареждане на системата или просто изпълнете заявка, която използва речник. След това речникът ще бъде зареден. Трябва да контролирате наличието на речници с активирана настройка lazy_load, тъй като ClickHouse не ги изтегля автоматично.

Отговорът на последния въпрос е или версията е стара, или има нужда от отстраняване на грешки.

Какво ще кажете за факта, че речниците за презареждане на системата не зареждат нито един от многото речници, ако поне един от тях се срине с грешка?

Има още един въпрос относно речниците за презареждане на системата. Имаме два речника - единият не е зареден, вторият е зареден. Речниците за презареждане на системата в този случай не зареждат никакъв речник и трябва да заредите конкретен речник от точка до точка по неговото име, като използвате речника за презареждане на системата. Това също ли е свързано с версията на ClickHouse?

Искам да угодя. Това поведение се промени. Така че, ако актуализирате ClickHouse, той също ще се промени. Ако не сте доволни от текущото поведение речници за презареждане на системата, актуализирайте и да се надяваме, че ще се промени към по-добро.

Има ли начин да конфигурирате подробностите в конфигурацията на ClickHouse, но да не ги светвате при грешки?

Следващият въпрос е за грешки, свързани с речника, а именно подробности. Регистрирахме подробностите за връзката в конфигурацията на ClickHouse към речника и в случай на грешка получаваме тези данни и паролата в отговор.

Решихме тази грешка, като добавихме подробности към конфигурацията на ODBC драйвера. Има ли някакъв начин да конфигурирате подробностите в конфигурацията на ClickHouse, но да не показвате тези подробности при грешки?

Тук решението наистина е - да посочите тези идентификационни данни в odbc.ini, а в самия ClickHouse да посочите само ODBC Data Source Name. Това няма да се случи за други източници на речник - нито за речник с MySQL, нито за останалите не трябва да виждате паролата в съобщението за грешка. За ODBC също ще погледна - ако има такова просто трябва да го махнеш.

Бонус: фонове за Zuma от събирания

С щракване върху снимката за най-упоритите читатели ще се отворят бонус фонове от събирания. Потушаване на огъня заедно с технологичните талисмани на Авито, съвещание с колеги от стаята на системния администратор или компютърен клуб от старата школа и провеждане на ежедневие под моста на фона на графити.

Източник: www.habr.com