Преместване в ClickHouse: 3 години по-късно

Преди три години Виктор Търнавски и Алексей Миловидов от Yandex на сцената HighLoad ++ каза, кой ClickHouse е добър и как не забавя. И на следващия етап беше Александър Зайцев с доклад относно преместването в Щракнете върху Къща от друга аналитична СУБД и със заключение, че Щракнете върху Къща, разбира се, добре, но не много удобно. Когато през 2016 г. компанията LifeStreet, където Александър работеше тогава, превеждаше многопетабайтова аналитична система в Щракнете върху Къща, това беше завладяващ "път от жълти тухли", пълен с непознати опасности - Щракнете върху Къща тогава изглеждаше като минно поле.

Три години по-късно Щракнете върху Къща стана много по-добре - през това време Александър основава компанията Altinity, която не само помага да се премести в Щракнете върху Къща десетки проекти, но и подобрява самия продукт заедно с колегите от Yandex. Сега Щракнете върху Къща все още не е безгрижна разходка, но вече не е минно поле.

Александър се занимава с разпределени системи от 2003 г., като разработва големи проекти MySQL, Oracle и Вертика. Най-накрая HighLoad ++ 2019 Александър, един от пионерите в използването Щракнете върху Къща, каза какво представлява сега тази СУБД. Ще научим за основните характеристики Щракнете върху Къща: как се различава от другите системи и в какви случаи е по-ефективно да се използва. Използвайки примери, нека разгледаме свежи и доказани в проекта практики за изграждане на системи, базирани на Щракнете върху Къща.

Ретроспекция: какво се случи преди 3 години

Преди три години прехвърлихме фирмата LifeStreet на Щракнете върху Къща от различна база данни за анализ и миграцията на анализа на рекламната мрежа изглеждаше така:

• Юни 2016 г. В Отворен код се появи Щракнете върху Къща и започна нашия проект;
• На август. Доказване на концепцията: голяма рекламна мрежа, инфраструктура и 200-300 терабайта данни;
• октомври. Първи производствени данни;
• декември. Пълно натоварване на продукта - 10-50 милиарда събития на ден.
• Юни 2017 г. Успешна миграция на потребители към Щракнете върху Къща, 2,5 петабайта данни в клъстер от 60 сървъра.

С напредването на миграцията разбирането нараства това Щракнете върху Къща е добра система, с която е приятно да се работи, но това е вътрешен проект на Yandex. Следователно има нюанси: Yandex първо ще се занимава със собствените си вътрешни клиенти и едва след това с общността и нуждите на външните потребители, докато ClickHouse не е достигнал корпоративното ниво в много функционални области тогава. Така че през март 2017 г. основахме Altinity, за да правим Щракнете върху Къща още по-бързо и по-удобно не само за Yandex, но и за други потребители. И сега ние:

• Ние обучаваме и помагаме за изграждането на решения, базирани на Щракнете върху Къща така че клиентите да не запълват неравности и така че решението в крайна сметка да работи;
• Осигуряваме 24/7 поддръжка Щракнете върху Къща- инсталации;
• Разработваме собствени екосистемни проекти;
• Активно се ангажирам със себе си Щракнете върху Къща, отговаряйки на заявки от потребители, които искат да видят определени функции.

И разбира се, помагаме с преместването в Щракнете върху Къща с MySQL, Вертика, Оракул, Зелена слива, Redshift и други системи. Участвахме в голямо разнообразие от премествания и всички те бяха успешни.

Защо дори да се преместите в Щракнете върху Къща

Не забавя! Това е основната причина. Щракнете върху Къща - много бърза база данни за различни сценарии:

Произволни цитати от хора, които работят с Щракнете върху Къща.

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

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

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

Безплатно Open Source. Не е нужно да плащате за нищо. Няма нужда да договаряте разрешение за поставяне на системата на вашия лаптоп или сървър. Няма скрити такси. В същото време никоя друга технология за бази данни с отворен код не може да се конкурира по скорост Щракнете върху Къща. MySQL, MariaDB, Greenplum - всички те са много по-бавни.

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

Преместване в ClickHouse

За да преминете към Щракнете върху Къща с нещо, имате нужда само от три неща:

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

Проблемът с преместването

Има само едно "но": ако се преместите в Щракнете върху Къща с нещо друго нещо обикновено се обърква. Свикнали сме с някои практики и неща, които работят в любимата ни база данни. Например всеки, който работи с SQL-бази данни, счита следния набор от функции за задължителен:

• сделки;
• ограничения;
• последователност;
• индекси;
• АКТУАЛИЗИРАНЕ/ИЗТРИВАНЕ;
• NULLs;
• милисекунди;
• автоматични преобразувания на типове;
• множество присъединявания;
• произволни прегради;
• инструменти за управление на клъстери.

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

И основното е, че в Щракнете върху Къща някои стандартни практики и подходи не работят или не работят по начина, по който сме свикнали. Всичко, което се появява в Щракнете върху Къща, съответства на "щракнете къща начин”, т.е. функциите са различни от другите DB. Например:

• Индексите не се избират, а се пропускат.
• АКТУАЛИЗИРАНЕ/ИЗТРИВАНЕ не синхронен, а асинхронен.
• Има множество присъединявания, но няма планиране на заявки. Как след това се изпълняват, обикновено не е много ясно за хората от света на базите данни.

Сценарии на ClickHouse

През 1960 г. американски математик от унгарски произход WignerEP написа статияНеразумната ефективност на математиката в природните науки”(„Неразбираемата ефективност на математиката в естествените науки”), че светът около нас по някаква причина е добре описан от математически закони. Математиката е абстрактна наука и физическите закони, изразени в математическа форма, не са тривиални и WignerEP подчерта, че това е много странно.

От моя гледна точка на, Щракнете върху Къща - същата странност. За да преформулираме Wigner, можем да кажем следното: удивителна е невъобразимата ефективност Щракнете върху Къща в голямо разнообразие от аналитични приложения!

Например, нека вземем Хранилище за данни в реално време, в който данните се зареждат почти непрекъснато. Искаме да получаваме заявки от него със секунда закъснение. Моля използвайте Щракнете върху Къщазащото е проектирано за този сценарий. Щракнете върху Къща ето как се използва не само в мрежата, но и в маркетинга и финансовия анализ, AdTecч, както и в Откриване на измамин. IN Data Warehouse в реално време използва се сложна структурирана схема като "звезда" или "снежинка", много таблици с ПРИСЪЕДИНЕТЕ СЕ КЪМ (понякога няколко) и данните обикновено се съхраняват и променят в някои системи.

Да вземем друг сценарий - Времеви редове: устройства за наблюдение, мрежи, статистика за употреба, интернет на нещата. Тук се срещаме с доста прости събития, подредени във времето. Щракнете върху Къща първоначално не е разработен за това, но се е показал добре, така че големите компании го използват Щракнете върху Къща като хранилище за информация за наблюдение. Да видя дали става Щракнете върху Къща за времеви серии направихме бенчмарк въз основа на подхода и резултатите InfluxDB и Времева скалаDB — специализиран времеви редове бази данни. Оказа сеЧе Щракнете върху Къща, дори без оптимизация за такива задачи, също печели на чужд терен:

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

Управление Log. Събирането на регистрационни файлове в базата данни обикновено е лошо, но в Щракнете върху Къща това може да стане с някои коментари, както е описано по-горе. Много компании използват Щракнете върху Къща само за това. В този случай се използва плоска широка маса, където съхраняваме целите трупи (например във формата JSON), или нарязани на парчета. Данните обикновено се зареждат в големи партиди (файлове) и ние търсим някакво поле.

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

Времеви редове

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

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

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

Сега има нарастване на специализираните бази данни, които измерват времеви редове. На линия DB-двигатели по някакъв начин различни бази данни се класират и могат да се разглеждат по тип:

Най-бързо растящият вид времеви редовес. Графичните бази данни също растат, но времеви редоверастат по-бързо през последните няколко години. Типични представители на това семейство бази данни са InfluxDB, Прометей, KDB, Времева скалаDB (построен на PostgreSQL), решения от Амазонка. Щракнете върху Къща тук също може да се използва и се използва. Нека ви дам няколко публични примера.

Един от пионерите е компанията CloudFlare (CDNдоставчик). Те наблюдават своите CDN през Щракнете върху Къща (DNS- искания, HTTP-заявки) с огромно натоварване - 6 милиона събития в секунда. Всичко минава Кафка, отива Щракнете върху Къща, който дава възможност да виждате в реално време табла за събития в системата.

Comcast - един от лидерите в телекомуникациите в САЩ: Интернет, цифрова телевизия, телефония. Те създадоха подобна система за контрол CDN в рамките Open Source проект Контрол на трафика Apache да работят с техните огромни данни. Щракнете върху Къща използва се като бекенд за анализи.

