HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

HighLoad++ Moscow 2018, Neuadd y Gyngres. Tachwedd 9, 15:00

Crynodebau a chyflwyniad: http://www.highload.ru/moscow/2018/abstracts/4066

Yuri Nasretdinov (VKontakte): bydd yr adroddiad yn sôn am y profiad o weithredu ClickHouse yn ein cwmni - pam mae ei angen arnom, faint o ddata rydyn ni'n ei storio, sut rydyn ni'n ei ysgrifennu, ac ati.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Deunyddiau ychwanegol: defnyddio Clickhouse yn lle ELK, Big Query ac TimescaleDB

Yuri Nasretdinov: - Helo bawb! Fy enw i yw Yuri Nasretdinov, gan fy mod wedi cael fy nghyflwyno eisoes. Rwy'n gweithio yn VKontakte. Byddaf yn siarad am sut yr ydym yn mewnosod data i ClickHouse o'n fflyd gweinyddwyr (degau o filoedd).

Beth yw boncyffion a pham eu casglu?

Yr hyn y byddwn yn ei ddweud wrthych: beth wnaethom ni, pam roedd angen "ClickHouse", yn y drefn honno, pam y gwnaethom ei ddewis, pa fath o berfformiad y gallwch chi ei gael yn fras heb ffurfweddu unrhyw beth yn arbennig. Fe ddywedaf ymhellach wrthych am fyrddau byffer, am y problemau a gawsom gyda nhw ac am ein datrysiadau a ddatblygwyd gennym o ffynhonnell agored - KittenHouse a Lighthouse.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Pam roedd angen i ni wneud unrhyw beth o gwbl (mae popeth bob amser yn dda ar VKontakte, iawn?). Roeddem am gasglu logiau dadfygio (ac roedd cannoedd o derabytes o ddata yno), efallai rhywsut y byddai'n fwy cyfleus i gyfrifo ystadegau; ac mae gennym fflyd o ddegau o filoedd o weinyddion y mae angen gwneud hyn i gyd ohonynt.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Pam wnaethon ni benderfynu? Mae'n debyg bod gennym ni atebion ar gyfer storio boncyffion. Yma - mae "Backend VK" mor gyhoeddus. Rwy'n argymell yn fawr tanysgrifio iddo.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Beth yw boncyffion? Dyma injan sy'n dychwelyd araeau gwag. Peiriannau yn VK yw'r hyn y mae eraill yn ei alw'n ficrowasanaethau. A dyma sticer gwenu (tipyn o hoff bethau). Sut felly? Wel, gwrandewch ymhellach!

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Beth ellir ei ddefnyddio i storio boncyffion? Mae'n amhosib peidio â sôn am Hadup. Yna, er enghraifft, Rsyslog (storio'r logiau hyn mewn ffeiliau). LSD. Pwy a wyr beth yw LSD? Na, nid yr LSD hwn. Storio ffeiliau, yn y drefn honno, hefyd. Wel, mae ClickHouse yn opsiwn rhyfedd.

Clickhouse a chystadleuwyr: gofynion a chyfleoedd

Beth ydyn ni eisiau? Rydym am sicrhau nad oes yn rhaid i ni boeni gormod am y llawdriniaeth, fel ei fod yn gweithio allan o'r bocs, yn ddelfrydol heb fawr o gyfluniad. Rydyn ni eisiau ysgrifennu llawer, ac ysgrifennu'n gyflym. Ac rydym am ei gadw am bob math o fisoedd, blynyddoedd, hynny yw, am amser hir. Efallai ein bod ni eisiau deall rhyw broblem y daethon nhw atom ni a dweud, “Nid yw rhywbeth yn gweithio yma,” ac roedd hynny 3 mis yn ôl), ac rydym am allu gweld beth ddigwyddodd 3 mis yn ôl" Cywasgu data - mae'n amlwg pam y byddai'n fantais - oherwydd mae'n lleihau faint o le y mae'n ei gymryd.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Ac mae gennym ofyniad mor ddiddorol: weithiau byddwn yn ysgrifennu allbwn rhai gorchmynion (er enghraifft, logiau), gall fod yn fwy na 4 kilobytes yn eithaf hawdd. Ac os yw'r peth hwn yn gweithio dros y CDU, yna nid oes angen iddo wario ... ni fydd ganddo unrhyw “gorbenion” ar gyfer y cysylltiad, ac i nifer fawr o weinyddion bydd hyn yn fantais.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Gadewch i ni weld beth mae ffynhonnell agored yn ei gynnig i ni. Yn gyntaf, mae gennym y Peiriant Logiau - dyma ein injan; Mewn egwyddor, gall wneud popeth, gall hyd yn oed ysgrifennu llinellau hir. Wel, nid yw'n cywasgu data yn dryloyw - gallwn gywasgu colofnau mawr ein hunain os ydym eisiau ... nid ydym, wrth gwrs, eisiau gwneud hynny (os yn bosibl). Yr unig broblem yw mai dim ond yr hyn sy'n ffitio yn ei gof y gall ei roi i ffwrdd; I ddarllen y gweddill, mae angen i chi gael y binlog o'r injan hon ac, yn unol â hynny, mae'n cymryd amser eithaf hir.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Pa opsiynau eraill sydd ar gael? Er enghraifft, "Hadup". Rhwyddineb gweithredu... Pwy sy'n meddwl bod Hadup yn hawdd ei sefydlu? Wrth gwrs, nid oes unrhyw broblemau gyda'r recordiad. Wrth ddarllen, mae cwestiynau'n codi weithiau. Mewn egwyddor, mae'n debyg na fyddwn yn dweud, yn enwedig ar gyfer boncyffion. Storio hirdymor - wrth gwrs, ie, cywasgu data - ie, llinynnau hir - mae'n amlwg y gallwch chi recordio. Ond recordio o nifer fawr o weinyddion... Mae'n rhaid i chi wneud rhywbeth eich hun o hyd!

