Оптимизация на редовете в ClickHouse. Доклад на Яндекс

Аналитичната СУБД ClickHouse обработва множество различни стрингове, което консумира ресурси. За да се ускори работата на системата, постоянно се добавят нови оптимизации. Разработчикът на ClickHouse, Николай Кочетов, разказва за стринговия тип данни, включително и за новия тип LowCardinality, и обяснява как можем да ускорим работата със стринговете.

— Първо нека да разберем как можем да съхраняваме стрингове.



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

Разбира се, понякога нещо забавя. Да предположим, че правите заявка към таблица. ClickHouse чете доста голямо количество данни, да кажем с скорост 100 ГБ/с, като обработва малко стрингове. Имаме две таблици, които съхраняват почти идентични данни. От втората таблица ClickHouse чете данни с по-голяма скорост, но стринговете на секунда се четат три пъти по-малко.

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

Ето още един пример. Нека предположим, че има предварително известно множество стрингове, ограничено до константа 1000 или 10 000 и практически никога не се променя. В този случай ни подхожда тип данни Enum, а в ClickHouse има два — Enum8 и Enum16. Благодарение на съхранението в Enum, ние бързо обработваме заявките.

В ClickHouse има ускорения за GROUP BY, IN, DISTINCT и оптимизации за някои функции, например за сравнение с константен стринг. Разбира се, числата в стринга не се преобразуват, а обратно, константният стринг се привежда към стойността на Enum. След това всичко бързо се сравнява.

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

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

Възниква въпросът, дали може да се направи по-добре? Вероятно да. Може да се запази структурата на Enum не в схемата на таблицата, а в ZooKeeper. Въпреки това могат да възникнат проблеми, свързани със синхронизацията. Например, една реплика е получила данни, друга — не, и ако при нея е старият Enum, нещо може да се счупи. (В ClickHouse почти завършихме неблокиращите ALTER-заявки. Когато ги завършим изцяло, няма да е необходимо да чакаме заявките за прочит.)

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

В речника ClickHouse съхраняваме множество различни редове, а в таблицата — техните идентификатори под формата на числа. Ако е необходимо да получим ред, извикваме функцията dictGet и работим с нея. След това не трябва да правим ALTER. За да добавим нещо в Enum, го вмъкваме в същата таблица MySQL.

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

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

Общ недостатък на двата метода е, че съхраняваме всички ключове на едно място и ги синхронизираме. Защо не съхраняваме речниците локално? Без синхронизация — без проблеми. Може да се съхрани речник локално в парче на диска. Тоест, направихме Insert, записахме речника. Ако работим с данните в паметта, можем да запишем речника или в блок от данни, или в парче колона, или в някакъв кеш, за да ускорим изчисленията.

Речниково кодиране на редове

Така стигнахме до създаването на нов тип данни в ClickHouse — LowCardinality. Това е формат за съхранение на данни: как те се записват на диска и как се четат, как са представени в паметта и схемата на обработката им.

На слайда има две колони. Отдясно редовете се съхраняват стандартно, в тип String. Ясно е, че това са някакви модели на мобилни телефони. Отляво има точно такава колона, но в тип LowCardinality. Тя се състои от речник с множество различни редове (редове от колоната вдясно) и списък с позиции (номера на редовете).

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

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

Особеността на LowCardinality е, че той може да се запазва за някои функции. На слайда се вижда пример за запитване. В първия ред създадох колона от тип LowCardinality от String, нарекох я S. След това попитах за името й — ClickHouse каза, че това е LowCardinality от String. Всичко е верно.

Третият ред е почти същият, само че извикахме функцията length. В ClickHouse функцията length връща тип данни UInt64. Но сега получихме LowCardinality от UInt64. Какъв е смисълът?

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

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

