Пераязджаем на ClickHouse: 3 гады праз

Тры гады таму Віктар Тарнаўскі і Аляксей Мілавідаў з Яндэкса на сцэне Высокая нагрузка++ расказвалі, які ClickHouse добры, і як ен не тармозіць. А на суседняй сцэне быў Аляксандр Зайцаў с дакладам аб пераездзе на ClickHouse з іншай аналітычнай СКБД і з высновай, што ClickHouse, вядома, добры, але не вельмі зручны. Калі ў 2016 годзе кампанія LifeStreet, у якой тады працаваў Аляксандр, перакладала мультыпетабайтавую аналітычную сістэму на ClickHouse, гэта была займальная «дарога з жоўтай цэглы», поўная невядомых небяспек. ClickHouse тады нагадваў міннае поле.

Тры гады праз ClickHouse стаў значна лепш - за гэты час Аляксандр заснаваў кампанію Altinity, якая не толькі дапамагае пераязджаць на ClickHouse дзясяткам праектаў, але і ўдасканальвае сам прадукт разам з калегамі з Яндэкса. Цяпер ClickHouse усё яшчэ не бесклапотная прагулка, але ўжо і не міннае поле.

Аляксандр займаецца размеркаванымі сістэмамі з 2003 года, распрацоўваў буйныя праекты на MySQL, Oracle и Вертыка. На мінулай HighLoad++ 2019 Аляксандр, адзін з піянераў выкарыстання ClickHouse, Распавёў, што цяпер з сябе ўяўляе гэтая СКБД. Мы даведаемся пра асноўныя асаблівасці ClickHouse: чым ён адрозніваецца ад іншых сістэм і ў якіх выпадках яго больш эфектыўна выкарыстоўваць. На прыкладах разгледзім свежыя і правераныя праектамі практыкі па пабудове сістэм на ClickHouse.

Рэтраспектыва: што было 3 гады таму

Тры гады таму мы перакладалі кампанію LifeStreet на ClickHouse з іншай аналітычнай базы дадзеных, і міграцыя аналітыкі рэкламнай сеткі выглядала так:

• Чэрвень 2016. У OpenSource з'явіўся ClickHouse і стартаваў наш праект;
• Жнівень. Доказ канцэпцыі: вялікая рэкламная сетка, інфраструктура і 200-300 тэрабайт дадзеных;
• Кастрычнік. Першыя прадакшн-дадзеныя;
• Снежань. Поўная прадуктовая нагрузка - 10-50 мільярдаў падзей у дзень.
• Чэрвень 2017. Паспяховы пераезд карыстальнікаў на ClickHouse, 2,5 петабайт дадзеных на кластары з 60-ці сервераў.

У працэсе міграцыі расло разуменне, што ClickHouse - Гэта добрая сістэма, з якой прыемна працаваць, але гэта ўнутраны праект кампаніі Яндэкс. Таму ёсць нюансы: Яндэкс спачатку будзе займацца ўласнымі ўнутранымі заказчыкамі і толькі потым - супольнасцю і патрэбамі знешніх карыстальнікаў, а ClickHouse не дацягваў тады да ўзроўню энтэрпрайзу па многіх функцыянальных абласцях. Таму ў сакавіку 2017 года мы заснавалі кампанію Altinity, каб зрабіць ClickHouse яшчэ хутчэй і зручней не толькі для Яндэкса, але і для іншых карыстальнікаў. І зараз мы:

• Навучальны і дапамагаем будаваць рашэнні на ClickHouse так, каб заказчыкі не набівалі гузы, і каб рашэнне ў выніку працавала;
• Забяспечваем 24/7 падтрымку ClickHouse-усталёўак;
• Распрацоўваем уласныя экасістэмныя праекты;
• Актыўна комитим у сам ClickHouse, адказваючы на ​​запыты карыстальнікаў, якія хочуць бачыць тыя ці іншыя фічы.

І вядома, мы дапамагаем з пераездам на ClickHouse с MySQL, Вертыка, Аракул, Грынплум, Redshift і іншых сістэм. Мы ўдзельнічалі ў самых розных пераездах, і яны ўсё былі паспяховымі.

Навошта ўвогуле пераязджаць на ClickHouse

Не тармозіць! Гэта галоўная прычына. ClickHouse - вельмі хуткая база дадзеных для розных сцэнарыяў:

Выпадковыя цытаты людзей, якія доўга працуюць з ClickHouse.

Маштабаванасць. На нейкі іншы БД можна дамагчыся нядрэннай прадукцыйнасці на адной жалязяцы, але ClickHouse можна маштабаваць не толькі вертыкальна, але і гарызантальна, проста дадаючы сервера. Усё працуе не так гладка, як хацелася б, але працуе. Можна нарошчваць сістэму разам з ростам бізнэсу. Гэта важна, што мы не абмежаваныя рашэннем зараз і заўсёды ёсць патэнцыял для развіцця.