Перкона вграден Щракнете върху Къща вътре във вашия PMMза да продължите да наблюдавате различни MySQL.

Специфични изисквания

Базите данни с времеви редове имат свои специфични изисквания.

• Бързо вмъкване от много агенти. Трябва да вмъкнем данни от много потоци много бързо. Щракнете върху Къща прави го добре, защото има всички неблокиращи вложки. Всякакви вмъкнете е нов файл на диска и малките вмъквания могат да бъдат буферирани по един или друг начин. IN Щракнете върху Къща по-добре е да вмъквате данни в големи партиди, а не един ред наведнъж.
• Гъвкава верига. В времеви редове обикновено не знаем напълно структурата на данните. Възможно е да се изгради система за мониторинг за конкретно приложение, но тогава е трудно да се използва за друго приложение. Това изисква по-гъвкава схема. Щракнете върху Къща, ви позволява да направите това, въпреки че е строго типизирана база.
• Ефективно съхранение и "забравяне" на данни. Обикновено в времеви редове огромно количество данни, така че те трябва да се съхраняват възможно най-ефективно. Например при InfluxDB добрата компресия е основната му характеристика. Но в допълнение към съхранението, вие също трябва да можете да „забравите“ стари данни и да направите някои намаляване на извадката — автоматично преброяване на агрегатите.
• Бързи заявки за обобщени данни. Понякога е интересно да се разгледат последните 5 минути с точност до милисекунди, но при месечните данни може да не е необходима подробност в минута или секунда - общата статистика е достатъчна. Поддръжка от този вид е необходима, в противен случай заявка за 3 месеца ще бъде изпълнена за много дълго време дори в Щракнете върху Къща.
• Заявки като "последна точка, считано от». Това са характерни за времеви редове заявки: погледнете последното измерване или състоянието на системата в даден момент t. За базата данни това не са много приятни заявки, но те също трябва да могат да се изпълняват.
• "залепване" на времеви редове. Времеви редове е времева серия. Ако има два времеви реда, тогава те често трябва да бъдат свързани и корелирани. Не е удобно да се прави това във всички бази данни, особено с неподравнени времеви редове: тук има едни времеви марки, има други. Можете да вземете предвид средната стойност, но изведнъж все още ще има дупка, така че не е ясно.

Нека да видим как се изпълняват тези изисквания Щракнете върху Къща.

Схемата

В Щракнете върху Къща схема за времеви редове може да се направи по различни начини, в зависимост от степента на редовност на данните. Възможно е да се изгради система върху редовни данни, когато знаем всички показатели предварително. Например, направих 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 и показатели.стойност. Тук можете да съхранявате такива произволни данни за наблюдение като масив от имена и масив от измервания за всяко събитие. За допълнителна оптимизация могат да бъдат направени няколко такива структури вместо една. Например един за поплавък-стойност, друг - за Int- в смисъл, защото Int Искам да съхранявам по-ефективно.

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

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

Но все още работи достатъчно бързо. Друг начин за съхраняване на нередовни данни е по редове.

Нередовни данни. струни. По този традиционен начин, без масиви, имената и стойностите се съхраняват наведнъж. Ако 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', ...)

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

Нека сравним три подхода:

Детали

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

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

В една от компаниите, които използват този подход (напр. Uber), масивите се нарязват на части от 128 елемента. Данните от няколко хиляди метрики с обем от 200 TB данни / ден не се съхраняват в един масив, а в 10 или 30 масива със специална логика за съхранение.

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

хибридна схема

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

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);

При залепване Щракнете върху Къща автоматично ще ги преброи. По този начин можете да комбинирате бизнеса с удоволствието: схемата е гъвкава и обща, но ние извадихме най-често използваните колони. Отбелязвам, че това не изисква смяна на вложката и ETL, който продължава да вмъква масиви в таблицата. Току-що го направихме ALTER TABLE, добави няколко високоговорителя и получи хибридна и по-бърза схема, която можете да започнете да използвате веднага.

Кодеци и компресия

За времеви редове важно е колко добре опаковате данните, защото масивът от информация може да бъде много голям. IN Щракнете върху Къща има набор от инструменти за постигане на ефекта на компресия 1:10, 1:20, а понякога и повече. Това означава, че 1 TB некомпресирани данни на диска заема 50-100 GB. По-малкият размер е добър, данните могат да се четат и обработват по-бързо.