Rsyslog. Mewn gwirionedd, fe wnaethom ei ddefnyddio fel opsiwn wrth gefn fel y gallem ei ddarllen heb ddympio'r binlog, ond ni all ysgrifennu llinellau hir; mewn egwyddor, ni all ysgrifennu mwy na 4 cilobeit. Mae'n rhaid i chi wneud cywasgu data yn yr un ffordd eich hun. Bydd darllen yn dod o ffeiliau.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yna mae datblygiad “badushka” LSD. Yn ei hanfod yr un peth â “Rsyslog”: mae'n cefnogi llinynnau hir, ond ni all weithio trwy'r CDU ac, mewn gwirionedd, oherwydd hyn, yn anffodus, mae angen ailysgrifennu cryn dipyn o bethau yno. Mae angen ailgynllunio LSD i allu recordio o ddegau o filoedd o weinyddion.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Ac yma! Opsiwn doniol yw ElasticSearch. Sut i ddweud? Mae'n gwneud yn dda gyda darllen, hynny yw, mae'n darllen yn gyflym, ond nid yn dda iawn gydag ysgrifennu. Yn gyntaf, os yw'n cywasgu data, mae'n wan iawn. Yn fwyaf tebygol, mae chwiliad llawn yn gofyn am strwythurau data mwy na'r gyfrol wreiddiol. Mae'n anodd gweithredu ac mae problemau'n aml yn codi gydag ef. Ac, eto, recordio mewn Elastig - mae'n rhaid i ni wneud popeth ein hunain.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yma mae ClickHouse yn opsiwn delfrydol, wrth gwrs. Yr unig beth yw bod recordio o ddegau o filoedd o weinyddion yn broblem. Ond o leiaf mae un broblem, gallwn geisio ei datrys rhywsut. Ac mae gweddill yr adroddiad yn ymwneud â'r broblem hon. Pa fath o berfformiad allwch chi ei ddisgwyl gan ClickHouse?

Sut ydym ni'n mynd i'w fewnosod? MergeTree

Pwy yn eich plith sydd ddim wedi clywed nac yn gwybod am “ClickHouse”? Mae angen i mi ddweud wrthych, onid ydw i? Cyflym iawn. Gall y mewnosodiad yno - 1-2 gigabits yr eiliad, hyrddiau o hyd at 10 gigabits yr eiliad wrthsefyll y cyfluniad hwn mewn gwirionedd - mae dau Xeon 6-craidd (hynny yw, nid hyd yn oed y mwyaf pwerus), 256 gigabeit o RAM, 20 terabytes yn RAID (neb wedi'i ffurfweddu, gosodiadau diofyn). Mae'n debyg bod Alexey Milovidov, datblygwr ClickHouse, yn eistedd yno yn crio oherwydd ni wnaethom ffurfweddu unrhyw beth (roedd popeth yn gweithio felly i ni). Yn unol â hynny, gellir cael cyflymder sganio o, dyweder, tua 6 biliwn o linellau yr eiliad os yw'r data wedi'i gywasgu'n dda. Os ydych chi'n hoffi % ar linyn testun - 100 miliwn o linellau yr eiliad, hynny yw, mae'n ymddangos yn eithaf cyflym.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Sut ydym ni'n mynd i'w fewnosod? Wel, rydych chi'n gwybod bod VK yn defnyddio PHP. Byddwn yn mewnosod o bob gweithiwr PHP trwy HTTP yn “ClickHouse”, yn y tabl MergeTree ar gyfer pob cofnod. Pwy sy'n gweld problem gyda'r cynllun hwn? Am ryw reswm, ni chododd pawb eu dwylo. Gadewch i mi ddweud wrthych.

Yn gyntaf, mae yna lawer o weinyddion - yn unol â hynny, bydd llawer o gysylltiadau (drwg). Yna mae'n well mewnosod data i MergeTree dim mwy nag unwaith yr eiliad. A phwy a wyr pam? Iawn, iawn. Fe ddywedaf ychydig mwy wrthych am hyn. Cwestiwn diddorol arall yw nad ydym yn gwneud dadansoddeg, nid oes angen i ni gyfoethogi'r data, nid oes angen gweinyddwyr canolradd arnom, rydym am fewnosod yn uniongyrchol i “ClickHouse” (yn ddelfrydol - y mwyaf uniongyrchol, gorau oll).

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yn unol â hynny, sut mae mewnosod yn cael ei wneud yn MergeTree? Pam ei bod yn well gosod ynddo ddim yn amlach nag unwaith yr eiliad neu'n llai aml? Y ffaith yw bod "ClickHouse" yn gronfa ddata golofnog ac yn didoli'r data yn nhrefn esgynnol yr allwedd gynradd, a phan fyddwch chi'n gwneud mewnosodiad, mae nifer o ffeiliau'n cael eu creu sydd o leiaf yn hafal i nifer y colofnau y mae'r data wedi'u didoli ynddynt yn nhrefn esgynnol yr allwedd gynradd (crëir cyfeiriadur ar wahân, set o ffeiliau ar ddisg ar gyfer pob mewnosodiad). Yna daw'r mewnosodiad nesaf, ac yn y cefndir fe'u cyfunir yn “raniadau” mwy. Gan fod y data wedi'i ddidoli, mae'n bosibl "uno" dwy ffeil wedi'u didoli heb ddefnyddio llawer o gof.

Ond, fel y gallech ddyfalu, os byddwch chi'n ysgrifennu 10 ffeil ar gyfer pob mewnosodiad, yna bydd ClickHouse (neu'ch gweinydd) yn dod i ben yn gyflym, felly argymhellir ei fewnosod mewn sypiau mawr. Yn unol â hynny, ni wnaethom erioed lansio'r cynllun cyntaf i'w gynhyrchu. Fe wnaethom lansio un ar unwaith, sydd yma Rhif 2 wedi:

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yma dychmygwch fod tua mil o weinyddion yr ydym wedi lansio arnynt, dim ond PHP sydd. Ac ar bob gweinydd mae ein hasiant lleol, y gwnaethom ei alw'n “Kittenhouse”, sy'n cynnal un cysylltiad â “ClickHouse” ac yn mewnosod data bob ychydig eiliadau. Yn mewnosod data nid i MergeTree, ond mewn tabl clustogi, sy'n gwasanaethu'n union i osgoi mewnosod yn uniongyrchol i MergeTree ar unwaith.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Gweithio gyda byrddau byffer