Партуемасць. Няма прывязкі да чагосьці аднаго. Напрыклад, з Amazon RedShift цяжка кудысьці пераехаць. А ClickHouse можна паставіць сабе на наўтбук, сервер, задэплоіць у воблака, сысці ў Kubernetes - Няма абмежаванняў на эксплуатацыю інфраструктуры. Гэта зручна для ўсіх, і гэта вялікая перавага, якой не могуць пахваліцца многія іншыя падобныя БД.

Гнуткасць. ClickHouse не спыняецца на чымсьці адным, напрыклад, на Яндэкс.Метрыцы, а развіваецца і выкарыстоўваецца ва ўсё большай і большай колькасці розных праектаў і індустрыі. Яго можна пашыраць, дадаючы новыя магчымасці для рашэння новых задач. Напрыклад, лічыцца, што захоўваць логі ў БД - маветон, таму для гэтага прыдумалі. Elasticsearch. Але, дзякуючы гнуткасці ClickHouse, у ім таксама можна захоўваць логі, і часта гэта нават лепш, чым у Elasticsearch - у ClickHouse для гэтага патрабуецца ў 10 разоў менш жалеза.

Бясплатны Open Source. Не трэба ні завошта плаціць. Не трэба дамаўляцца аб дазволе паставіць сістэму сабе на наўтбук або сервер. Няма утоеных плацяжоў. Пры гэтым ніякая іншая Open Source тэхналогія баз дадзеных не можа канкураваць па хуткасці з ClickHouse. MySQL, MariaDB, Greenplum - усе яны значна павольней.

Супольнасць, драйв і весялосьць. У ClickHouse выдатная супольнасць: мітапы, чаты і Аляксей Мілавідаў, які нас усіх зараджае сваёй энергіяй і аптымізмам.

Пераезд на ClickHouse

Каб пераходзіць на ClickHouse з чагосьці патрэбныя ўсяго толькі тры рэчы:

• Разумець абмежаванні ClickHouse і для чаго ён не падыходзіць.
• Выкарыстоўваць перавагі тэхналогіі і яе наймацнейшыя бакі.
• Эксперыментаваць. Нават разумеючы як працуе ClickHouse, не заўсёды магчыма прадбачыць, калі ён будзе хутчэй, калі павольней, калі лепш, а калі горш. Таму спрабуйце.

Праблема пераезду

Ёсць толькі адно "але": калі пераязджаеце на ClickHouse з чагосьці іншага, то звычайна нешта ідзе ня так. Мы абвыклі да нейкіх практыкаў і рэчаў, якія працуюць у каханай БД. Напрыклад, любы чалавек, які працуе з SQL-базамі дадзеных, лічыць абавязковымі такі набор функцый:

• транзакцыі;
• канстрэйнты;
• кансістэнцыя;
• індэксы;
• UPDATE/DELETE;
• NULLs;
• мілісекунды;
• аўтаматычныя прывядзення тыпаў;
• множныя джойны;
• адвольныя партыцыі;
• сродкі кіравання кластарам.

Набор-то абавязковы, але тры гады таму ў ClickHouse не было ні адной з гэтых функцый! Цяпер з нерэалізаванага засталося менш за палову: транзакцыі, канстрэйнты, Consistency, мілісекунды і прывядзенне тыпаў.

І галоўнае - тое, што ў ClickHouse некаторыя стандартныя практыкі і падыходы не працуюць ці працуюць не так, як мы прывыклі. Усё, што з'яўляецца ў ClickHouse, адпавядае «ClickHouse way», г.зн. функцыі адрозніваюцца ад іншых БД. Напрыклад:

• Індэксы не выбіраюць, а прапускаюць.
• UPDATE/DELETE ня сінхронныя, а асінхронныя.
• Множныя джойны ёсць, але планавальніка запытаў няма. Як яны тады выконваюцца, увогуле не вельмі зразумела людзям са свету БД.

Сцэнары ClickHouse

У 1960 годзе амерыканскі матэматык венгерскага паходжання Wigner EP напісаў артыкул «Заўсёдная эфэктыўнасць матэматыкі ў навакольных умовах»(«Неспасціжная эфектыўнасць матэматыкі ў прыродазнаўчых навуках») аб тым, што навакольны свет чамусьці добра апісваецца матэматычнымі законамі. Матэматыка - абстрактная навука, а фізічныя законы, выяўленыя ў матэматычнай форме не трывіяльныя, і Wigner EP падкрэсліў, што гэта вельмі дзіўна.

З майго пункту гледжання, ClickHouse - такое ж дзівацтва. Перафармулюючы Вигнера, можна сказаць так: дзіўная неспасціжная эфектыўнасць ClickHouse у самых разнастайных аналітычных прыкладаннях!