За да постигнете високо ниво на компресия, Щракнете върху Къща поддържа следните кодеци:

Примерна таблица:

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 с LZ4 и ZSTD кодеци и компресия.

Вижда се, че таблиците с кодеци заемат много по-малко място.

Размерът има значение

Не по-малко важно выбрать правилен тип данни:

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

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

Агрегация и Материализирани възгледи

Агрегирането и материализираните изгледи ви позволяват да правите агрегати за различни случаи:

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

TTL - "забравете" стари данни

Как да "забравите" данни, които вече не са необходими? Щракнете върху Къща знае как да го направи. Когато създавате таблици, можете да посочите 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 */

много нива - разделяне на данни между дискове

Развивайки тази идея, данните могат да се съхраняват в Щракнете върху Къща на различни места. Да предположим, че искаме да съхраним горещи данни за последната седмица на много бърз локален SSDи добавяме още исторически данни на друго място. IN Щракнете върху Къща сега е възможно:

Можете да конфигурирате правилата за задържане (политика за съхранение) Така Щракнете върху Къща автоматично ще прехвърли данни в друго хранилище, когато са изпълнени определени условия.

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

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

Уникални функции Щракнете върху Къща

Почти всичко в Щракнете върху Къща има такива "акценти", но те се изравняват с изключителното - това, което го няма в други бази данни. Ето например някои от уникалните функции Щракнете върху Къща:

• масиви. В Щракнете върху Къща много добра поддръжка на масиви, както и възможност за извършване на сложни изчисления върху тях.
• Агрегиране на структури от данни. Това е една от "убийствените характеристики" Щракнете върху Къща. Въпреки факта, че момчетата от Yandex казват, че не искаме да агрегираме данни, всичко се агрегира в Щракнете върху Къщазащото е бързо и удобно.
• Материализирани изгледи. Заедно с агрегиращите структури от данни, материализираните изгледи ви позволяват да направите удобен в реално време агрегиране.
• ClickHouse SQL. Това е разширение за език SQL с някои допълнителни и изключителни функции, които са налични само в Щракнете върху Къща. Преди това беше, така да се каже, разширение от една страна и недостатък от друга. Сега почти всички недостатъци в сравнение с SQL 92 премахнахме го, сега е просто разширение.
• Lambda- изрази. Още ли са в някаква база данни?
• ML-поддържа. Това е в различни бази данни, някои са по-добри, други са по-лоши.
• Отворен код. Можем да се разширим Щракнете върху Къща заедно. Сега в Щракнете върху Къща около 500 сътрудници, като този брой непрекъснато нараства.

Трудни запитвания

В Щракнете върху Къща има много различни начини да направите едно и също нещо. Например, има три различни начина за връщане на последната стойност от таблица за процесор (има и четвърти, но е още по-екзотичен).

Първият показва колко удобно е да се направи в Щракнете върху Къща запитвания, когато искате да проверите това кортеж съдържащи се в подзаявката. Това е нещо, което на мен лично наистина ми липсваше в други бази данни. Ако искам да сравня нещо с подзаявка, тогава в други бази данни само скалар може да бъде сравнен с него и за няколко колони трябва да напиша ПРИСЪЕДИНЕТЕ СЕ КЪМ. В Щракнете върху Къща можете да използвате кортеж:

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 

В Щракнете върху Къща има няколко десетки агрегатни функции и ако използвате комбинатори, тогава според законите на комбинаториката получавате около хиляда от тях. ArgMax - една от функциите, които отчитат максималната стойност: заявката връща стойността usage_user, при което се достига максималната стойност created_at:

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

ASOF ПРИСЪЕДИНЕТЕ СЕ - "залепване" на редове с различно време. Това е уникална функция за бази данни и е достъпна само в kdb+. Ако има два времеви реда с различни времена, ASOF ПРИСЪЕДИНЕТЕ СЕ позволява разместването и залепването им с едно искане. За всяка стойност в една времева серия се намира най-близката стойност в друга и те се връщат на същия ред:

Аналитични функции

В стандарта 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;

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

Обещах ламбда - ето ги!

Това е аналог на аналитична заявка в стандарта SQL-2003: отчита разликата между две клеймо за време, продължителност, редни - всичко, което обикновено считаме за аналитични функции. IN Щракнете върху Къща ние ги броим чрез масиви: първо свиваме данните в масив, след това правим каквото си поискаме с масива и след това го разширяваме обратно. Не е много удобно, изисква най-малко любов към функционалното програмиране, но е много гъвкаво.

