Оптимизация на низи в 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 ГБ — мисля, няма нужда да се разчита на това.

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

Връзка от слайда

Сега ще оценим скоростта на работа. За да я оценя, използвах набор от данни за описания на таксита в Ню Йорк. Той е наличен се намира на 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