Beth yw e? Mae byrddau byffer yn ddarn o gof sy'n cael ei rwygo (hynny yw, gellir ei fewnosod ynddo'n aml). Maent yn cynnwys sawl darn, ac mae pob un o'r darnau yn gweithio fel byffer annibynnol, ac maent yn cael eu fflysio'n annibynnol (os oes gennych lawer o ddarnau yn y byffer, yna bydd llawer o fewnosodiadau yr eiliad). Mae'n bosibl darllen o'r tablau hyn - yna rydych chi'n darllen undeb cynnwys y byffer a'r tabl rhiant, ond ar hyn o bryd mae'r ysgrifennu wedi'i rwystro, felly mae'n well peidio â darllen oddi yno. Ac mae tablau byffer yn dangos QPS da iawn, hynny yw, hyd at 3 mil o QPS ni fydd gennych unrhyw broblemau o gwbl wrth fewnosod. Mae'n amlwg, os bydd y gweinydd yn colli pŵer, yna gellir colli'r data, oherwydd dim ond yn y cof y cafodd ei storio.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Ar yr un pryd, mae'r cynllun gyda byffer yn cymhlethu ALTER, oherwydd yn gyntaf mae angen i chi ollwng yr hen fwrdd clustogi gyda'r hen gynllun (ni fydd y data'n diflannu yn unrhyw le, oherwydd bydd yn cael ei fflysio cyn i'r bwrdd gael ei ddileu). Yna rydych chi'n “newid” y tabl sydd ei angen arnoch chi ac yn creu'r bwrdd clustogi eto. Yn unol â hynny, er nad oes bwrdd clustogi, ni fydd eich data yn llifo i unrhyw le, ond gallwch ei gael ar ddisg yn lleol o leiaf.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Beth yw Kittenhouse a sut mae'n gweithio?

Beth yw KittenHouse? Mae hwn yn ddirprwy. Tybed pa iaith? Cesglais y pynciau mwyaf hype yn fy adroddiad - “Clickhouse”, Ewch, efallai y byddaf yn cofio rhywbeth arall. Ydy, mae hyn wedi'i ysgrifennu yn Go, oherwydd nid wyf yn gwybod mewn gwirionedd sut i ysgrifennu yn C, nid wyf am wneud hynny.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yn unol â hynny, mae'n cynnal cysylltiad â phob gweinydd a gall ysgrifennu i'r cof. Er enghraifft, os ydym yn ysgrifennu logiau gwall i Clickhouse, yna os nad oes gan Clickhouse amser i fewnosod data (wedi'r cyfan, os yw gormod wedi'i ysgrifennu), yna nid ydym yn chwyddo'r cof - rydym yn taflu'r gweddill allan. Oherwydd os ydym yn ysgrifennu sawl gigabeit yr eiliad o wallau, yna mae'n debyg y gallwn daflu rhai allan. Gall Kittenhouse wneud hyn. Hefyd, gall berfformio danfoniad dibynadwy, hynny yw, ysgrifennu i ddisg ar y peiriant lleol ac unwaith bob tro (yno, unwaith bob cwpl o eiliadau) mae'n ceisio cyflwyno data o'r ffeil hon. Ac ar y dechrau fe wnaethom ddefnyddio'r fformat Gwerthoedd rheolaidd - nid rhyw fformat deuaidd, fformat testun (fel yn SQL rheolaidd).

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Ond yna digwyddodd hyn. Fe wnaethom ddefnyddio danfoniad dibynadwy, ysgrifennu logiau, yna penderfynwyd (roedd yn glwstwr prawf amodol)... Cafodd ei roi allan am sawl awr a'i ddwyn yn ôl i fyny, a dechreuodd mewnosodiad o fil o weinyddion - daeth i'r amlwg bod Clickhouse yn dal i gael “Edefyn ar gysylltiad” - yn unol â hynny, mewn mil o gysylltiadau, mae mewnosodiad gweithredol yn arwain at gyfartaledd llwyth ar y gweinydd o tua mil a hanner. Yn syndod, derbyniodd y gweinydd geisiadau, ond roedd y data yn dal i gael ei fewnosod ar ôl peth amser; ond roedd yn anodd iawn i'r gweinydd ei wasanaethu ...

Ychwanegu nginx

Datrysiad o'r fath ar gyfer y model Thread per connection yw nginx. Fe wnaethom osod nginx o flaen Clickhouse, ar yr un pryd sefydlu cydbwyso ar gyfer dau atgynhyrchiad (cynyddodd ein cyflymder mewnosod 2 waith, er nad yw'n ffaith y dylai hyn fod yn wir) a chyfyngu ar nifer y cysylltiadau â Clickhouse, i'r i fyny'r afon ac, yn unol â hynny, yn fwy , nag mewn 50 o gysylltiadau, mae'n ymddangos nad oes diben mewnosod.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yna sylweddolom fod anfanteision i'r cynllun hwn yn gyffredinol, oherwydd dim ond un nginx sydd gennym yma. Yn unol â hynny, os bydd y nginx hwn yn damwain, er gwaethaf presenoldeb atgynyrchiadau, rydym yn colli data neu, o leiaf, nid ydym yn ysgrifennu yn unrhyw le. Dyna pam y gwnaethom ein cydbwyso llwyth ein hunain. Sylweddolon ni hefyd fod “Clickhouse” yn dal yn addas ar gyfer boncyffion, a dechreuodd y “cythraul” ysgrifennu ei logiau yn “Clickhouse” hefyd - cyfleus iawn, a dweud y gwir. Rydyn ni'n dal i'w ddefnyddio ar gyfer “cythreuliaid” eraill.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yna fe wnaethom ddarganfod y broblem ddiddorol hon: os ydych chi'n defnyddio dull ansafonol o fewnosod yn y modd SQL, mae'n gorfodi parser SQL llawn-fledged seiliedig ar AST, sy'n eithaf araf. Yn unol â hynny, rydym wedi ychwanegu gosodiadau i sicrhau na fydd hyn byth yn digwydd. Fe wnaethom lwytho cydbwyso, gwiriadau iechyd, felly os bydd un yn marw, rydym yn dal i adael y data. Bellach mae gennym gryn dipyn o dablau sydd eu hangen arnom i gael gwahanol glystyrau Clickhouse. Ac fe ddechreuon ni feddwl am ddefnyddiau eraill hefyd - er enghraifft, roedden ni eisiau ysgrifennu logiau o fodiwlau nginx, ond nid ydyn nhw'n gwybod sut i gyfathrebu gan ddefnyddio ein RPC. Wel, hoffwn eu dysgu sut i anfon o leiaf rywsut - er enghraifft, i dderbyn digwyddiadau ar localhost trwy CDU ac yna eu hanfon ymlaen at Clickhouse.

