Ефективно използване на ClickHouse. Алексей Миловидов (Яндекс)

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

Здравейте всички! Казвам се Алексей, правя ClickHouse.

Първо, бързам да ви зарадвам веднага, днес няма да ви кажа какво е ClickHouse. Честно казано, уморих се от това. Всеки път ти казвам какво е. И вероятно всички вече знаят.

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

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

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

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

Ако разгледаме как ClickHouse извършва вмъкване, тогава можете да изпратите поне терабайт данни в една заявка. Не е проблем.

И да видим какво ще бъде типичното представяне. Например, имаме таблица с данни на Yandex.Metrica. Хитове. 105 някои колони. 700 байта некомпресирани. И ние ще вмъкнем по добър начин партиди от един милион реда.

Вмъкваме в таблицата MergeTree, получават се половин милион реда в секунда. Страхотен. В репликирана таблица - ще бъде малко по-малко, около 400 000 реда в секунда.

И ако включите вмъкването на кворума, получавате малко по-малко, но все пак прилична производителност, 250 000 пъти в секунда. Вмъкването на кворум е недокументирана функция в ClickHouse*.

* към 2020 г., вече документиран.

Какво се случва, ако го направите погрешно? Вмъкваме един ред в таблицата MergeTree и получаваме 59 реда в секунда. Това е 10 000 пъти бавно. В ReplicatedMergeTree - 6 реда в секунда. И ако кворумът се включи, тогава се получават 2 реда в секунда. Според мен това е някаква пълна глупост. Как можеш да забавиш така? Дори на тениската ми пише, че ClickHouse не трябва да забавя. Но въпреки това понякога се случва.

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

От техническа гледна точка най-важното е, че когато правите вмъкване в ClickHouse, данните не влизат в нито една memtable. Дори нямаме истинска лог структура на MergeTree, а само MergeTree, защото няма нито log, нито memTable. Просто незабавно записваме данните във файловата система, вече разложена на колони. И ако имате 100 колони, тогава повече от 200 файла ще трябва да бъдат записани в отделна директория. Всичко това е много тромаво.

И възниква въпросът: „Как да го направя правилно?“ Ако възникне такава ситуация, все още трябва по някакъв начин да запишете данни в ClickHouse.

Метод 1. Това е най-лесният начин. Използвайте някакъв вид разпределена опашка. Например Кафка. Просто изваждате данни от Kafka, ние ги пакетираме веднъж на секунда. И всичко ще бъде наред, записвате, всичко работи добре.

Недостатъците са, че Kafka е друга тромава разпределена система. Разбирам също така, ако вече имате Кафка във вашата компания. Добре е, удобно е. Но ако не е там, тогава трябва да помислите три пъти, преди да плъзнете друга разпределена система във вашия проект. И затова си струва да обмислим алтернативи.

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

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

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

От друга страна, данните също изчезват с kill -9. Ако вашият сървър се повреди, вие ще загубите тези данни. И друг проблем е, че ако не можете да пишете в базата данни, вашите данни ще се натрупат в RAM. И или RAM паметта свършва, или просто губите данни.

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

В този случай обаче данните ще бъдат изпратени незабавно до ClickHouse. И самата ClickHouse ще ги буферира.

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

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

*от 2020 г. също трябва да се добави към разглеждането Къща за котенца.

Метод 6. Друг начин е да използвате буферни таблици. Предимството на този метод е, че е много лесно да започнете да го използвате. Създайте буферна таблица и вмъкнете в нея.

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

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

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

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

* от 2020 г. има подобна поддръжка за RabbitMQ.

Какво друго може да бъде неудобно или неочаквано при вмъкване на данни? Ако направите заявка за вмъкване на стойности и напишете някои изчислени изрази в стойности. Например, now() също е оценен израз. И в този случай ClickHouse е принуден да стартира интерпретатора на тези изрази за всеки ред и производителността ще спадне с порядъци. По-добре да го избягвате.

* в момента проблемът е напълно решен, няма повече регресия на производителността при използване на изрази в VALUES.

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