Напрыклад, возьмем Real-Time Data Warehouse, у які дадзеныя грузяцца практычна бесперапынна. Мы жадаем атрымліваць ад яго запыты з секунднай затрымкай. Калі ласка – выкарыстоўваем ClickHouse, таму што для гэтага сцэнара ён і быў распрацаваны. ClickHouse менавіта так і выкарыстоўваецца не толькі ў вэб, але і ў маркетынгавай і фінансавай аналітыцы, AdTech, а таксама ў Fraud detection. У Real-time Data Warehouse выкарыстоўваецца складаная структураваная схема тыпу "зорка" ці "сняжынка", шмат табліц з РЭГІСТРАЦЫЯ (часам множнымі), а дадзеныя звычайна захоўваюцца і мяняюцца ў нейкіх сістэмах.

Возьмем іншы сцэнар - Часовы шэраг: маніторынг прылад, сетак, статыстыка выкарыстання, інтэрнет рэчаў. Тут мы сустракаемся з упарадкаванымі па часе дастаткова простымі падзеямі. ClickHouse для гэтага не быў першапачаткова распрацаваны, але добра сябе паказаў, таму буйныя кампаніі выкарыстоўваюць ClickHouse як сховішча для маніторынгавай інфармацыі. Каб вывучыць, ці падыходзіць ClickHouse для time-series, мы зрабілі бенчмарк на аснове падыходу і выніках InfluxDB и Часовая шкалаDB - спецыялізаваных time-series баз дадзеных. Аказалася, Што ClickHouse, нават без аптымізацыі пад такія задачы, выйграе і на чужым полі:

В time-series звычайна выкарыстоўваецца вузкая табліца - некалькі маленькіх калонак. З маніторынгу можа прыходзіць вельмі шмат дадзеных, – мільёны запісаў у секунду, – і звычайна яны паступаюць маленькімі ўстаўкамі (рэальнага часу стрымінгам). Таму патрэбен іншы сцэнар устаўкі, а самі запыты - са сваёй некаторай спецыфікай.

кіраванне Уваход. Збор логаў у БД - гэта звычайна дрэнна, але ў ClickHouse гэта можна рабіць з некаторымі каментарамі, як апісана вышэй. Многія кампаніі выкарыстоўваюць ClickHouse менавіта для гэтага. У гэтым выпадку выкарыстоўваецца плоская шырокая табліца, дзе мы захоўваем логі цалкам (напрыклад, у выглядзе JSON), альбо наразаем на часткі. Дадзеныя загружаюцца звычайна вялікімі батчамі (файламі), а шукаем па якім-небудзь полі.

Для кожнай з гэтых функцый звычайна выкарыстоўваюцца спецыялізаваныя БД. ClickHouse адзін можа рабіць гэта ўсё і настолькі добра, што абганяе іх па прадукцыйнасці. Давайце зараз падрабязна разгледзім time-series сцэнар, і як правільна "рыхтаваць" ClickHouse пад гэты сцэнар.

Time-Series

У сапраўдны момант гэта асноўны сцэнар, для якога ClickHouse лічыцца стандартным рашэннем. Часовыя шэрагі - Гэта набор спарадкаваных у часе падзей, якія прадстаўляюць змены нейкага працэсу ў часе. Напрыклад, гэта можа быць частата сэрцабіццяў за дзень ці колькасць працэсаў у сістэме. Усё, што дае часовыя цікі з нейкімі вымярэннямі - гэта time-series:

Больш за ўсё такога кшталту падзей прыходзіць з маніторынгу. Гэта можа быць не толькі маніторынг вэба, але і рэальных прылад: аўтамабіляў, прамысловых сістэм, IoT, вытворчасцей або беспілотных таксі, у багажнік якіх Яндэкс ужо зараз кладзе ClickHouse-сервер.

Напрыклад, ёсць кампаніі, якія збіраюць дадзеныя з судоў. Кожныя некалькі секунд датчыкі з кантэйнеравоза адпраўляюць сотні розных вымярэнняў. Інжынеры іх вывучаюць, будуюць мадэлі і спрабуюць зразумець, наколькі эфектыўна выкарыстоўваецца судна, таму што кантэйнеравоз не павінен прастойваць ні секунды. Любы просты - гэта страта грошай, таму важна спрагназаваць маршрут так, каб стаянкі былі мінімальнымі.

Цяпер назіраецца рост спецыялізаваных БД, якія вымяраюць time-series. На сайце БД-рухавікі нейкім чынам ранжыруюцца розныя базы дадзеных, і іх можна паглядзець па тыпах:

Самы хуткарослы тып - time-series. Таксама растуць графавыя БД, але time-series растуць хутчэй за апошнія некалькі гадоў. Тыповыя прадстаўнікі БД гэтага сямейства - гэта InfluxDB, Праметэй, KDB, Часовая шкалаDB (пабудаваная на PostgreSQL), рашэнні ад амазонка. ClickHouse тут таксама можа быць скарыстаны, і ён выкарыстоўваецца. Прывяду некалькі публічных прыкладаў.

Адзін з піянераў - кампанія CloudFlare (CDN-правайдэр). Яны маніторыць свой CDN праз ClickHouse (DNS-запыты, HTTP-запыты) з велізарнай нагрузкай - 6 мільёнаў падзей у секунду. Усё ідзе праз Кафка, адпраўляецца ў ClickHouse, Які дае магчымасць у рэальным часе бачыць дашборды падзей у сістэме.

Comcast - Адзін з лідэраў тэлекамунікацый у ЗША: інтэрнэт, лічбавае тэлебачанне, тэлефанія. Яны стварылі аналагічную сістэму кіравання CDN у рамках Open Source праекта Apache Traffic Control для працы са сваімі вялізнымі дадзенымі. ClickHouse выкарыстоўваецца як бэкэнд для аналітыкі.

Перкона ўбудавалі ClickHouse унутр свайго PMM, Каб захоўваць маніторынг розных MySQL.

Спецыфічныя патрабаванні

Да time-series баз даных ёсць свае спецыфічныя патрабаванні.

• Хуткая ўстаўка з многіх агентаў. Мы павінны вельмі хутка ўставіць дадзеныя з многіх патокаў. ClickHouse добра гэта робіць, таму што ў яго ўсе ўстаўкі не блакавальныя. Любы INSERT - гэта новы файл на дыску, а маленькія ўстаўкі можна буферызаваць тым ці іншым спосабам. У ClickHouse лепш устаўляць дадзеныя вялікімі пакетамі, а не па адным радку.
• Гнуткая схема. У time-series мы звычайна не ведаем структуру даных да канца. Можна пабудаваць сістэму маніторынгу для канкрэтнага дадатку, але тады яе цяжка выкарыстоўваць для іншага прыкладання. Для гэтага патрэбна больш гнуткая схема. ClickHouse, дазваляе гэта зрабіць, нават нягледзячы на ​​тое, што гэта строга тыпізаваная база.
• Эфектыўнае захоўванне і "забыванне" дадзеных. Звычайна ў time-series гіганцкі аб'ём дадзеных, таму іх трэба захоўваць максімальна эфэктыўна. Напрыклад, у InfluxDB добрая кампрэсія - гэта яго асноўная фішка. Але акрамя захоўвання, трэба яшчэ ўмець і "забываць" старыя дадзеныя і рабіць які-небудзь паніжэнне дыскрэтызацыі - аўтаматычны падлік агрэгатаў.
• Хуткія запыты агрэгаваных дадзеных. Часам цікава паглядзець апошнія 5 хвілін з дакладнасцю да мілісекунд, але на месячных дадзеных хвілінная або секундная гранулярнасць можа быць не патрэбна - дастаткова агульнай статыстыкі. Падтрымка такога роду неабходна, інакш запыт за 3 месяцы будзе выконвацца вельмі доўга нават у ClickHouse.
• Запыты тыпу «last point, as of». Гэта тыповыя для time-series запыты: глядзім апошняе вымярэнне або стан сістэмы ў момант часу t. Для БД гэта не вельмі прыемныя запыты, але іх таксама трэба ўмець выконваць.
• "Склейванне" часовых шэрагаў. Часовыя шэрагі - Гэта часовы шэраг. Калі ёсць два часовыя шэрагі, то іх часта трэба злучаць і карэляваць. Не на ўсіх БД гэта зручна рабіць, асабліва, з невыраўнаванымі часавымі шэрагамі: тут - адны часовыя засечкі, там - іншыя. Можна лічыць сярэднія, але раптам тамака ўсё роўна будзе дзірка, таму незразумела.

Давайце паглядзім, як гэтыя патрабаванні выконваюцца ў ClickHouse.

схема

В ClickHouse схему для time-series можна зрабіць рознымі спосабамі, у залежнасці ад ступені рэгулярнасці дадзеных. Можна пабудаваць сістэму на рэгулярных дадзеных, калі мы ведаем усе метрыкі загадзя. Напрыклад, так зрабіў CloudFlare з маніторынгам CDN - Гэта добра аптымізаваная сістэма. Можна пабудаваць больш агульную сістэму, якая маніторыць усю інфраструктуру, розныя сервісы. У выпадку нерэгулярных дадзеных, мы не ведаем загадзя, што маніторым - і, напэўна, гэта найбольш агульны выпадак.