Също така може да бъде направена оптимизация на GROUP BY, защото нашата колона с речника вече е частично агрегирана — може по-бързо да се изчисляват стойностите на хеш-функциите и приблизително да се намира bucket, където да се постави новия ред. Освен това можете да специализирате някои агрегатни функции, например uniq, тъй като в нея може да се изпрати само речник, а позициите да останат недокоснати — така всичко ще работи по-бързо. Първите две оптимизации вече добавихме в ClickHouse.

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

Втората настройка се нарича low_cardinality_use_single_dictionary_for_part. Представете си, че в предишната схема, когато вмъквахме данни, нашият речник е пренаситен и сме го записали на диска. Въпросът е, защо сега да не формираме още един точно такъв речник?

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

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

Преди да обсъдим предимствата на LowCardinality, веднага ще кажа, че вряд ли ще постигнем намаляване на данните на диска (въпреки че това може да се случи), защото ClickHouse компресира данните. Има стандартен вариант – LZ4. Може също така да се направи компресия с помощта на ZSTD. Но и двата алгоритъма вече реализират речникова компресия, затова нашият външен речник ClickHouse не би бил много полезен.

За да не бъда голословен, взех някои данни от метриката — String, LowCardinality(String) и Enum — и ги записах в различни типове данни. Получиха се три колони, в които са записани един милиард реда. В първата колона, CodePage, има само 62 стойности. И е видно, че в LowCardinality(String) компресията е по-добра. String е малко по-зле, но това вероятно е заради факта, че низовете са кратки, ние запазваме техните дължини, а те заемат много място и не се компресират добре.

Ако вземем PhoneModel, те са 48 хиляди — вече повече, и разликата между String и LowCardinality(String) почти не съществува. За URL също спестихме само 2 GB — мисля, не си струва да се разчита на това.

Оценка на скоростта на работа

Линк от слайда

Сега ще оценим скоростта на работа. За да я оценя, използвах датасет с описание на таксиметрови пътувания в Ню Йорк. Той е наличен е на GitHub. В него има малко над един милиард пътувания. Отразени са местоположението, времето на начало и край на пътуването, начин на плащане, брой пътници и дори видът такси — зелено, жълто и Uber.

Първият запитвах направих доста прост — попитах къде най-често поръчват такси. За това трябва да взема местоположението, от което е правена поръчката, да направя по него GROUP BY и да изчисля функцията count. Ето какво дава ClickHouse.

За да измеря скоростта на обработка на запитването, създадох три таблици с идентични данни, но използвах три различни типа данни за нашето стартово местоположение — String, LowCardinality и Enum. LowCardinality и Enum се оказаха пет пъти по-бързи от String. Enum е по-бърз, защото работи с числа. LowCardinality — защото е реализирана оптимизация за GROUP BY.

Нека усложним запитването — ще попитаме къде се намира най-популярният парк в Ню Йорк. Отново ще измерваме по това, къде най-често поръчват такси, но ще филтрираме само тези местоположения, където има думата „парк“. Ще добавим и функцията like.

Гледаме времето — виждаме, че Enum изведнъж започна да забавя. Вярно, работи още по-бавно от стандартния тип данни String. Това се случва, защото функцията like съвсем не е оптимизирана за Enum. Трябва да преобразуваме нашите низове от Enum в обикновени низове — правим повече работа. LowCardinality(String) също не е оптимизиран по подразбиране, но при него like работи върху речника, така че запитването се ускорява в сравнение с String.

При работа с Enum има по-глобален проблем. Ако искаме да го оптимизираме, трябва да го направим на всяко място в кода. Да предположим, че сме написали нова функция — задължително трябва да измислим оптимизация за Enum. А при LowCardinality всичко е оптимизирано по подразбиране.

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

LowCardinality все още работи по-бързо, въпреки че тук няма филтриране. Това се дължи на факта, че нашите функции работят само със справочника. Функцията за изчисляване на хеш има един аргумент — може да обработва по-малко данни и също може да върне LowCardinality.

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

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