* наскоро в ClickHouse в експериментален режим беше добавена поддръжка за компактен формат на парчета и парчета в RAM с предварително записващ лог, което почти напълно решава проблема.

Сега разгледайте втория вид проблем - въвеждането на данни.

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

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

Например имаме IP адрес. В един случай го записахме като низ. Например 192.168.1.1. В противен случай това ще бъде число от тип UInt32*. 32 бита са достатъчни за IPv4 адрес.

Първо, колкото и да е странно, данните ще бъдат компресирани приблизително по същия начин. Ще има разлика, разбира се, но не толкова голяма. Така че няма специални проблеми с I/O на диска.

Но има сериозна разлика в процесорното време и времето за изпълнение на заявката.

Нека преброим броя на уникалните IP адреси, ако те се съхраняват като числа. Получава се 137 милиона реда в секунда. Ако е същото като линиите, тогава 37 милиона реда в секунда. Не знам защо се получи това съвпадение. Сам съм правил тези искания. Но въпреки това около 4 пъти по-бавно.

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

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

Нека разгледаме различни случаи.

1. Един случай, когато имате няколко различни уникални стойности. В този случай използваме проста практика, която вероятно знаете и можете да използвате за всяка СУБД. Всичко това има смисъл не само за ClickHouse. Просто запишете цифровите идентификатори в базата данни. И можете да конвертирате в низове и обратно отстрани на вашето приложение.

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

Вместо това ние просто записваме номера Ulnt32 и 250. Имаме 250 в Yandex, но вашият може да е различен. За всеки случай ще кажа, че ClickHouse има вградена възможност за работа с геобаза. Просто записвате директория с региони, включително йерархична, т.е. ще има Москва, Московска област и всичко, от което се нуждаете. И можете да конвертирате на ниво заявка.

Вторият вариант е почти същият, но с поддръжка в ClickHouse. Това е тип данни Enum. Вие просто пишете всички стойности, от които се нуждаете, в Enum. Например, типа на устройството и напишете там: настолен компютър, мобилен телефон, таблет, телевизор. Само 4 варианта.

Недостатъкът е, че трябва периодично да променяте. Добавена е само една опция. Изработваме алтернативна маса. Всъщност alter table в ClickHouse е безплатен. Особено безплатно за Enum, защото данните на диска не се променят. Но въпреки това alter придобива заключване * на масата и трябва да изчака, докато всички селекции бъдат завършени. И едва след като тази промяна ще бъде изпълнена, т.е. все още има някои неудобства.

* в последните версии на ClickHouse, ALTER е направен напълно неблокиращ.

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

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

Ето един пример. Има Yandex.Direct. И има рекламна фирма и банери. Вероятно има десетки милиони рекламни компании. И грубо се побира в RAM. И има милиарди банери, те не се побират. И ние използваме кеширан речник от MySQL.

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

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

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

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

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

И има един прост трик. Вярно е, че също не е много подходящ за сериозни данни, но ако нещо не е много сериозно, тогава просто добавете друг идентификатор на клиента към ключа на речника. И тогава ще имате сблъсъци, но само в рамките на един клиент. И ние използваме този метод за картата на връзките в Yandex.Metrica. Имаме url адреси там, съхраняваме хешове. И знаем, че има конфликти, разбира се. Но когато се покаже страница, тогава вероятността на една страница за един потребител някои URL адреси да се слепят и това да бъде забелязано, тогава това може да бъде пренебрегнато.

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

Друг пример, ако низовете са кратки, като домейни на уебсайтове. Те могат да се съхраняват както са. Или, например, езикът на браузъра ru е 2 байта. Разбира се, съжалявам за байтовете, но не се притеснявайте, 2 байта не са жалко. Моля, запазете го както е, не се притеснявайте.

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

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

И ако данните се съхраняват на място, те просто се четат в правилния ред от файловата система и всичко е наред.

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

За url адреси, например, можете да съхранявате домейна отделно. И ако наистина имате нужда от домейн, просто използвайте тази колона и URL адресите ще лъжат и дори няма да ги докоснете.

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