Рэгулярныя дадзеныя. Калонкі. Схема простая - калонкі з патрэбнымі тыпамі:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Гэта звычайная табліца, якая маніторыць нейкую актыўнасць па загрузцы сістэмы (карыстальнік, сістэма, халастым ходу, прыемна). Проста і зручна, але не гнутка. Калі жадаем больш гнуткую схему, то можна выкарыстоўваць масівы.

Нерэгулярныя дадзеныя. Масівы:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Структура Укладзеная - Гэта два масіва: metrics.name и metrics.value. Тут можна захоўваць такія адвольныя маніторынгавыя дадзеныя, як масіў назоваў і масіў вымярэнняў пры кожнай падзеі. Для далейшай аптымізацыі замест адной такой структуры можна зрабіць некалькі. Напрыклад, адну - для плаваць-значэнне, іншую - для INT-значэнне, таму што INT хочацца захоўваць больш эфектыўна.

Але да такой структуры больш складана звяртацца. Прыйдзецца выкарыстоўваць адмысловую канструкцыю, праз адмысловыя функцыі выцягваць значэнні спачатку азначніка, а потым масіва:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Але гэта ўсё роўна працуе дастаткова хутка. Іншы спосаб захоўвання нерэгулярных дадзеных - па радках.

Нерэгулярныя дадзеныя. Радкі. У гэтым традыцыйным спосабе без масіваў захоўваюцца адразу назовы і значэнні. Калі з адной прылады прыходзіць адразу 5 000 вымярэнняў - генеруецца 5 000 радкоў у БД:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

ClickHouse з гэтым спраўляецца - у яго ёсць спецыяльныя пашырэнні ClickHouse SQL. напрыклад, maxIf - спецыяльная функцыя, якая лічыць максімум па метрыцы пры выкананні нейкай умовы. Можна ў адным запыце напісаць некалькі такіх выразаў і адразу палічыць значэнне для некалькіх метрык.

Параўнальны тры падыходы:

Дэталі

Тут я дадаў "Памер дадзеных на дыску" для некаторага тэставага набору дадзеных. У выпадку з калонкамі ў нас самы маленькі памер дадзеных: максімальны сціск, максімальная хуткасць запытаў, але мы плацім тым, што павінны ўсё адразу зафіксаваць.

У выпадку з масівамі ўсё крыху горш. Дадзеныя ўсё роўна добра сціскаюцца, і можна захоўваць нерэгулярную схему. Але ClickHouse - калоначная база дадзеных, а калі мы пачынаем захоўваць усё ў масіве, то яна ператвараецца ў радковую, і мы плацім за гнуткасць эфектыўнасцю. На любую аперацыю прыйдзецца прачытаць увесь масіў у памяць, пасля гэтага знайсці ў ім патрэбны элемент - а калі масіў расце, то хуткасць дэградуе.

У адной з кампаній, якая выкарыстоўвае такі падыход (напрыклад, Uber), масівы наразаюцца на кавалачкі з 128 элементаў. Дадзеныя некалькіх тысяч метрык аб'ёмам у 200 ТБ дадзеных/у дзень захоўваюцца не ў адным масіве, а ў з 10 ці 30 масівах са спецыяльнай логікай для захоўвання.

Максімальна просты падыход - з радкамі. Але дадзеныя дрэнна сціскаюцца, памер табліцы атрымліваецца вялікай, ды яшчэ калі запыты ідуць па некалькіх метрыках, то ClickHouse працуе неаптымальна.

Гібрыдная схема

Выкажам здагадку, што мы абралі схему з масівам. Але калі мы ведаем, што большасць нашых дашбордаў паказваюць толькі метрыкі user і system, мы можам дадаткова з масіва на ўзроўні табліцы матэрыялізаваць гэтыя метрыкі ў калонкі такім чынам:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Пры ўстаўцы ClickHouse аўтаматычна іх палічыць. Так можна сумясціць прыемнае з карысным: схема гнуткая і агульная, але самыя часта выкарыстоўваюцца калонкі мы выцягнулі. Заўважу, што гэта не запатрабавала мяняць устаўку і ETL, Які працягвае ўстаўляць у табліцу масівы. Мы проста зрабілі ALTER TABLE, дадалі пару калонак і атрымалася гібрыдная і хутчэйшая схема, якой можна адразу пачынаць карыстацца.

Кодэкі і кампрэсія

Для time-series важна, наколькі добра вы пакуеце дадзеныя, таму што масіў інфармацыі можа быць вельмі вялікі. У ClickHouse есць набор сродкаў для дасягнення эфекту кампрэсіі 1:10, 1:20, а часам і больш. Гэта значыць, што неўпакаваныя дадзеныя аб'ёмам 1 ТБ на дыску займаюць 50-100 ГБ. Меншы памер - гэта добра, дадзеныя хутчэй можна прачытаць і апрацаваць.