Специални функции

Освен това в Щракнете върху Къща множество специализирани функции. Например, как да определите колко сесии се изпълняват едновременно? Типична задача за наблюдение е да се определи максималното натоварване в една заявка. IN Щракнете върху Къща има специална функция за тази цел:

Като цяло ClickHouse има специални функции за много цели:

• runDifference, runningAccumulate, съсед;
• sumMap(ключ, стойност);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• С ПЪЛНЕЖ / С ВРЪЗКИ;
• проста линейна регресия, стохастична линейна регресия.

Това не е пълен списък с функции, има само 500-600 от тях. Съвет: всички функции в Щракнете върху Къща е в системната таблица (не всички са документирани, но всички са интересни):

select * from system.functions order by name

Щракнете върху Къща съхранява много информация за себе си, включително регистрационни таблици, query_log, дневник за проследяване, дневник на операции с блокове от данни (part_log), регистъра на показателите и системния регистър, който обикновено записва на диска. Дневникът на показателите е времеви редове в Щракнете върху Къща всъщност Щракнете върху Къща: самата база данни може да играе роля времеви редове бази данни, като по този начин се „поглъща“.

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

Голям клъстер или много малки Щракнете върху Къща

Какво е по-добре - един голям клъстер или много малки ClickHouses? Традиционният подход към DWH е голям клъстер, в който се разпределят схеми за всяко приложение. Стигнахме до администратора на базата данни - дайте ни схема и ни беше дадена:

В Щракнете върху Къща можете да го направите по различен начин. Всяко приложение може ли да направи своето Щракнете върху Къща:

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

Но ако имаме много Щракнете върху Къща, и трябва да го задавате често, тогава искате да автоматизирате този процес. За това можем да използваме например Kubernetes и clickhouse-оператор. IN Kubernetes ClickHouse можете да поставите "on click": мога да щракна върху бутон, да стартирам манифеста и базата данни е готова. Веднага можете да създадете схема, да започнете да зареждате метрики там и след 5 минути имам готово табло Графана. Толкова е просто!

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

По този начин, Щракнете върху Къща - това е:

• бързо. Всеки знае това.
• просто. Малко спорно, но мисля, че е трудно за научаване, лесно за битка. Ако разбирате как Щракнете върху Къща работи, всичко е много просто.
• Универсално. Подходящ е за различни сценарии: DWH, времеви редове, съхранение на регистрационни файлове. Но не е така OLTP база данни, така че не се опитвайте да правите кратки вмъквания и четения там.
• Интересното. Вероятно този, който работи с Щракнете върху Къща, изживя много интересни минути в добър и лош смисъл. Например, излезе ново издание, всичко спря да работи. Или когато сте се борили два дни със задача, но след въпрос в чата на Telegram задачата е решена за две минути. Или, както на конференцията при доклада на Леша Миловидов, екранна снимка от Щракнете върху Къща прекъсна предаването HighLoad ++. Такива неща се случват през цялото време и съставляват живота ни Щракнете върху Къща ярки и интересни!

Презентацията може да се види тук.

Дългоочакваната среща на разработчиците на системи с високо натоварване в HighLoad ++ ще се проведе на 9 и 10 ноември в Сколково. И накрая, това ще бъде офлайн конференция (макар и с всички предпазни мерки), тъй като енергията на HighLoad++ не може да бъде пакетирана онлайн.

За конференцията намираме и ви показваме случаи за максималните възможности на технологията: HighLoad ++ беше, е и ще бъде единственото място, където можете да научите за два дни как работят Facebook, Yandex, VKontakte, Google и Amazon.

След като провеждаме нашите срещи без прекъсване от 2007 г., тази година ще се срещнем за 14-ти път. През това време конференцията се разрасна 10 пъти, миналата година ключовото събитие в индустрията събра 3339 участници, 165 лектори на доклади и срещи и 16 песни се изпълняваха едновременно.
Миналата година за вас имаше 20 автобуса, 5280 литра чай и кафе, 1650 литра плодови напитки и 10200 бутилки вода. И още 2640 килограма храна, 16 000 чинии и 25 000 чаши. Между другото, със събраните пари от рециклирана хартия засадихме 100 дъбови фиданки 🙂

Билети могат да бъдат закупени тук, получавайте новини за конференцията — тук, и говорете във всички социални мрежи: Telegram, Facebook, Vkontakte и Twitter.

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