И в един случай ние просто ще получим URL адресите и ще изчислим домейна. Оказва се 166 милисекунди. И ако вземете готов домейн, тогава се оказва само 67 милисекунди, тоест почти три пъти по-бързо. И по-бързо, не защото трябва да правим някакви изчисления, а защото четем по-малко данни.

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

И ако погледнете количеството данни на диска, се оказва, че URL адресът е 126 мегабайта, а домейнът е само 5 мегабайта. Оказва се 25 пъти по-малко. Въпреки това, заявката все още е само 4 пъти по-бърза. Но това е, защото данните са горещи. И ако беше студено, вероятно щеше да е 25 пъти по-бързо поради дисков I/O.

Между другото, ако прецените колко домейнът е по-малък от URL адреса, тогава се оказва, че е около 4 пъти, но по някаква причина данните на диска отнемат 25 пъти по-малко. Защо? Поради компресия. И URL адресът е компресиран, и домейнът е компресиран. Но често URL адресът съдържа куп боклук.

И, разбира се, струва си да използвате правилните типове данни, които са специално проектирани за правилните стойности или които пасват. Ако сте в IPv4, запазете UInt32*. Ако IPv6, тогава FixedString(16), тъй като IPv6 адресът е 128 бита, т.е. съхранява се директно в двоичен формат.

Но какво ще стане, ако понякога имате IPv4 адреси, а понякога IPv6? Да, можете да запазите и двете. Една колона за IPv4, друга за IPv6. Разбира се, има опция за съпоставяне на IPv4 към IPv6. Това също ще работи, но ако често се нуждаете от IPv4 адрес във вашите заявки, тогава би било хубаво да го поставите в отделна колона.

* Сега ClickHouse има отделни типове данни IPv4, IPv6, които съхраняват данни толкова ефективно, колкото числата, но ги представят толкова удобно, колкото низове.

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

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

Така че в този случай би било по-правилно да се раздели на 4 колони. Тук не се страхувайте, защото това е ClickHouse. ClickHouse е колонна база данни. И колкото повече кокетни малки колони, толкова по-добре. Ще има 5 BrowserVersion, направете 5 колони. Това е добре.

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

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

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

* Сега ClickHouse има тип данни Ниска кардиналност което ви позволява ефективно да съхранявате низове с по-малко усилия.

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

Тук виждаме хиляда таблици, всяка от които съдържа остатъка от деленето на неясно какво на хиляда.

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

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

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

Или, например, microsharding, но повече за това по-късно.

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

И понякога хората ме питат: „Как се променя ефективността на заявките за обхват в ClickHouse с размера на таблицата?“. Казвам, че изобщо не се променя. Например, имате таблица с милиард реда и четете диапазон от един милион реда. Всичко е наред. Ако таблицата има трилион реда и вие четете един милион реда, тогава ще бъде почти същото.

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

Промяната в ClickHouse е безплатна, ако се промени колона за добавяне/пускане.

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

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

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

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

* Сега ClickHouse има повече въвеждане на таблична функция.

Друг анти-модел е microsharding. Например, трябва да шардите данни и имате 5 сървъра, а утре ще има 6 сървъра. И мислите как да балансирате отново тези данни. И вместо това не се разделяте на 5 фрагмента, а на 1 фрагмента. И след това картографирате всеки от тези микрошардове към отделен сървър. И ще успеете на един сървър, например 000 ClickHouse, например. Отделен екземпляр на отделни портове или отделни бази данни.

Но в ClickHouse това не е много добре. Защото дори едно копие на ClickHouse се опитва да използва всички налични ресурси на сървъра, за да обработи една заявка. Тоест имате някакъв сървър и там, например, 56 процесорни ядра. Изпълнявате заявка, която отнема една секунда и ще използва 56 ядра. И ако поставите 200 ClickHouses на един сървър там, тогава се оказва, че ще стартират 10 000 нишки. Като цяло всичко ще бъде много зле.

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

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

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

Като цяло предварителното агрегиране е добро. Имахте милиард реда, събрахте ги и станаха 1 реда и сега заявката се изпълнява незабавно. Всичко е страхотно. Ето как можете да го направите. И за това дори ClickHouse има специален тип таблица AggregatingMergeTree, който извършва постепенно агрегиране при вмъкване на данни.