Un cam i ffwrdd o ateb

Dechreuodd y cynllun terfynol edrych fel hyn (pedwerydd fersiwn y cynllun hwn): ar bob gweinydd o flaen Clickhouse mae nginx (ar yr un gweinydd) ac yn syml mae'n dirprwyo ceisiadau i localhost gyda chyfyngiad ar nifer y cysylltiadau o 50 darnau. Ac roedd y cynllun hwn eisoes yn eithaf gweithio, roedd popeth yn eithaf da ag ef.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Buom yn byw fel hyn am tua mis. Roedd pawb yn hapus, fe wnaethon nhw ychwanegu tablau, maen nhw'n ychwanegu, maen nhw'n ychwanegu ... Yn gyffredinol, roedd hi'n amlwg nad oedd y ffordd rydyn ni'n ychwanegu tablau byffer yn optimaidd iawn (gadewch i ni ei roi felly). Gwnaethom 16 darn ym mhob bwrdd a chyfwng fflach o ychydig eiliadau; roedd gennym 20 bwrdd a phob bwrdd yn derbyn 8 mewnosodiad yr eiliad - ac ar y pwynt hwn dechreuodd “Clickhouse”... dechreuodd y cofnodion arafu. Wnaethon nhw ddim hyd yn oed fynd trwy... Roedd gan Nginx yn ddiofyn beth mor ddiddorol, pe bai cysylltiadau'n dod i ben i fyny'r afon, yna byddai'n dychwelyd “502” i bob cais newydd.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

A dyma ni (dwi newydd edrych ar y logiau yn Clickhouse ei hun) tua hanner y cant o geisiadau wedi methu. Yn unol â hynny, roedd defnydd disg yn uchel, roedd llawer o uno. Wel, beth wnes i? Yn naturiol, wnes i ddim trafferthu darganfod pam yn union y daeth y cysylltiad ac i fyny'r afon i ben.

Amnewid nginx gyda dirprwy gwrthdro

Penderfynais fod angen i ni reoli hyn ein hunain, nid oes angen i ni ei adael i nginx - nid yw nginx yn gwybod pa dablau sydd yn Clickhouse, a rhoddais ddirprwy gwrthdro yn lle nginx, a ysgrifennais fy hun hefyd.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Beth mae e'n ei wneud? Mae'n gweithio yn seiliedig ar y llyfrgell fasthttp “goshnoy”, hynny yw, yn gyflym, bron mor gyflym â nginx. Mae'n ddrwg gennyf, Igor, os ydych chi'n bresennol yma (noder: Mae Igor Sysoev yn rhaglennydd Rwsiaidd a greodd y gweinydd gwe nginx). Gall ddeall pa fath o ymholiadau yw'r rhain - INSERT neu SELECT - yn unol â hynny, mae'n dal gwahanol gronfeydd cysylltu ar gyfer gwahanol fathau o ymholiadau.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yn unol â hynny, hyd yn oed os nad oes gennym amser i gwblhau'r ceisiadau mewnosod, bydd y “dewisiadau” yn mynd heibio, ac i'r gwrthwyneb. Ac mae'n grwpio'r data yn dablau byffer - gyda byffer bach: pe bai unrhyw wallau, gwallau cystrawen, ac yn y blaen - fel na fyddent yn effeithio'n fawr ar weddill y data, oherwydd pan fyddwn yn ei fewnosod yn syml mewn tablau byffer, rydym yn wedi bachi "bachi", a'r holl wallau cystrawen yn effeithio ar y darn bach hwn yn unig; ac yma byddant eisoes yn effeithio ar glustog fawr. Bach yw 1 megabeit, hynny yw, nid mor fach.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Mae mewnosod cydamseriad ac yn y bôn amnewid nginx, yn ei hanfod yn gwneud yr un peth ag y gwnaeth nginx o'r blaen - nid oes angen i chi newid y “Kittenhouse” lleol ar gyfer hyn. A chan ei fod yn defnyddio fasthttp, mae'n gyflym iawn - gallwch wneud mwy na 100 mil o geisiadau yr eiliad am fewnosodiadau sengl trwy ddirprwy gwrthdro. Yn ddamcaniaethol, gallwch chi fewnosod un llinell ar y tro i ddirprwy wrthdroi'r kittenhouse, ond wrth gwrs nid ydym yn gwneud hynny.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Dechreuodd y cynllun edrych fel hyn: “Kittenhouse”, mae'r dirprwy gwrthdro yn grwpio llawer o geisiadau yn dablau ac, yn eu tro, mae'r tablau byffer yn eu gosod yn y prif rai.

Ateb dros dro yw Killer, mae Kitten yn barhaol

Mae hon yn broblem ddiddorol... A oes unrhyw un ohonoch wedi defnyddio fasthttp? Pwy ddefnyddiodd fasthttp gyda cheisiadau POST? Yn ôl pob tebyg, ni ddylai hyn fod wedi'i wneud mewn gwirionedd, oherwydd mae'n clustogi'r corff ceisiadau yn ddiofyn, ac mae maint ein byffer wedi'i osod i 16 megabeit. Daeth y mewnosodiad i ben ar ryw adeg, a dechreuodd talpiau 16-megabyte gyrraedd o bob degau o filoedd o weinyddion, a chawsant oll eu clustogi yn y cof cyn eu hanfon i Clickhouse. Yn unol â hynny, daeth y cof i ben, daeth y Lladdwr Allan o'r Cof a lladd y dirprwy gwrthdro (neu “Clickhouse”, a allai, yn ddamcaniaethol, “fwyta” mwy na'r dirprwy gwrthdro). Ailadroddodd y cylch ei hun. Ddim yn broblem ddymunol iawn. Er i ni faglu ar hyn dim ond ar ôl sawl mis o weithredu.