Для дасягнення высокага ўзроўню кампрэсіі, ClickHouse падтрымлівае наступныя кодэкі:

Прыклад табліцы:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Тут мы вызначаем кодэк DoubleDelta у адным выпадку, у другім - Гарыла, і абавязкова дадаем яшчэ LZ4 кампрэсію. У выніку памер дадзеных на дыску моцна памяншаецца:

Тут паказана, колькі месца займаюць адны і тыя ж дадзеныя, але пры выкарыстанні розных кодэкаў і кампрэсій:

• у GZIP'аваным файле на дыску;
• у ClickHouse без кодэкаў, але з ZSTD-кампрэсіяй;
• у ClickHouse c кодэкамі і кампрэсіяй LZ4 і ZSTD.

Відаць, што табліцы з кодэкамі займаюць значна менш месцы.

Памер мае значэнне

Не менш важна выбраць правільны тып дадзеных:

Ва ўсіх прыкладах вышэй я выкарыстоўваў Паплавок64. Але калі б мы выбралі Паплавок32, то гэта было б нават лепш. Гэта добра прадэманстравалі хлопцы з Перконы ў артыкуле па спасылцы вышэй. Важна выкарыстоўваць максімальна кампактны тып, які падыходзіць пад задачу: нават у меншай ступені для памеру на дыску, чым для хуткасці запытаў. ClickHouse вельмі да гэтага адчувальны.

Калі вы можаце выкарыстоўваць int32 замест int64, то чакайце амаль двухразовае павелічэнне прадукцыйнасці. Дадзеныя займаюць менш памяці, і ўся "арыфметыка" працуе значна хутчэй. ClickHouse ўнутры сябе - вельмі строга тыпізаваная сістэма, ён максімальна выкарыстоўвае ўсе магчымасці, якія падаюць сучасныя сістэмы.

Агрэгацыя і Матэрыялізаваныя погляды

Агрэгацыя і матэрыялізаваныя ўяўленні дазваляюць зрабіць агрэгаты на розныя выпадкі жыцця:

Напрыклад, у вас могуць быць не агрэгаваныя зыходныя дадзеныя, і на іх можна навесіць розныя матэрыялізаваныя паданні з аўтаматычным сумаваннем праз адмысловы рухавічок SummingMergeTree (SMT). SMT - Гэта спецыяльная агрэгуе структура дадзеных, якая лічыць агрэгаты аўтаматычна. У базу дадзеных устаўляюцца волкія дадзеныя, яны аўтаматычна агрэгуюцца, і адразу па іх можна выкарыстоўваць дашборды.

TTL - «забываем» старыя дадзеныя

Як "забываць" дадзеныя, якія больш не патрэбныя? ClickHouse умее гэта. Пры стварэнні табліц можна пазначыць TTL выразы: напрыклад, што хвілінныя дадзеныя захоўваем адзін дзень, дзённыя - 30 дзён, а тыднёвыя або месячныя не чапаем ніколі:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-tier - Падзяляем дадзеныя па дысках

Развіваючы гэтую ідэю, дадзеныя можна захоўваць у ClickHouse у розных месцах. Выкажам здагадку, гарачыя дадзеныя за апошні тыдзень жадаем захоўваць на вельмі хуткім лакальным. SSD, а больш гістарычныя дадзеныя складаем у іншае месца. У ClickHouse зараз гэта магчыма:

Можна сканфігураваць палітыку захоўвання (storage policy) так што ClickHouse будзе аўтаматычна перакладаць дадзеныя па дасягненні некаторых умоў у іншае сховішча.

Але і гэта яшчэ не ўсё. На ўзроўні канкрэтнай табліцы можна вызначыць правілы, калі менавіта па часе дадзеныя пераходзяць на халоднае захоўванне. Напрыклад, 7 дзён дадзеныя ляжаць на вельмі хуткай кружэлцы, а ўсё, што старэй, пераносіцца на павольны. Гэта добра тым, што дазваляе сістэму трымаць на максімальнай прадукцыйнасці, пры гэтым кантралюючы выдаткі і не марнуючы сродкі на лядоўні дадзеныя:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Унікальныя магчымасці ClickHouse

Амаль ва ўсім у ClickHouse ёсць такія «разыначкі», але яны нівеліруюцца эксклюзівам - тым, чаго няма ў іншых БД. Напрыклад, вось некаторыя з унікальных функцый ClickHouse:

• Масівы. У ClickHouse вельмі добрая падтрымка для масіваў, а таксама магчымасць выконваць на іх складаныя вылічэнні.
• Агрэгавальныя структуры дадзеных. Гэта адна з «кілер-фіч» ClickHouse. Нягледзячы на ​​тое, што хлопцы з Яндэкса кажуць, што мы не хочам агрэгаваць дадзеныя, усе агрэгуюць у ClickHouse, таму што гэта хутка і зручна.
• Матэрыялізаваныя ўяўленні. Разам з якія агрэгуюць структурамі дадзеных матэрыялізаваныя ўяўленні дазваляюць рабіць зручную рэальнага часу агрэгацыю.
• ClickHouse SQL. Гэта пашырэнне мовы SQL з некаторымі дадатковымі і эксклюзіўнымі фічамі, якія ёсць толькі ў ClickHouse. Раней гэта было як бы з аднаго боку пашырэнне, а з другога боку - недахоп. Цяпер амаль усе недахопы ў параўнанні з SQL 92 мы прыбралі, зараз гэта толькі пашырэнне.
• Лямбда-выразы. Ці ёсць яны яшчэ ў якой-небудзь базе даных?
• ML-падтрымка. Гэта ёсць у розных БД, у нейкіх лепшых, у нейкіх горш.
• Адкрыты код. Мы можам пашыраць ClickHouse разам. Зараз у ClickHouse каля 500 кантрыб'ютараў, і гэты лік пастаянна расце.

Хітрыя запыты

В ClickHouse ёсць шмат розных спосабаў зрабіць адно і тое ж. Напрыклад, можна трыма рознымі спосабамі вярнуць апошняе значэнне з табліцы для CPU (ёсць яшчэ і чацвёрты, але ён яшчэ экзатычныя).

Першы паказвае, як зручна рабіць у ClickHouse запыты, калі вы хочаце правяраць, што картэж змяшчаецца ў подзапросе. Гэта тое, чаго мне асабіста вельмі не хапала ў іншых БД. Калі я хачу нешта параўнаць з подзапросом, то ў іншых БД з ім можна параўноўваць толькі скаляр, а для некалькіх калонак трэба пісаць РЭГІСТРАЦЫЯ. У ClickHouse можна выкарыстоўваць tuple:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Другі спосаб робіць тое ж самае, але выкарыстоўвае агрэгатную функцыю argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В ClickHouse ёсць некалькі дзясяткаў агрэгатных функцый, а калі выкарыстоўваць камбінатары, то па законах камбінаторыкі іх атрымаецца каля тысячы. ArgMax - адна з функцый, якая лічыць максімальнае значэнне: запыт вяртае значэнне usage_user, на якім дасягаецца максімальнае значэнне створана_на:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN - «склейванне» шэрагаў з розным часам. Гэта ўнікальная функцыя для баз дадзеных, якая ёсць яшчэ толькі ў kdb+. Калі ёсць два часовых шэрагу з розным часам, ASOF JOIN дазваляе іх зрушыць і склеіць у адным запыце. Для кожнага значэння ў адным часовым шэрагу знаходзіцца бліжэйшае значэнне ў іншым, і яны вяртаюцца на адной радкоў:

аналітычныя функцыі

У стандарце SQL-2003 можна пісаць так:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В ClickHouse так нельга - ён не падтрымлівае стандарт SQL-2003 і, мусіць, ніколі не будзе гэта рабіць. Замест гэтага ў ClickHouse прынята пісаць так:

Я абяцаў лямбды - вось яны!

Гэта аналаг аналітычнага запыту ў стандарце SQL-2003: ён лічыць розніцу паміж двума timestamp, duration, парадкавы нумар - усё, што звычайна мы лічым аналітычнымі функцыямі. У ClickHouse мы іх лічым праз масівы: спачатку згортваем дадзеныя ў масіў, пасля гэтага на масіве які робіцца ўсё, што жадаем, а потым разгортваем зваротна. Гэта не вельмі зручна, патрабуе кахання да функцыянальнага праграмавання, прынамсі, але гэта вельмі гнутка.

Спецыяльныя функцыі

Акрамя таго ў ClickHouse шмат спецыялізаваных функцый. Напрыклад, як вызначыць, колькі сесій праходзіць адначасова? Тыповая задача для маніторынгу - вызначыць максімальную загрузку адным запытам. У ClickHouse ёсць спецыяльная функцыя для гэтай мэты:

Наогул, для шматлікіх мэт у ClickHouse ёсць адмысловыя функцыі:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Гэта не поўны спіс функцый, усяго іх 500-600. Хінт: усе функцыі ў ClickHouse ёсць у сістэмнай табліцы (не ўсе дакументаваны, але ўсё цікавыя):

select * from system.functions order by name

ClickHouse сам у сабе захоўвае шмат інфармацыі пра сябе, у тым ліку log tables, query_log, лог трасіроўкі, лог аперацыі з блокамі дадзеных (part_log), лог метрык, і сістэмны лог, які ён звычайна піша на дыск. Лог метрык - гэта time-series в ClickHouse на самай ClickHouse: БД сама для сябе можа гуляць ролю time-series баз дадзеных, такім чынам "пажыраючы" самога сябе.

