е колонообразен систем за управување со бази на податоци со отворен код за онлајн аналитичка обработка на прашања (OLAP) создаден од Yandex. Се користи од Yandex, CloudFlare, VK.com, Badoo и други услуги ширум светот за складирање навистина големи количини на податоци (вметнување илјадници редови во секунда или петабајти податоци зачувани на дискот).
Во нормален, „жичен“ DBMS, чии примери се MySQL, Postgres, MS SQL Server, податоците се складираат по овој редослед:
Во овој случај, вредностите поврзани со еден ред физички се складираат рамо до рамо. Во колонообразен DBMS, вредностите од различни колони се зачувуваат одделно, а податоците од една колона се складираат заедно:
Примери на колонообразни DBMS се Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Компанијата е испраќач на пошта Почнав да го користам Clickhouse во 2018 година за известување и бев многу импресиониран од неговата едноставност, приспособливост, поддршка за SQL и брзина. Брзината на овој DBMS се граничи со магија.
олеснување
Clickhouse инсталира на Ubuntu со една команда. Ако знаете SQL, можете веднаш да започнете со користење на Clickhouse за вашите потреби. Сепак, ова не значи дека можете да „покажете за креирање табела“ во MySQL и да копирате-залепите SQL во Clickhouse.
Во споредба со MySQL, постојат важни разлики во типовите на податоци во дефинициите на шемите на табелите во овој DBMS, така што сè уште ви треба малку време да ги промените дефинициите на шемите за табели и да ги научите моторите на табелите за да се чувствувате удобно.
Clickhouse работи одлично без дополнителен софтвер, но ако сакате да користите репликација ќе треба да инсталирате ZooKeeper. Анализата на перформансите на барањето покажува одлични резултати - системските табели ги содржат сите информации, а сите податоци може да се добијат со користење на стара и здодевна SQL.
Перформанси
- Clickhouse наспроти Vertica и MySQL споредби на конфигурациски сервер: два приклучоци Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 на 8 6TB SATA HDD, ext4.
- споредба на Clickhouse со складирање облак на Amazon RedShift.
- Извадоци од блог :
Базата на податоци ClickHouse има многу едноставен дизајн - сите јазли во кластерот имаат иста функционалност и користат само ZooKeeper за координација. Изградивме мал кластер од неколку јазли и извршивме тестирање, при што откривме дека системот има доста импресивни перформанси, што одговара на тврдените предности во аналитичките одредници на DBMS. Решивме подетално да го разгледаме концептот зад ClickHouse. Првата пречка за истражување беше недостатокот на алатки и малата заедница на ClickHouse, па навлегувавме во дизајнот на овој DBMS за да разбереме како функционира.
ClickHouse не поддржува примање податоци директно од Кафка, бидејќи тоа е само база на податоци, па затоа напишавме сопствена услуга за адаптер во Go. Ги читаше Cap'n Proto кодираните пораки од Кафка, ги конвертираше во TSV и ги вметнуваше во ClickHouse во групи преку интерфејсот HTTP. Подоцна ја преработивме оваа услуга за да ја користиме библиотеката Go во врска со нашиот сопствен интерфејс ClickHouse за да ги подобриме перформансите. При евалуација на перформансите на приемните пакети, откривме важна работа - се покажа дека за ClickHouse оваа изведба силно зависи од големината на пакетот, односно од бројот на редови вметнати во исто време. За да разбереме зошто тоа се случува, проучувавме како ClickHouse ги складира податоците.
Главниот мотор, или подобро кажано, фамилија на табели мотори што ги користи ClickHouse за складирање податоци, е MergeTree. Овој мотор е концептуално сличен на алгоритмот LSM што се користи во Google BigTable или Apache Cassandra, но избегнува градење средна мемориска табела и запишува податоци директно на дискот. Ова му дава одлична брзина на пишување, бидејќи секој вметнат пакет е само подреден според примарниот клуч „примарниот клуч“, компресиран и запишан на дискот за да формира сегмент.
Отсуството на мемориска табела или каков било концепт на „свежина“ на податоци исто така значи дека тие можат само да се додаваат, системот не поддржува менување или бришење. Од денес, единствениот начин за бришење податоци е да ги избришете по календарски месец, бидејќи сегментите никогаш не ја преминуваат границата на еден месец. Тимот на ClickHouse активно работи на тоа да ја направи оваа функција приспособлива. Од друга страна, тоа го прави пишувањето и спојувањето на сегменти без кавга, затоа примајте скали на пропусната моќ линеарно со бројот на паралелни вметнувања додека I/O или јадрата не се заситат.
Меѓутоа, оваа околност значи и дека системот не е погоден за мали пакети, па затоа услугите и инсертерите на Кафка се користат за баферирање. Понатаму, ClickHouse во позадина продолжува континуирано да ги спојува сегментите, така што многу мали информации ќе се комбинираат и снимаат повеќе пати, со што ќе се зголеми интензитетот на снимањето. Сепак, премногу неповрзани делови ќе предизвикаат агресивно пригушување на влошките сè додека продолжува спојувањето. Откривме дека најдобриот компромис помеѓу внесувањето податоци во реално време и перформансите на ингестијата е да се прифати ограничен број вметнувања во секунда во табелата.
Клучот за перформансите за читање на табелата е индексирањето и локацијата на податоците на дискот. Без разлика колку е брза обработката, кога моторот треба да скенира терабајти податоци од дискот и да користи само дел од нив, ќе биде потребно време. ClickHouse е продавница за колони, така што секој сегмент содржи датотека за секоја колона (колона) со подредени вредности за секој ред. Така, цели колони кои не се присутни во барањето може прво да се прескокнат, а потоа повеќе ќелии може да се обработуваат паралелно со векторизирано извршување. За да се избегне целосно скенирање, секој сегмент има мала индексна датотека.
Со оглед на тоа што сите колони се подредени по „примарниот клуч“, индексната датотека ги содржи само етикетите (фатените редови) од секој N-ти ред, за да може да ги чува во меморија дури и за многу големи табели. На пример, можете да ги поставите стандардните поставки за „означување на секој 8192-ри ред“, потоа „скудно“ индексирање на табела со 1 трилион. линиите што лесно се вклопуваат во меморијата би земале само 122 знаци.
Развој на системот
Развојот и подобрувањето на Clickhouse може да се следат и погрижете се процесот на „растење“ да се одвива со импресивно темпо.
Популарност
Се чини дека популарноста на Clickhouse расте експоненцијално, особено во заедницата што зборува руски. Минатогодишната конференција за високо оптоварување 2018 (Москва, 8-9 ноември 2018) покажа дека чудовишта како vk.com и Badoo користат Clickhouse, кој вметнува податоци (на пример, дневници) од десетици илјади сервери истовремено. Во видео од 40 минути . Наскоро ќе го објавиме преписот на Хабр за погодност за работа со материјалот.
Апликации
Откако поминав одредено време во истражување, мислам дека има области каде што ClickHouse може да биде корисен или целосно да ги замени другите традиционални и популарни решенија како што се MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot и друид. Следниве се деталите за користење на ClickHouse за надградба или целосно замена на горенаведените DBMS.
Проширување на MySQL и PostgreSQL
Неодамна, делумно го заменивме MySQL со ClickHouse за платформата за билтен . Проблемот беше што MySQL поради лошо замислен дизајн ја евидентираше секоја испратена е-пошта и секоја врска во таа е-пошта со хаш-base64, создавајќи огромна MySQL табела (email_stats). Откако испрати само 10 милиони е-пошта до претплатниците на услугата, оваа табела зафаќаше 150 GB простор за датотеки, а MySQL почна да се „глупави“ на едноставни прашања. За да го решиме проблемот со просторот за датотеки, успешно користевме компресија на табелата InnoDB, што го намали за фактор 4. Сепак, сè уште нема смисла да се складираат повеќе од 20-30 милиони е-пошта во MySQL само заради читање историја, бидејќи секое едноставно барање што поради некоја причина мора да направи целосно скенирање резултира со замена и тежок I/O надземни, за што редовно добивавме предупредувања од Zabbix.
Clickhouse користи два алгоритми за компресија кои ја намалуваат количината на податоци за околу , но во конкретниот случај податоците беа особено „компресибилни“.
Замена на ELK
Врз основа на моето сопствено искуство, оџакот ELK (ElasticSearch, Logstash и Kibana, во конкретниов случај ElasticSearch) бара многу повеќе ресурси за извршување отколку што се потребни за складирање на дневници. ElasticSearch е одличен мотор ако сакате добро пребарување на дневници со целосен текст (и мислам дека навистина не ви треба), но се прашувам зошто стана де факто стандарден мотор за логирање. Нејзините перформанси за внесување, во комбинација со Logstash, ни создаваа проблеми дури и при прилично мали оптоварувања и бараше додавање на сè повеќе RAM и простор на дискот. Како база на податоци, Clickhouse е подобар од ElasticSearch од следниве причини:
- Поддршка за дијалект SQL;
- Најдобар степен на компресија на зачуваните податоци;
- Поддршка за пребарување Regex наместо пребарување на целосен текст;
- Подобрено распоред на барања и подобри вкупни перформанси.
Во моментов, најголемиот проблем што се јавува при споредување на ClickHouse со ELK е немањето решенија за прикачување логови, како и недостатокот на документација и упатства на оваа тема. Во исто време, секој корисник може да го постави ELK користејќи го прирачникот Digital Ocean, што е многу важно за брза имплементација на такви технологии. Тука има мотор на база на податоци, но сè уште нема Filebeat за ClickHouse. Да има и систем за работа со логови , постои алатка да внесете податоци за евиденција на датотеката во ClickHouse, но за сето ова е потребно повеќе време. Сепак, ClickHouse сè уште води на патот поради неговата едноставност, па дури и почетниците можат лесно да го инсталираат и да започнат целосно функционална употреба за само 10 минути.
Претпочитајќи минималистички решенија, се обидов да користам FluentBit, алатка за испраќање дневници со многу ниска меморија, со ClickHouse, додека се обидував да избегнам користење на Кафка. Сепак, малите некомпатибилности треба да се решат, како на пр пред да може да се направи без прокси слојот што ги конвертира податоците од FluentBit во ClickHouse.
Како алтернатива на Kibana, можете да го користите ClickHouse како заднина . Колку што разбрав, ова може да предизвика проблеми со перформансите при рендерирање на огромен број податочни точки, особено кај постарите верзии на Grafana. Во Qwintry, сè уште не сме го пробале ова, но поплаките за ова се појавуваат од време на време на каналот за поддршка на ClickHouse во Telegram.
Замена на Google Big Query и Amazon RedShift (решение за големи компании)
Идеален случај за употреба за BigQuery е да се вчитаат 1TB JSON податоци и да се извршат аналитички барања на нив. Big Query е одличен производ чија приспособливост е тешко да се прецени. Ова е многу покомплексен софтвер од ClickHouse кој работи на внатрешен кластер, но од гледна точка на клиентот, има многу заедничко со ClickHouse. BigQuery може брзо да „поскапи“ откако ќе почнете да плаќате за секој SELECT, па затоа е вистинско SaaS решение со сите свои добрите и лошите страни.
ClickHouse е најдобриот избор кога извршувате многу пресметковно скапи барања. Колку повеќе SELECT пребарувања извршувате секој ден, толку повеќе е важно да го замените Big Query со ClickHouse, бидејќи таквата замена ќе ви заштеди илјадници долари кога станува збор за многу терабајти податоци што се обработуваат. Ова не се однесува на зачуваните податоци, што е прилично евтино за обработка во Big Query.
Во статија на Александар Зајцев, ко-основач на Altinity ги опишува придобивките од таквата миграција на DBMS.
Замена на TimescaleDB
TimescaleDB е екстензија PostgreSQL што ја оптимизира работата со временски серии во редовна база на податоци (, ).
Иако ClickHouse не е сериозен конкурент во нишата на временските серии, но во однос на колонообразната структура и векторското извршување на барањето, тој е многу побрз од TimescaleDB во повеќето случаи на обработка на аналитички барања. Во исто време, перформансите за примање на пакетни податоци на ClickHouse се околу 3 пати повисоки, покрај тоа, користат 20 пати помалку простор на дискот, што е навистина важно за обработка на големи количини на историски податоци: .
За разлика од ClickHouse, единствениот начин да заштедите простор на дискот во TimescaleDB е да користите ZFS или слични датотечни системи.
Претстојните ажурирања на ClickHouse најверојатно ќе воведат делта компресија, што ќе го направи уште посоодветно за обработка и складирање на податоци од временски серии. TimescaleDB може да биде подобар избор од голиот ClickHouse во следниве случаи:
- мали инсталации со многу малку RAM (<3 GB);
- голем број мали ИНСЕРТИ кои не сакате да ги префрлите во големи фрагменти;
- подобра конзистентност, униформност и барања за КИСИЛ;
- PostGIS поддршка;
- се спојуваат со постојните PostgreSQL табели, бидејќи Timescale DB е во суштина PostgreSQL.
Конкуренција со системите Hadoop и MapReduce
Hadoop и другите производи на MapReduce можат да вршат многу сложени пресметки, но имаат тенденција да работат со огромна латентност. ClickHouse го решава овој проблем со обработка на терабајти податоци и производство на резултати речиси веднаш. Така, ClickHouse е многу поефикасен за извршување на брзо, интерактивно аналитичко истражување, кое треба да биде од интерес за научниците за податоци.
Натпревар со Пино и Друид
Најблиските конкуренти на ClickHouse се колонообразните, линеарно скалабилни производи со отворен код Pinot и Druid. Одлична работа за споредување на овие системи е објавена во статијата 1 февруари 2018 година
Оваа статија треба да се ажурира - вели дека ClickHouse не поддржува операции за ажурирање и бришење, што не е целосно точно во однос на најновите верзии.
Немаме многу искуство со овие DBMS, но не ми се допаѓа сложеноста на основната инфраструктура што е потребна за да се стартуваат Druid и Pinot - тоа е цел куп „подвижни делови“ опкружени со Java од сите страни.
Druid и Pinot се Apache-инкубатор проекти, кои се детално опфатени од Apache на нивните страници на проектот GitHub. Пино се појави во инкубаторот во октомври 2018 година, а Друид е роден 8 месеци порано - во февруари.
Недостатокот на информации за тоа како функционира AFS покренува некои, а можеби и глупави прашања за мене. Се прашувам дали авторите на Пино забележале дека Фондацијата Апачи е повеќе наклонета кон Друид и дали таквиот однос кон конкурентот предизвикал чувство на завист? Дали развојот на Друид ќе се забави и развојот на Пино ќе се забрза ако спонзорите што го поддржуваат првиот одеднаш се заинтересираат за второто?
Недостатоци на ClickHouse
Незрелост: Очигледно, ова е сè уште здодевна технологија, но во секој случај, ништо вакво не се гледа во другите колонообразни DBMS.
Малите влошки не работат добро при голема брзина: влошките мора да се поделат на големи парчиња бидејќи перформансите на малите влошки се намалуваат пропорционално со бројот на колони во секој ред. Вака ClickHouse ги складира податоците на дискот - секоја колона значи 1 датотека или повеќе, така што за да вметнете 1 ред кој содржи 100 колони, треба да отворите и напишете најмалку 100 датотеки. Ова е причината зошто вметнувањето на баферот бара посредник (освен ако самиот клиент не обезбедува баферирање) - обично Кафка или некој вид систем на редици. Можете исто така да го користите моторот за табела Buffer за подоцна да копирате големи делови од податоци во табелите MergeTree.
Приклучувањата на табелите се ограничени од RAM меморијата на серверот, но барем ги има! На пример, Друид и Пино воопшто немаат такви врски, бидејќи е тешко да се имплементираат директно во дистрибуирани системи кои не поддржуваат преместување на големи делови од податоци помеѓу јазлите.
Наоди
Во наредните години, планираме широко да го користиме ClickHouse во Qwintry, бидејќи овој DBMS обезбедува одличен баланс на перформанси, ниски трошоци, приспособливост и едноставност. Прилично сум сигурен дека брзо ќе се прошири откако заедницата ClickHouse ќе најде повеќе начини да го користи во мали и средни инсталации.
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB DDR4).
Dell R730xd 2 пати поевтин во центарот за податоци Equinix Tier IV во Амстердам? Само овде во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за
Извор: www.habr.com