Но има моменти, в които си мислите, че ние ще събираме данни като тези и ще събираме данни като тези. И в някой съседен отдел, също не искам да казвам кой, използват SummingMergeTree таблици за сумиране по първичния ключ и 20 колони се използват като първичен ключ. За всеки случай промених имената на някои колони за конспирация, но това е всичко.

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

И какво е особено добро? Че тези хора от съседния отдел отиват и питат понякога да добавят още една колона към първичния ключ. Тоест събрахме данните така и сега искаме малко повече. Но в ClickHouse няма алтернативен първичен ключ. Следователно трябва да напишете някои скриптове на C ++. И аз не харесвам скриптове, дори и да са на C++.

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

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

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

Защо много такива заявки в безкраен цикъл са лоши? Ако индексът не се използва, тогава ще имате много преминавания на едни и същи данни. Но ако се използва индекс, например, имате първичен ключ на ru и там пишете url = нещо. И мислите, че един url ще бъде прочетен по точки от таблицата, всичко ще бъде наред. Но наистина не. Защото ClickHouse прави всичко на партиди.

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

И като бонус можете да видите, че в ClickHouse не трябва да се страхувате да прехвърлите дори мегабайти и дори стотици мегабайти в секцията IN. Спомням си от нашата практика, че ако подадем куп стойности в секцията IN в MySQL, например, подадем 100 мегабайта от някакви числа там, тогава MySQL изяжда 10 гигабайта памет и нищо друго не се случва това, всичко работи зле.

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

Има обаче някои трудности. Например, че IN с подзаявка не използва индекса. Но това си е наш проблем и трябва да го оправим. Тук няма нищо фундаментално. Хайде да го направим*.

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

* вече използвам; всичко беше поправено, както беше обещано.

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

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

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

Сега още нещо интересно. Това е ръчна репликация.

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

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

И периодично все още трябва да синхронизирате ръчно. Например веднъж месечно администраторите правят rsync.

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

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

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

В таблица MergeTree не е необходимо да имате дата и час. Все още можете да използвате. Ако няма дата и час, напишете, че по подразбиране е 2000. Ще работи и няма да изисква ресурси.

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

От друга страна, могат да се използват примитивни машини за таблици. Например, попълнете данните веднъж и вижте, завъртете и изтрийте. Можете да използвате Log.

Или съхраняването на малки обеми за междинна обработка е StripeLog или TinyLog.

Паметта може да се използва, ако има малко количество данни и просто завъртете нещо в RAM.

ClickHouse не харесва много пренормираните данни.

Ето един типичен пример. Това е огромен брой URL адреси. Поставяте ги в съседната таблица. И тогава решихме да направим JOIN с тях, но това няма да работи, като правило, защото ClickHouse поддържа само Hash JOIN. Ако няма достатъчно RAM за много данни, с които да се свържете, тогава JOIN няма да работи *.

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

* и сега ClickHouse също има присъединяване за сливане и работи в условия, при които междинните данни не се побират в RAM. Но това е неефективно и препоръката остава в сила.

Още няколко примера, но вече се съмнявам дали са антишаблони или не.

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

* отдавна е добавена поддръжка за актуализиране и изтриване в пакетен режим.

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

Разпределени JOIN в ClickHouse - това също се обработва зле от програмата за планиране на заявки.

Лошо, но понякога добре.

Използване на ClickHouse само за четене на данни с select*.

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

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

Въпроси

Благодаря за доклада! Къде да се оплача за срива на ClickHouse?

Можете да се оплачете лично на мен още сега.

Наскоро започнах да използвам ClickHouse. Веднага премахна cli интерфейса.

Какъв резултат.

Малко по-късно пуснах сървъра с малък селект.

Имаш талант.

Отворих грешка в GitHub, но тя беше игнорирана.

Ще видим.

Алексей ме подмами да присъствам на доклада, като ми обеща да ми каже как притискате данните вътре.

Много просто.

Това разбрах вчера. Повече конкретика.

Няма страшни трикове. Това е просто компресия блок по блок. По подразбиране е LZ4, можете да активирате ZSTD*. Блокира от 64 килобайта до 1 мегабайт.

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