Beth rydw i wedi'i wneud? Unwaith eto, nid wyf yn hoffi deall beth yn union ddigwyddodd. Rwy'n meddwl ei bod yn eithaf amlwg na ddylech glustogi i'r cof. Ni allwn clytio fasthttp, er i mi geisio. Ond fe wnes i ddod o hyd i ffordd i'w wneud fel nad oedd angen clytio dim, a deuthum i fyny gyda fy null fy hun yn HTTP - fe wnes i ei alw KITTEN. Wel, mae'n rhesymegol - "VK", "Kitten"... Beth arall?..

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Os daw cais i'r gweinydd gyda'r dull Kitten, yna dylai'r gweinydd ymateb "meow" - yn rhesymegol. Os yw'n ymateb i hyn, yna ystyrir ei fod yn deall y protocol hwn, ac yna rwy'n rhyng-gipio'r cysylltiad (mae gan fasthttp ddull o'r fath), ac mae'r cysylltiad yn mynd i'r modd “amrwd”. Pam fod ei angen arnaf? Rwyf am reoli sut mae darllen o gysylltiadau TCP yn digwydd. Mae gan TCP briodwedd hyfryd: os nad oes neb yn darllen o'r ochr arall, yna mae'r ysgrifen yn dechrau aros, ac nid yw cof yn cael ei wario'n arbennig ar hyn.

Ac felly yr wyf yn darllen gan tua 50 o gleientiaid ar y tro (o hanner cant oherwydd dylai hanner cant yn bendant fod yn ddigon, hyd yn oed os yw'r gyfradd yn dod o DC arall)... Defnydd wedi gostwng gyda'r dull hwn o leiaf 20 gwaith, ond yr wyf, i fod yn onest , Ni allwn fesur yn union faint o'r gloch, oherwydd mae eisoes yn ddibwrpas (mae eisoes wedi cyrraedd lefel y gwall). Mae'r protocol yn ddeuaidd, hynny yw, mae'n cynnwys enw'r tabl a data; nid oes penawdau http, felly ni ddefnyddiais soced gwe (nid oes angen i mi gyfathrebu â phorwyr - gwnes i brotocol sy'n gweddu i'n hanghenion). A daeth popeth yn iawn gydag ef.

Mae'r bwrdd clustogi yn drist

Yn ddiweddar daethom ar draws nodwedd ddiddorol arall o fyrddau byffer. Ac mae'r broblem hon eisoes yn llawer mwy poenus na'r lleill. Gadewch i ni ddychmygu'r sefyllfa hon: rydych chi eisoes yn defnyddio Clickhouse yn weithredol, mae gennych chi ddwsinau o weinyddion Clickhouse, ac mae gennych chi rai ceisiadau sy'n cymryd amser hir iawn i'w darllen (gadewch i ni ddweud, mwy na 60 eiliad); ac rydych chi'n dod i wneud Alter ar hyn o bryd... Yn y cyfamser, ni fydd “dewisiadau” a ddechreuodd cyn “Alter” yn cael eu cynnwys yn y tabl hwn, ni fydd “Alter” yn dechrau - mae'n debyg rhai nodweddion o sut mae “Clickhouse” yn gweithio yn y lle hwn. Efallai y gellir trwsio hyn? Neu onid yw'n bosibl?

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yn gyffredinol, mae'n amlwg nad yw hon yn broblem mor fawr mewn gwirionedd, ond gyda thablau clustogi mae'n dod yn fwy poenus. Oherwydd, os, gadewch i ni ddweud, eich goramser “Alter” (ac efallai y bydd yn seibio ar westeiwr arall - nid ar eich un chi, ond ar replica, er enghraifft), yna... Rydych chi wedi dileu'r bwrdd byffer, eich “Alter” ( neu ryw westeiwr arall) wedi'i amseru. yna mae gwall "Alter" wedi digwydd) - mae dal angen i chi sicrhau bod y data'n parhau i gael ei ysgrifennu: rydych chi'n creu'r tablau byffer yn ôl (yn ôl yr un cynllun â'r tabl rhiant), yna Mae “Alter” yn mynd drwodd, yn dod i ben wedi'r cyfan, ac mae'r byffer y mae'r bwrdd yn dechrau bod yn wahanol o ran sgema i'r rhiant. Yn dibynnu ar beth oedd yr "Alter", efallai na fydd y mewnosodiad yn mynd i'r bwrdd clustogi hwn mwyach - mae hyn yn drist iawn.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Mae yna arwydd o'r fath hefyd (efallai bod rhywun wedi sylwi arno) - fe'i gelwir yn query_thread_log mewn fersiynau newydd o Clickhouse. Yn ddiofyn, mewn rhai fersiwn roedd un. Yma rydym wedi cronni 840 miliwn o gofnodion mewn ychydig fisoedd (100 gigabeit). Mae hyn oherwydd y ffaith bod “mewnosod” wedi'i ysgrifennu yno (efallai nawr, gyda llaw, nid ydyn nhw wedi'u hysgrifennu). Fel y dywedais wrthych, mae ein “mewnosodiadau” yn fach – cawsom lawer o “fewnosod” yn y byrddau clustogi. Mae'n amlwg bod hyn yn anabl - dwi'n dweud wrthych chi beth welais i ar ein gweinydd. Pam? Dyma ddadl arall yn erbyn defnyddio tablau byffer! Mae Smotyn yn drist iawn.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Pwy wyddai mai enw'r boi yma oedd Spotty? Cododd gweithwyr VK eu dwylo. IAWN.

Am y cynlluniau ar gyfer “KitttenHouse”

Nid yw cynlluniau fel arfer yn cael eu rhannu, iawn? Yn sydyn, ni fyddwch yn eu cyflawni ac ni fyddwch yn edrych yn dda iawn yng ngolwg pobl eraill. Ond byddaf yn cymryd y risg! Rydym am wneud y canlynol: mae byrddau clustogi, mae'n ymddangos i mi, yn dal i fod yn faglau ac mae angen inni glustogi'r gosodiad ein hunain. Ond nid ydym am ei glustogi ar ddisg o hyd, felly byddwn yn clustogi'r mewnosodiad er cof.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Yn unol â hynny, pan fydd “mewnosodiad” yn cael ei wneud, ni fydd yn gydamserol mwyach - bydd eisoes yn gweithio fel bwrdd clustogi, bydd yn mewnosod yn y bwrdd rhiant (wel, ryw ddydd yn ddiweddarach) ac yn adrodd trwy sianel ar wahân y mae mewnosodiadau wedi mynd heibio ac sy'n heb.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Pam na allaf adael y mewnosodiad cydamserol? Mae'n llawer mwy cyfleus. Y ffaith yw, os ydych chi'n mewnosod o 10 mil o westeion, yna mae popeth yn iawn - fe gewch chi ychydig bach gan bob gwesteiwr, rydych chi'n mewnosod yno unwaith yr eiliad, mae popeth yn iawn. Ond hoffwn i'r cynllun hwn weithio, er enghraifft, o ddau beiriant, fel y gallwch chi lawrlwytho ar gyflymder uchel - efallai na fyddwch chi'n cael yr uchafswm allan o Clickhouse, ond yn ysgrifennu o leiaf 100 megabeit yr eiliad o un peiriant trwy ddirprwy gwrthdro - mae'n rhaid i'r cynllun ehangu i feintiau mawr a bach, felly ni allwn aros eiliad ar gyfer pob gosodiad, felly rhaid iddo fod yn anghydamserol. Ac yn yr un modd, dylai cadarnhad asyncronig ddod ar ôl i'r mewnosodiad gael ei gwblhau. Byddwn yn gwybod a basiodd ai peidio.

Y peth pwysicaf yw ein bod yn gwybod yn sicr yn y cynllun hwn a ddigwyddodd y mewnosodiad ai peidio. Dychmygwch y sefyllfa hon: mae gennych fwrdd clustogi, fe wnaethoch chi ysgrifennu rhywbeth ynddo, ac yna, gadewch i ni ddweud, aeth y bwrdd i'r modd darllen yn unig a cheisio fflysio'r byffer. Ble bydd y data yn mynd? Byddant yn aros yn y byffer. Ond ni allwn fod yn sicr o hyn - beth os oes gwall arall, oherwydd ni fydd y data yn aros yn y byffer ... (Cyfeiriadau Alexey Milovidov, Yandex, datblygwr ClickHouse) Neu a fydd yn aros? Bob amser? Mae Alexey yn ein hargyhoeddi y bydd popeth yn iawn. Nid oes gennym unrhyw reswm i beidio â'i gredu. Ond yr un peth: os na ddefnyddiwn dablau clustogi, yna ni fydd unrhyw broblemau gyda nhw. Mae creu dwywaith cymaint o fyrddau hefyd yn anghyfleus, er nad oes unrhyw broblemau mawr mewn egwyddor. Dyma'r cynllun.

Gadewch i ni siarad am ddarllen

Nawr gadewch i ni siarad am ddarllen. Fe wnaethom hefyd ysgrifennu ein hofferyn ein hunain yma. Mae'n ymddangos, wel, pam ysgrifennu eich offeryn eich hun yma?.. A phwy ddefnyddiodd Tabix? Rhywsut ychydig o bobl a gododd eu dwylo... A phwy sy'n fodlon ar berfformiad Tabix? Wel, nid ydym yn hapus ag ef, ac nid yw'n gyfleus iawn ar gyfer gwylio data. Mae'n iawn ar gyfer dadansoddeg, ond dim ond ar gyfer gwylio mae'n amlwg nad yw wedi'i optimeiddio. Felly ysgrifennais fy rhyngwyneb fy hun, fy hun.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Mae'n syml iawn - dim ond darllen data y gall. Nid yw'n gwybod sut i ddangos graffeg, nid yw'n gwybod sut i wneud unrhyw beth. Ond gall ddangos yr hyn sydd ei angen arnom: er enghraifft, faint o resi sydd yn y tabl, faint o le y mae'n ei gymryd (heb ei dorri i lawr yn golofnau), hynny yw, rhyngwyneb sylfaenol iawn yw'r hyn sydd ei angen arnom.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Ac mae'n edrych yn debyg iawn i Sequel Pro, ond dim ond wedi'i wneud ar Twitter Bootstrap, a'r ail fersiwn. Rydych chi'n gofyn: "Yuri, pam ar yr ail fersiwn?" Pa flwyddyn? 2018? Yn gyffredinol, fe wnes i hyn amser maith yn ôl ar gyfer “Muscle” (MySQL) a newid ychydig o linellau yn yr ymholiadau yno, a dechreuodd weithio i “Clickhouse”, a diolch arbennig am hynny! Oherwydd bod y parser yn debyg iawn i'r un "cyhyr", ac mae'r ymholiadau yn debyg iawn - yn gyfleus iawn, yn enwedig ar y dechrau.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Wel, mae'n gallu hidlo tablau, yn gallu dangos strwythur a chynnwys y tabl, yn caniatáu ichi ddidoli, hidlo yn ôl colofnau, yn dangos yr ymholiad a arweiniodd at y canlyniad, y rhesi yr effeithiwyd arnynt (faint o ganlyniad), hynny yw, y pethau sylfaenol ar gyfer gwylio data. Eithaf cyflym.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Mae yna hefyd olygydd. Ceisiais yn onest ddwyn y golygydd cyfan o Tabix, ond allwn i ddim. Ond rhywsut mae'n gweithio. Mewn egwyddor, dyna i gyd.

Mae "Clickhouse" yn addas ar gyfer cuddfannau

Rwyf am ddweud wrthych fod Clickhouse, er gwaethaf yr holl broblemau a ddisgrifiwyd, yn addas iawn ar gyfer logiau. Yn bwysicaf oll, mae'n datrys ein problem - mae'n gyflym iawn ac yn caniatáu ichi hidlo logiau yn ôl colofnau. Mewn egwyddor, nid yw byrddau byffer wedi perfformio'n dda, ond fel arfer does neb yn gwybod pam... Efallai nawr eich bod chi'n gwybod yn well lle bydd gennych chi broblemau.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

TCP? Yn gyffredinol, yn VK mae'n arferol defnyddio CDU. A phan ddefnyddiais TCP... Wrth gwrs, ni ddywedodd neb wrthyf: “Yuri, am beth rydych chi'n siarad! Ni allwch, mae angen CDU arnoch chi.” Mae'n troi allan nad yw TCP mor frawychus. Yr unig beth yw, os oes gennych chi ddegau o filoedd o gyfansoddion gweithredol yr ydych chi'n eu hysgrifennu, mae angen i chi ei baratoi ychydig yn fwy gofalus; ond y mae yn bosibl, ac yn bur hawdd.

Addewais bostio “Kittenhouse” a “Goleudy” ar HighLoad Siberia pe bai pawb yn tanysgrifio i'n “backend VK” cyhoeddus... A wyddoch chi, nid yw pawb wedi tanysgrifio... Wrth gwrs, ni fyddaf yn mynnu eich bod yn tanysgrifio i'n cyhoeddus. Mae yna ormod ohonoch chi o hyd, efallai y bydd rhywun hyd yn oed yn tramgwyddo, ond yn dal i fod, tanysgrifiwch (a dyma mae'n rhaid i mi wneud llygaid fel rhai cath). Dyna cysylltu ag ef gyda llaw. Diolch yn fawr iawn! Github yw ein un ni yma. Gyda Clickhouse bydd eich gwallt yn feddal ac yn sidanaidd.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Arwain: - Gyfeillion, yn awr am gwestiynau. Yn union ar ôl i ni gyflwyno'r dystysgrif gwerthfawrogiad a'ch adroddiad ar VHS.

Yuri Nasretdinov (y cyfeirir ati o hyn ymlaen fel YN): – Sut oeddech chi’n gallu cofnodi fy adroddiad ar VHS os oedd newydd ddod i ben?

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Arwain: - Ni allwch hefyd benderfynu'n llawn sut y bydd “Clickhouse” yn gweithio ai peidio! Gyfeillion, 5 munud ar gyfer cwestiynau!

cwestiynau

Cwestiwn gan y gynulleidfa (y cyfeirir ato o hyn ymlaen fel C): - Prynhawn Da. Diolch yn fawr iawn am yr adroddiad. Mae gennyf ddau gwestiwn. Dechreuaf gyda rhywbeth gwamal: a yw nifer y llythrennau t yn yr enw "Kittenhouse" yn y diagramau (3, 4, 7...) yn effeithio ar foddhad y cathod?

YN: - Nifer o beth?

Z: — Llythyr t. Mae tri t, rhywle tua thri t.

YN: - Wnes i ddim ei drwsio? Wel, wrth gwrs mae'n ei wneud! Mae'r rhain yn gynhyrchion gwahanol - roeddwn i'n eich twyllo chi i gyd y tro hwn. Iawn, rwy'n kidding - does dim ots. Ah, yma! Na, yr un peth ydyw, gwnes i deipo.

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Z: - Diolch. Mae'r ail gwestiwn yn ddifrifol. Cyn belled ag y deallaf, yn Clickhouse, mae byrddau byffer yn byw yn y cof yn unig, nid ydynt wedi'u clustogi i ddisg ac, yn unol â hynny, nid ydynt yn barhaus.

YN: - Ydw.

Z: - Ac ar yr un pryd, mae'ch cleient yn clustogi i ddisg, sy'n awgrymu rhywfaint o warant o gyflwyno'r un logiau hyn. Ond nid yw hyn wedi'i warantu o bell ffordd yn Clickhouse. Eglurwch sut mae'r warant yn cael ei chyflawni, oherwydd beth?.. Dyma'r mecanwaith hwn yn fwy manwl

YN: - Oes, yn ddamcaniaethol nid oes unrhyw wrthddywediadau yma, oherwydd pan fydd Clickhouse yn cwympo, gallwch chi ei ganfod mewn miliwn o wahanol ffyrdd. Os bydd Clickhouse yn chwalu (os yw'n dod i ben yn anghywir), gallwch, yn fras, ailddirwyn ychydig o'ch log a ysgrifennwyd gennych a dechrau o'r eiliad pan oedd popeth yn iawn. Gadewch i ni ddweud eich bod yn ailddirwyn munud, hynny yw, ystyrir eich bod wedi fflysio popeth mewn munud.

Z: - Hynny yw, mae “Kittenhouse” yn dal y ffenestr yn hirach ac, rhag ofn y bydd cwymp, yn gallu ei hadnabod a'i hailddirwyn?

YN: - Ond mae hyn mewn theori. Yn ymarferol, nid ydym yn gwneud hyn, ac mae darpariaeth ddibynadwy o sero i gyfnod anfeidredd. Ond un ar gyfartaledd. Rydym yn fodlon, os bydd Clickhouse yn damwain am ryw reswm neu fod y gweinyddwyr yn “ailgychwyn,” yna byddwn yn colli ychydig. Ym mhob achos arall, ni fydd dim yn digwydd.

Z: - Helo. O'r cychwyn cyntaf roedd yn ymddangos i mi y byddech yn wir yn defnyddio CDU o ddechrau'r adroddiad. Mae gennych chi http, hynny i gyd... Ac yn ôl yr hyn a ddeallaf, achoswyd y rhan fwyaf o'r problemau a ddisgrifiwyd gennych gan yr ateb penodol hwn...

YN: – Beth ydyn ni'n defnyddio TCP?

Z: - Yn y bôn ie.

YN: - Ddim.

Z: – Gyda fasthttp y cawsoch broblemau, gyda'r cysylltiad roedd gennych broblemau. Pe baech newydd ddefnyddio CDU byddech wedi arbed peth amser i chi'ch hun. Wel, byddai problemau gyda negeseuon hir neu rywbeth arall...

YN: - Gyda beth?

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Z: – Gyda negeseuon hir, oherwydd efallai na fydd yn ffitio i'r MTU, rhywbeth arall... Wel, efallai y bydd problemau eu hunain. Y cwestiwn yw: pam ddim CDU?

YN: - Rwy'n credu bod yr awduron a ddatblygodd TCP / IP yn llawer callach na mi ac yn gwybod yn well na mi sut i gyfresoli pecynnau (fel eu bod yn mynd), ar yr un pryd addasu'r ffenestr anfon, nid gorlwytho'r rhwydwaith, rhoi adborth ar beth Nid yw'n cael ei ddarllen, nid yn cyfrif ar yr ochr arall... Byddai'r holl broblemau hyn, yn fy marn i, yn bodoli yn y CDU, dim ond byddai'n rhaid i mi ysgrifennu hyd yn oed mwy o god nag a ysgrifennais eisoes er mwyn gweithredu'r un peth fy hun ac yn fwyaf tebygol yn wael. Dydw i ddim hyd yn oed yn hoffi ysgrifennu yn C, heb sôn am yno...

Z: - Dim ond cyfleus! Wedi'i anfon yn iawn a pheidiwch ag aros am unrhyw beth - mae'n gwbl anghydamserol. Daeth hysbysiad yn ôl bod popeth yn iawn - mae hynny'n golygu ei fod wedi cyrraedd; Os na ddaw, mae'n golygu ei fod yn ddrwg.

YN: – Mae angen y ddau arnaf – mae angen i mi allu anfon y ddau gyda gwarant danfon a heb warant danfon. Mae'r rhain yn ddau senario gwahanol. Mae angen i mi beidio â cholli rhai logiau neu beidio â'u colli o fewn rheswm.

Z: - Ni fyddaf yn gwastraffu amser. Mae angen trafod hyn yn fwy. Diolch.

Arwain: - Pwy sydd â chwestiynau - dwylo i'r awyr!

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

Z: - Helo, Sasha ydw i. Rhywle yng nghanol yr adroddiad, roedd teimlad yn ymddangos, yn ogystal â TCP, ei bod yn bosibl defnyddio datrysiad parod - rhyw fath o Kafka.

YN: - Wel ... dywedais wrthych nad wyf am ddefnyddio gweinyddwyr canolradd, oherwydd ... yn Kafka, mae'n troi allan bod gennym ddeng mil o westeion; mewn gwirionedd, mae gennym fwy - degau o filoedd o westeion. Gall hefyd fod yn boenus i'w wneud â Kafka heb unrhyw ddirprwy. Yn ogystal, yn bwysicaf oll, mae'n dal i roi “latency”, mae'n rhoi gwesteiwyr ychwanegol y mae angen i chi eu cael. Ond dwi ddim eisiau eu cael nhw - dwi eisiau...

Z: “Ond yn y diwedd fe drodd allan felly beth bynnag.”

YN: - Na, nid oes unrhyw westeion! Mae hyn i gyd yn gweithio ar westeion Clickhouse.

Z: — Wel, a “Kittenhouse”, sef y gwrthwyneb — pa le y mae yn byw ?

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

YN: - Ar y gwesteiwr Clickhouse, nid yw'n ysgrifennu unrhyw beth i'r ddisg.

Z: — Gadewch i ni dybied.

Arwain: - Ydych chi'n fodlon? A allwn ni roi cyflog i chi?

Z: - Wyt, ti'n gallu. Mewn gwirionedd, mae yna lawer o faglau er mwyn cael yr un peth, ac yn awr - mae'r ateb blaenorol ar y pwnc o TCP yn gwrth-ddweud, yn fy marn i, y sefyllfa hon. Mae'n teimlo y gallai popeth fod wedi'i wneud ar fy ngliniau mewn llawer llai o amser.

YN: - A hefyd pam nad oeddwn i eisiau defnyddio Kafka, oherwydd roedd cryn dipyn o gwynion yn sgwrs Clickhouse Telegram bod, er enghraifft, negeseuon Kafka wedi'u colli. Nid o Kafka ei hun, ond wrth integreiddio Kafka a Clickhaus; neu rywbeth nad oedd yn cysylltu yno. Yn fras, byddai angen ysgrifennu cleient i Kafka bryd hynny. Dydw i ddim yn meddwl y gallai fod ateb symlach na mwy dibynadwy.

Z: – Dywedwch wrthyf, pam na wnaethoch chi roi cynnig ar unrhyw giwiau neu ryw fath o fws cyffredin? Gan eich bod yn dweud y gallech anfon y boncyffion eu hunain drwy'r ciw gyda asyncronig a derbyn yr ymateb yn asyncronig trwy'r ciw?

HighLoad++, Yuri Nasretdinov (VKontakte): sut mae VK yn mewnosod data i ClickHouse o ddegau o filoedd o weinyddion

YN: – Awgrymwch pa giwiau y gellid eu defnyddio?

Z: – Unrhyw un, hyd yn oed heb warant eu bod mewn trefn. Rhyw fath o Redis, RMQ...

YN: - Mae gen i deimlad na fydd Redis yn fwyaf tebygol yn gallu tynnu cymaint o fewnosodiad hyd yn oed ar un gwesteiwr (yn ystyr sawl gweinydd) sy'n tynnu Clickhouse allan. Ni allaf ategu hyn gydag unrhyw dystiolaeth (nid wyf wedi ei feincnodi), ond mae'n ymddangos i mi nad Redis yw'r ateb gorau yma. Mewn egwyddor, gellir ystyried y system hon fel ciw negeseuon byrfyfyr, ond sydd wedi'i deilwra ar gyfer “Clickhouse” yn unig.

Arwain: - Yuri, diolch yn fawr iawn. Cynigiaf derfynu’r cwestiynau a’r atebion yma a dweud i ba rai o’r rhai a ofynnodd y cwestiwn y byddwn yn rhoi’r llyfr.

YN: – Hoffwn roi llyfr i’r person cyntaf a ofynnodd gwestiwn.

Arwain: - Gwych! Gwych! Gwych! Diolch yn fawr!

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, cwmwl VPS i ddatblygwyr o $4.99, analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: Y gwir i gyd am VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps o $ 19 neu sut i rannu gweinydd? (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 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV o $199 yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am Sut i adeiladu seilwaith Corp. dosbarth gyda'r defnydd o weinyddion Dell R730xd E5-2650 v4 gwerth 9000 ewro am geiniog?

Ffynhonnell: hab.com

Ychwanegu sylw