Гэта таксама ўнікальная рэч - раз мы добра робім працу для time-series, чаму не можам самі ў сабе захоўваць усё, што трэба? Нам не патрэбен Праметэй, мы захоўваем усё ў сабе. Падключылі Графана і самі сябе маніторым. Аднак, калі ClickHouse упадзе, то мы не ўбачым, - чаму, - таму звычайна так не робяць.

Вялікі кластар ці шмат маленькіх ClickHouse

Што лепш - адзін вялікі кластар або шмат маленькіх ClickHouse? Традыцыйны падыход да DWH - Гэта вялікі кластар, у якім вылучаюцца схемы пад кожнае прыкладанне. Мы прыйшлі да адміністратара БД – дайце нам схему, і нам яе выдалі:

В ClickHouse можна зрабіць гэта па-іншаму. Можна кожнаму з дадаткам зрабіць свой уласны ClickHouse:

Нам больш не патрэбен вялікі монструозны DWH і нязгодлівыя адміны. Мы можам кожнаму з дадаткам выдаць свой уласны ClickHouse, і распрацоўшчык можа гэта зрабіць сам, бо ClickHouse вельмі проста усталёўваецца і не патрабуе складанага адміністравання:

Але калі ў нас шмат ClickHouse, І трэба часта яго ставіць, то хочацца гэты працэс аўтаматызаваць. Для гэтага можна, напрыклад, выкарыстоўваем Kubernetes и Clickhouse-аператар. У Kubernetes ClickHouse можна паставіць "па пстрычцы": я магу націснуць кнопку, запусціць маніфест і база гатова. Можна адразу ж стварыць схему, пачаць туды грузіць метрыкі, і праз 5 хвілін у мяне ўжо готаў дашборд Графана. Настолькі ўсё проста!

Што ў выніку?

Такім чынам, ClickHouse - Гэта:

• Хутка. Гэта ўсім вядома.
• проста. Крыху спрэчна, але я лічу, што цяжка ў вучэнні, лёгка ў баі. Калі зразумець, як ClickHouse працуе, далей усё вельмі проста.
• Універсальна. Ён падыходзіць для розных сцэнарыяў: DWH, Time Series, Log Storage. Але гэта не OLTP база дадзеных, таму не спрабуйце зрабіць там кароткія ўстаўкі і чытанні.
• Цікава. Мусіць, той, хто працуе з ClickHouse, перажыў шмат цікавых хвілін у добрым і дрэнным сэнсе. Напрыклад, выйшаў новы рэліз, усё перастала працаваць. Або калі вы біліся над задачай два дні, але пасля пытання ў Тэлеграм-чаце задача вырашылася за дзве хвіліны. Або як на канферэнцыі на дакладзе Лёшы Мілавідава скрыншот з ClickHouse зламаў трансляцыю Высокая нагрузка++. Такога роду рэчы адбываюцца пастаянна і робяць наша жыццё з ClickHouse яркай і цікавай!

Прэзетацыю можна паглядзець тут.

Доўгачаканая сустрэча распрацоўшчыкаў высоканагружаных сістэм на Высокая нагрузка++ адбудзецца 9 і 10 лістапада ў Сколкава. Нарэшце гэта будзе афлайн-канферэнцыя (хоць і з захаваннем усіх мер засцярогі), бо энергію HighLoad++ немагчыма спакаваць у анлайн.

Для канферэнцыі мы знаходзім і паказваем вам кейсы аб максімальных магчымасцях тэхналогій: HighLoad++ быў, ёсць і будзе адзіным месцам, дзе можна за два дні даведацца, як уладкованыя Facebook, Яндэкс, Укантакце, Google і Amazon.

Праводзячы нашы сустрэчы без перапынку з 2007 года, сёлета мы сустрэнемся 14-ы раз. За гэты час канферэнцыя вырасла ў 10 разоў, летась ключавая падзея галіны сабрала 3339 удзельнікаў, 165 спікераў дакладаў і мітапаў, а адначасова ішло 16 трэкаў.
У мінулым годзе для вас было 20 аўтобусаў, 5280 літраў гарбаты і кава, 1650 літраў морсаў і 10200 бутэлечак вады. А яшчэ 2640 кілаграмаў ежы, 16 000 талерак і 25 000 шкляначак. Дарэчы, на грошы, атрыманыя ад перапрацаванай паперы, мы пасадзілі 100 саджанцаў дуба 🙂

Білеты купіць можна тут, атрымаць навіны пра канферэнцыю тут, а пагаварыць - ва ўсіх сацсетках: Тэлеграма, Facebook, Vkontakte и Twitter.

Крыніца: habr.com