Блоковете само необработени данни ли са?

Не точно сурово. Има масиви. Ако имате цифрова колона, тогава числата в един ред се подреждат в масив.

Ясно е.

Алексей, пример, който беше с uniqExact през IP адреси, т.е. фактът, че uniqExact отнема повече време за броене по низове, отколкото по числа и т.н. Ами ако направим финт с уши и замятаме в момента на корекцията? Тоест ти май каза, че на диска не се различава много. Ако четем редове от диска, кастаме, тогава ще имаме ли агрегати по-бързо или не? Или все още незначително печелим тук? Струва ми се, че сте го тествали, но по някаква причина не сте го посочили в бенчмарка.

Мисля, че ще е по-бавно, отколкото без кастинг. В този случай IP адресът трябва да бъде анализиран от низа. Разбира се, в ClickHouse анализът на IP адрес също е оптимизиран. Много се постарахме, но на едно и също място имаш числата, написани в десетхилядна форма. Много неудобно. От друга страна, функцията uniqExact ще работи по-бавно върху низове, не само защото това са низове, но и защото е избрана различна специализация на алгоритъма. Просто низовете се обработват по различен начин.

И ако вземем по-примитивен тип данни? Например те записаха потребителското име, което имаме, записаха го като линия и след това го кастнаха, ще бъде ли по-забавно или не?

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

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

т.е. частично рестартиране?

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

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

Не мисля така.

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

Да, но за съжаление не в C++.

Вашите колеги могат ли да пишат на C++?

Ще намеря някой.

Страхотен*.

* функцията е добавена два месеца след доклада - разработена е от автора на въпроса и е изпратена от него pull request.

Благодаря ви!

Здравейте! Благодаря за доклада! Споменахте, че ClickHouse консумира много добре всички налични ресурси. И говорителят до Luxoft говори за решението си за руските пощи. Той каза, че много харесват ClickHouse, но не го използват вместо основния си конкурент именно защото изяде целия процесор. И те не можаха да го вместят в своята архитектура, в своя ZooKeeper с докери. Възможно ли е по някакъв начин да се ограничи ClickHouse, така че да не консумира всичко, което му стане достъпно?

Да, възможно е и много лесно. Ако искате да консумирате по-малко ядра, просто пишете set max_threads = 1. И това е всичко, той ще изпълни заявката в едно ядро. Освен това можете да зададете различни настройки за различните потребители. Така че няма проблем. И кажете на колегите от Luxoft, че не е добре, че не са намерили тази настройка в документацията.

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

Първо, дневниците обикновено не са дълги редове. Има, разбира се, и изключения. Например, някаква услуга, написана на java, хвърля изключение, то се регистрира. И така в безкраен цикъл и при изчерпване на пространството на твърдия диск. Решението е много просто. Ако линиите са много дълги, тогава ги изрежете. Какво означава дълго? Десетки килобайти е лошо *.

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

Един килобайт нормален ли е?

Това е нормално.

Здравейте! Благодаря за доклада! Вече попитах за това в чата, но не помня дали получих отговор. Има ли някакъв план за разширяване на секцията WITH по CTE начин?

Все още не. Частта СЪС е някак несериозна. Това е като малка функция за нас.

Разбирам. Благодаря ти!

Благодаря за доклада! Много интересно! глобален въпрос. Предвижда ли се да се направи, може би под формата на някакви мъничета, модификация на изтриването на данни?

Задължително. Това е първата ни задача в нашата опашка. Сега активно мислим как да направим всичко правилно. И трябва да започнете да натискате клавиатурата*.

* натисна бутоните на клавиатурата и всичко беше готово.

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

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

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

Да.

Въпрос. Ако не можем да изберем първичен ключ, тогава правилно ли е да го направим точно чрез полето „Дата“, така че във фонов режим да има по-малко преструктуриране на тези данни, така че да се поберат по по-подреден начин? Ако нямате заявки за диапазон и дори не можете да изберете първичен ключ, струва ли си да поставите дата в първичния ключ?

Да.

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

Добре, благодаря ти много!

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