yn system rheoli cronfa ddata golofnog ffynhonnell agored ar gyfer prosesu ymholiadau dadansoddol ar-lein (OLAP) a grëwyd gan Yandex. Fe'i defnyddir gan Yandex, CloudFlare, VK.com, Badoo a gwasanaethau eraill ledled y byd i storio symiau mawr iawn o ddata (mewnosod miloedd o resi yr eiliad neu petabytes o ddata sy'n cael ei storio ar ddisg).
Mewn DBMS arferol, "llinyn", ac enghreifftiau yw MySQL, Postgres, MS SQL Server, mae data'n cael ei storio yn y drefn hon:
Yn yr achos hwn, mae'r gwerthoedd sy'n gysylltiedig ag un rhes yn cael eu storio'n gorfforol ochr yn ochr. Yn DBMS colofnol, mae gwerthoedd o wahanol golofnau'n cael eu storio ar wahân, ac mae data un golofn yn cael ei storio gyda'i gilydd:
Enghreifftiau o DBMS colofnol yw Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Anfonwr post yw'r cwmni Dechreuais ddefnyddio Clickhouse yn 2018 ar gyfer adrodd a gwnaeth ei symlrwydd, ei scalability, cefnogaeth SQL, a chyflymder argraff fawr arnaf. Roedd cyflymder y DBMS hwn yn ymylu ar hud.
rhwyddineb
Mae Clickhouse yn gosod ar Ubuntu gydag un gorchymyn. Os ydych chi'n gwybod SQL, gallwch chi ddechrau defnyddio Clickhouse ar unwaith ar gyfer eich anghenion. Fodd bynnag, nid yw hyn yn golygu y gallwch "dangos creu tabl" yn MySQL a chopïo-gludo SQL yn Clickhouse.
O'i gymharu â MySQL, mae gwahaniaethau math o ddata pwysig yn y diffiniadau sgema tabl yn y DBMS hwn, felly mae angen peth amser arnoch o hyd i newid diffiniadau sgema'r bwrdd a dysgu'r peiriannau bwrdd i fod yn gyfforddus.
Mae Clickhouse yn gweithio'n wych heb unrhyw feddalwedd ychwanegol, ond os ydych chi am ddefnyddio dyblygu bydd angen i chi osod ZooKeeper. Mae dadansoddiad perfformiad ymholiad yn dangos canlyniadau rhagorol - mae tablau'r system yn cynnwys yr holl wybodaeth, a gellir cael yr holl ddata gan ddefnyddio SQL hen a diflas.
Cynhyrchiant
- Cymariaethau Clickhouse yn erbyn Vertica a MySQL ar weinydd cyfluniad: dwy soced Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 RAM GiB; md RAID-5 ar 8 6TB SATA HDD, ext4.
- cymhariaeth o Clickhouse gyda storfa cwmwl Amazon RedShift.
- Dyfyniadau blog :
Mae gan gronfa ddata ClickHouse ddyluniad syml iawn - mae gan bob nod yn y clwstwr yr un swyddogaeth ac maent yn defnyddio ZooKeeper yn unig ar gyfer cydlynu. Fe wnaethon ni adeiladu clwstwr bach o sawl nod a chynnal profion, lle canfuom fod gan y system berfformiad eithaf trawiadol, sy'n cyfateb i'r manteision honedig mewn meincnodau DBMS dadansoddol. Fe wnaethom benderfynu edrych yn agosach ar y cysyniad y tu ôl i ClickHouse. Y rhwystr cyntaf i ymchwil oedd diffyg offer a chymuned fach ClickHouse, felly fe wnaethom ymchwilio i ddyluniad y DBMS hwn i ddeall sut mae'n gweithio.
Nid yw ClickHouse yn cefnogi derbyn data yn uniongyrchol gan Kafka, gan mai cronfa ddata yn unig ydyw, felly fe wnaethon ni ysgrifennu ein gwasanaeth addaswyr ein hunain yn Go. Darllenodd negeseuon wedi'u hamgodio Cap'n Proto o Kafka, eu trosi i TSV, a'u mewnosod yn ClickHouse mewn sypiau trwy'r rhyngwyneb HTTP. Yn ddiweddarach fe wnaethom ailysgrifennu'r gwasanaeth hwn i ddefnyddio'r llyfrgell Go ar y cyd â'n rhyngwyneb ClickHouse ein hunain i wella perfformiad. Wrth werthuso perfformiad derbyn pecynnau, fe wnaethom ddarganfod peth pwysig - ar gyfer ClickHouse mae'r perfformiad hwn yn dibynnu'n gryf ar faint y pecyn, hynny yw, nifer y rhesi a fewnosodwyd ar yr un pryd. Er mwyn deall pam mae hyn yn digwydd, buom yn astudio sut mae ClickHouse yn storio data.
Y brif injan, neu yn hytrach, teulu o beiriannau bwrdd a ddefnyddir gan ClickHouse ar gyfer storio data, yw MergeTree. Mae'r injan hon yn gysyniadol debyg i'r algorithm LSM a ddefnyddir yn Google BigTable neu Apache Cassandra, ond mae'n osgoi adeiladu tabl cof canolradd ac yn ysgrifennu data yn uniongyrchol i ddisg. Mae hyn yn rhoi trwybwn ysgrifennu rhagorol iddo, gan fod pob pecyn a fewnosodir yn cael ei ddidoli gan yr allwedd gynradd "sylfaenol" yn unig, wedi'i gywasgu, a'i ysgrifennu ar ddisg i ffurfio segment.
Mae absenoldeb tabl cof neu unrhyw gysyniad o “ffresder” data hefyd yn golygu mai dim ond eu hychwanegu, nid yw'r system yn cefnogi newid na dileu. O heddiw ymlaen, yr unig ffordd i ddileu data yw ei ddileu fesul mis calendr, gan nad yw segmentau byth yn croesi ffin mis. Mae tîm ClickHouse wrthi'n gweithio ar wneud y nodwedd hon yn addasadwy. Ar y llaw arall, mae'n gwneud ysgrifennu a chyfuno segmentau yn rhydd o gynnen, felly derbyniwch raddfeydd trwybwn yn llinol gyda nifer y mewnosodiadau cyfochrog nes bod I/O neu creiddiau'n dirlawn.
Fodd bynnag, mae'r amgylchiad hwn hefyd yn golygu nad yw'r system yn addas ar gyfer pecynnau bach, felly defnyddir gwasanaethau Kafka a mewnosodwyr ar gyfer byffro. Ymhellach, mae ClickHouse yn y cefndir yn parhau i uno'r segmentau yn barhaus, fel y bydd llawer o ddarnau bach o wybodaeth yn cael eu cyfuno a'u cofnodi fwy o weithiau, gan gynyddu dwyster y recordio. Fodd bynnag, bydd gormod o rannau digyswllt yn achosi i fewnosodiadau hyrddio'n ymosodol cyn belled â bod yr uno'n parhau. Rydym wedi canfod mai’r cyfaddawd gorau rhwng amlyncu data amser real a pherfformiad amlyncu yw derbyn nifer cyfyngedig o fewnosodiadau yr eiliad yn y tabl.
Yr allwedd i berfformiad darllen tabl yw mynegeio a lleoliad y data ar ddisg. Ni waeth pa mor gyflym yw'r prosesu, pan fydd angen i'r injan sganio terabytes o ddata o ddisg a defnyddio ffracsiwn ohono yn unig, bydd yn cymryd amser. Mae ClickHouse yn storfa golofn, felly mae pob segment yn cynnwys ffeil ar gyfer pob colofn (colofn) gyda gwerthoedd wedi'u didoli ar gyfer pob rhes. Felly, gellir hepgor colofnau cyfan nad ydynt yn bresennol yn yr ymholiad yn gyntaf, ac yna gellir prosesu celloedd lluosog ochr yn ochr â gweithredu fectoraidd. Er mwyn osgoi sgan llawn, mae gan bob segment ffeil fynegai fach.
O ystyried bod pob colofn wedi'i didoli yn ôl yr "allwedd gynradd", dim ond labeli (rhesi wedi'u dal) o bob Nfed rhes y mae'r ffeil mynegai yn eu cynnwys, er mwyn gallu eu cadw yn y cof hyd yn oed ar gyfer tablau mawr iawn. Er enghraifft, gallwch chi osod y gosodiadau diofyn i “farcio pob rhes 8192”, yna mynegeio “prin” o dabl gydag 1 triliwn. byddai llinellau sy'n ffitio'n hawdd i'r cof ond yn cymryd 122 o nodau.
Datblygu system
Gellir olrhain datblygiad a gwelliant Clickhouse ar a gwneud yn siŵr bod y broses o “dyfu i fyny” yn digwydd ar gyflymder trawiadol.
Poblogrwydd
Mae'n ymddangos bod poblogrwydd Clickhouse yn tyfu'n esbonyddol, yn enwedig yn y gymuned sy'n siarad Rwsieg. Dangosodd cynhadledd llwyth Uchel 2018 y llynedd (Moscow, Tachwedd 8-9, 2018) fod angenfilod fel vk.com a Badoo yn defnyddio Clickhouse, sy'n mewnosod data (er enghraifft, logiau) o ddegau o filoedd o weinyddion ar yr un pryd. Mewn fideo 40 munud . Yn fuan byddwn yn postio'r trawsgrifiad ar Habr er hwylustod gweithio gyda'r deunydd.
Ceisiadau
Ar ôl treulio peth amser yn ymchwilio, rwy'n meddwl bod yna feysydd lle gall ClickHouse fod yn ddefnyddiol neu'n gallu disodli atebion mwy traddodiadol a phoblogaidd yn llwyr fel MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot a Derwydd. Mae'r canlynol yn fanylion defnyddio ClickHouse i uwchraddio neu ddisodli'r DBMS uchod yn llwyr.
Ymestyn MySQL a PostgreSQL
Yn fwyaf diweddar, fe wnaethom ddisodli MySQL yn rhannol â ClickHouse ar gyfer y platfform cylchlythyr . Y broblem oedd bod MySQL oherwydd dyluniad gwael wedi cofnodi pob e-bost a anfonwyd a phob dolen yn yr e-bost hwnnw gyda hash base64, gan greu tabl MySQL enfawr (email_stats). Ar ôl anfon dim ond 10 miliwn o negeseuon e-bost at danysgrifwyr y gwasanaeth, roedd y tabl hwn yn meddiannu 150 GB o ofod ffeil, a dechreuodd MySQL "dwp" ar ymholiadau syml. I drwsio’r mater gofod ffeil, fe wnaethom ddefnyddio cywasgiad tabl InnoDB yn llwyddiannus, a’i gostyngodd gan ffactor o 4. Fodd bynnag, nid yw'n gwneud synnwyr o hyd storio mwy na 20-30 miliwn o negeseuon e-bost yn MySQL er mwyn darllen hanes yn unig, gan fod unrhyw ymholiad syml sy'n gorfod gwneud sgan llawn am ryw reswm yn arwain at gyfnewid a I/O trwm. uwchben, am ba rai y cawsom rybuddion Zabbix yn rheolaidd.
Mae Clickhouse yn defnyddio dau algorithm cywasgu sy'n lleihau faint o ddata o tua , ond yn yr achos penodol hwn, roedd y data yn arbennig o "gywasgadwy".
Amnewid ELK
Yn seiliedig ar fy mhrofiad fy hun, mae stac ELK (ElasticSearch, Logstash a Kibana, yn yr achos penodol hwn ElasticSearch) yn gofyn am lawer mwy o adnoddau i'w rhedeg nag sydd eu hangen i storio logiau. Mae ElasticSearch yn beiriant gwych os ydych chi eisiau chwiliad log testun llawn da (nid wyf yn meddwl bod ei angen arnoch mewn gwirionedd), ond rwy'n meddwl tybed pam ei fod wedi dod yn beiriant logio safonol de facto. Roedd ei berfformiad llyncu, ynghyd â Logstash, wedi rhoi problemau inni hyd yn oed ar lwythi gwaith gweddol ysgafn ac roedd angen ychwanegu mwy a mwy o RAM a gofod disg. Fel cronfa ddata, mae Clickhouse yn well nag ElasticSearch am y rhesymau canlynol:
- cymorth tafodiaith SQL;
- Y raddfa orau o gywasgu'r data sydd wedi'i storio;
- Cefnogaeth i chwiliad Regex yn lle chwiliad testun llawn;
- Gwell amserlennu ymholiadau a pherfformiad cyffredinol gwell.
Ar hyn o bryd, y broblem fwyaf sy'n codi wrth gymharu ClickHouse ag ELK yw'r diffyg atebion ar gyfer uwchlwytho logiau, yn ogystal â diffyg dogfennaeth a thiwtorialau ar y pwnc hwn. Ar yr un pryd, gall pob defnyddiwr sefydlu ELK gan ddefnyddio llawlyfr y Cefnfor Digidol, sy'n bwysig iawn ar gyfer gweithredu technolegau o'r fath yn gyflym. Mae peiriant cronfa ddata yma, ond nid oes Filebeat ar gyfer ClickHouse eto. Oes, mae yna a system ar gyfer gweithio gyda logiau , mae offeryn i fewnbynnu data ffeil log i ClickHouse, ond mae hyn i gyd yn cymryd mwy o amser. Fodd bynnag, mae ClickHouse yn dal i arwain y ffordd oherwydd ei symlrwydd, felly gall hyd yn oed dechreuwyr ei osod yn hawdd a dechrau defnydd cwbl weithredol mewn dim ond 10 munud.
Gan ffafrio datrysiadau minimalaidd, ceisiais ddefnyddio FluentBit, teclyn llwytho log cof isel iawn, gyda ClickHouse wrth geisio osgoi defnyddio Kafka. Fodd bynnag, mae angen rhoi sylw i fân anghydnawsedd, megis cyn y gellir ei wneud heb yr haen ddirprwy sy'n trosi data o FluentBit i ClickHouse.
Fel dewis arall yn lle Kibana, gallwch ddefnyddio ClickHouse fel backend . Hyd y deallaf, gall hyn achosi problemau perfformiad wrth rendro nifer enfawr o bwyntiau data, yn enwedig gyda fersiynau hŷn o Grafana. Yn Qwintry, nid ydym wedi rhoi cynnig ar hyn eto, ond mae cwynion am hyn yn ymddangos o bryd i'w gilydd ar sianel gymorth ClickHouse yn Telegram.
Amnewid Google Big Query ac Amazon RedShift (ateb i gwmnïau mawr)
Yr achos defnydd delfrydol ar gyfer BigQuery yw llwytho 1TB o ddata JSON a rhedeg ymholiadau dadansoddol arno. Mae Big Query yn gynnyrch gwych y mae'n anodd goramcangyfrif ei scalability. Mae hwn yn feddalwedd llawer mwy cymhleth na ClickHouse sy'n rhedeg ar glwstwr mewnol, ond o safbwynt y cleient, mae ganddo lawer yn gyffredin â ClickHouse. Gall BigQuery "prisio i fyny" yn gyflym ar ôl i chi ddechrau talu am bob SELECT, felly mae'n ddatrysiad SaaS go iawn gyda'i holl fanteision ac anfanteision.
ClickHouse yw'r dewis gorau pan fyddwch chi'n rhedeg llawer o ymholiadau cyfrifiadurol drud. Po fwyaf o ymholiadau SELECT rydych chi'n eu rhedeg bob dydd, y mwyaf o bwynt y mae'n ei wneud i ddisodli Big Query gyda ClickHouse, oherwydd bydd un o'r fath yn ei le yn arbed miloedd o ddoleri i chi o ran llawer o derabytes o ddata sy'n cael eu prosesu. Nid yw hyn yn berthnasol i ddata sydd wedi'i storio, sy'n eithaf rhad i'w brosesu yn Big Query.
Mewn erthygl gan Alexander Zaitsev, cyd-sylfaenydd Altinity yn disgrifio manteision ymfudiad DBMS o'r fath.
AmserlenDB Amnewid
Estyniad PostgreSQL yw TimescaleDB sy'n gwneud y gorau o weithio gyda chyfresi amser mewn cronfa ddata reolaidd (, ).
Er nad yw ClickHouse yn gystadleuydd difrifol yn y gilfach cyfres amser, ond o ran strwythur colofnol a gweithredu ymholiad fector, mae'n llawer cyflymach na TimescaleDB yn y rhan fwyaf o achosion o brosesu ymholiadau dadansoddol. Ar yr un pryd, mae perfformiad derbyn data pecyn ClickHouse tua 3 gwaith yn uwch, yn ogystal, mae'n defnyddio 20 gwaith yn llai o le ar y ddisg, sy'n bwysig iawn ar gyfer prosesu llawer iawn o ddata hanesyddol: .
Yn wahanol i ClickHouse, yr unig ffordd i arbed rhywfaint o le ar ddisg yn TimescaleDB yw defnyddio ZFS neu systemau ffeiliau tebyg.
Bydd diweddariadau sydd ar ddod i ClickHouse yn debygol o gyflwyno cywasgu delta, a fydd yn ei gwneud hyd yn oed yn fwy addas ar gyfer prosesu a storio data cyfres amser. Gall TimescaleDB fod yn ddewis gwell na ClickHouse noeth yn yr achosion canlynol:
- gosodiadau bach gydag ychydig iawn o RAM (<3 GB);
- nifer fawr o INSERT bach nad ydych am eu byffro yn ddarnau mawr;
- gwell cysondeb, unffurfiaeth a gofynion ACID;
- cymorth PostGIS;
- uno â thablau PostgreSQL presennol, gan mai PostgreSQL yw Graddfa Amser DB yn ei hanfod.
Cystadleuaeth gyda systemau Hadoop a MapReduce
Gall Hadoop a chynhyrchion MapReduce eraill wneud llawer o gyfrifiadau cymhleth, ond maent yn tueddu i redeg yn hwyr iawn.Mae ClickHouse yn trwsio'r broblem hon trwy brosesu terabytes o ddata a chynhyrchu canlyniadau bron yn syth. Felly, mae ClickHouse yn llawer mwy effeithlon ar gyfer perfformio ymchwil ddadansoddol gyflym, ryngweithiol, a ddylai fod o ddiddordeb i wyddonwyr data.
Cystadleuaeth gyda Pinot a Druid
Cystadleuwyr agosaf ClickHouse yw'r cynhyrchion ffynhonnell agored colofnol, llinol y gellir eu graddio, Pinot a Druid. Mae swydd ardderchog yn cymharu'r systemau hyn wedi'i chyhoeddi yn yr erthygl Chwefror 1, 2018
Mae angen diweddaru'r erthygl hon - mae'n dweud nad yw ClickHouse yn cefnogi gweithrediadau DIWEDDARU a DILEU, nad yw'n gwbl wir mewn perthynas â'r fersiynau diweddaraf.
Nid oes gennym lawer o brofiad gyda'r DBMSs hyn, ond nid wyf yn hoffi cymhlethdod y seilwaith sylfaenol sy'n ofynnol i redeg Druid a Pinot - mae'n griw cyfan o "rhannau symudol" wedi'u hamgylchynu gan Java o bob ochr.
Mae Druid a Pinot yn brosiectau deor Apache, sy'n cael sylw manwl gan Apache ar eu tudalennau prosiect GitHub. Ymddangosodd Pinot yn y deorydd ym mis Hydref 2018, a ganwyd Druid 8 mis ynghynt - ym mis Chwefror.
Mae’r diffyg gwybodaeth am sut mae AFS yn gweithio yn codi rhai cwestiynau, ac efallai dwp, i mi. Tybed a sylwodd awduron Pinot fod Sefydliad Apache yn fwy tueddol tuag at Dderwyddon, ac a achosodd y fath agwedd tuag at gystadleuydd deimlad o genfigen? A fydd datblygiad Derwydd yn arafu a datblygiad Pinot yn cyflymu os bydd y noddwyr sy'n cefnogi'r cyntaf yn ymddiddori yn yr olaf yn sydyn?
Anfanteision ClickHouse
Anaeddfedrwydd: Yn amlwg, mae hon yn dechnoleg ddiflas o hyd, ond beth bynnag, ni welir dim fel hyn mewn DBMS colofnol eraill.
Nid yw mewnosodiadau bach yn perfformio'n dda ar gyflymder uchel: rhaid rhannu mewnosodiadau yn dalpiau mawr oherwydd bod perfformiad mewnosodiadau bach yn diraddio yn gymesur â nifer y colofnau ym mhob rhes. Dyma sut mae ClickHouse yn storio data ar ddisg - mae pob colofn yn golygu 1 ffeil neu fwy, felly i fewnosod 1 rhes sy'n cynnwys 100 o golofnau, mae angen ichi agor ac ysgrifennu o leiaf 100 o ffeiliau. Dyma pam mae angen cyfryngwr ar gyfer byffro mewnosod (oni bai bod y cleient ei hun yn darparu byffro) - fel arfer Kafka neu ryw fath o system giwio. Gallwch hefyd ddefnyddio'r peiriant bwrdd Buffer i gopïo darnau mawr o ddata yn ddiweddarach i dablau MergeTree.
Mae ymunoiadau tabl wedi'u cyfyngu gan RAM gweinyddwr, ond o leiaf maen nhw yno! Er enghraifft, nid oes gan Druid a Pinot gysylltiadau o'r fath o gwbl, gan eu bod yn anodd eu gweithredu'n uniongyrchol mewn systemau gwasgaredig nad ydynt yn cefnogi symud darnau mawr o ddata rhwng nodau.
Canfyddiadau
Yn y blynyddoedd i ddod, rydym yn bwriadu gwneud defnydd helaeth o ClickHouse yn Qwintry, gan fod y DBMS hwn yn darparu cydbwysedd rhagorol o berfformiad, gorbenion isel, scalability, a symlrwydd. Rwy'n eithaf sicr y bydd yn lledaenu'n gyflym unwaith y bydd cymuned ClickHouse yn dod o hyd i fwy o ffyrdd i'w ddefnyddio mewn gosodiadau bach a chanolig.
Rhai hysbysebion 🙂
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com