Di van çend salên borî de, databasên rêze-dem ji tiştek xerîb (pir pispor an di pergalên çavdêriya vekirî (û bi çareseriyên taybetî ve girêdayî ye) an jî di projeyên Daneyên Mezin de têne bikar anîn) veguherî "hilberek xerîdar". Li ser axa Federasyona Rûsyayê, ji bo vê yekê divê spasiyên taybetî ji Yandex û ClickHouse re bêne kirin. Heya vê nuqteyê, heke we hewce bû ku hûn hejmareke mezin ji daneyên rêze-dem hilînin, we pêdivî bû ku hûn hewcedariya avakirina stûnek Hadoop-a cinawirdar bikin û wê biparêzin, an jî bi protokolên kesane yên ji bo her pergalê re têkilî daynin.
Dibe ku di sala 2019-an de gotarek ku TSDB hêja ye ku bikar bîne dê ji yek hevokê pêk were: "tenê ClickHouse bikar bînin." Lê... nuans hene.
Bi rastî, ClickHouse bi rengek çalak pêş dikeve, bingeha bikarhêner mezin dibe, û piştgirî pir çalak e, lê gelo em bûne rehînên serkeftina giştî ya ClickHouse, ya ku çareseriyên din, belkî bi bandortir / pêbawertir siya kiriye?
Di destpêka sala borî de, me dest bi ji nû ve xebitandina pergala xweya çavdêriyê kir, di dema ku pirsa hilbijartina databasek guncaw ji bo hilanîna daneyan derket holê. Ez dixwazim li vir qala dîroka vê hilbijartinê bikim.
Formulkirina pirsgirêkê
Berî her tiştî, pêşgotinek pêwîst. Çima em bi tevahî pergala çavdêriya xwe hewce ne û ew çawa hate sêwirandin?
Me di sala 2008-an de dest bi peydakirina karûbarên piştgiriyê kir, û heya 2010-an eşkere bû ku bi çareseriyên ku di wê demê de hebûn (em li ser dipeyivin, Xwedê li min bibore, Cacti, Zabbix û Grafîtê ku derdikeve holê).
Pêdiviyên me yên sereke ev bûn:
- piştgirî (di wê demê de - bi dehan, û di pêşerojê de - bi sedan) xerîdar di nav yek pergalê de û di heman demê de hebûna pergalek rêveberiya hişyariya navendî;
- nermbûn di birêvebirina pergala hişyariyê de (zêdebûna hişyariyan di navbera efserên peywirê de, bername, bingeha zanînê);
- şiyana hûrgulîkirina grafîkan (Zabbix wê demê grafîkan di forma wêneyan de pêşkêş dikir);
- hilanîna demdirêj a mîqdarek mezin a daneyan (salek an jî zêdetir) û şiyana ku zû vegere wê.
Di vê gotarê de em bala xwe didin xala dawî.
Di derbarê depokirinê de, hewcedarî wiha bûn:
- divê sîstem bi lez bixebite;
- tê xwestin ku pergal pêwendiyek SQL hebe;
- pêdivî ye ku pergal aram be û xwedan bingehek bikarhêner û piştgirîyek çalak be (dema ku em bi hewcedariya piştgirîkirina pergalên mîna MemcacheDB, ku nema pêşkeftî bû, an hilana belavkirî ya MooseFS, ku şopînerê xeletiyê bi Chineseînî hate hilanîn, rû bi rû mabûn: em vê çîrokê dubare dikin ji bo projeya me nexwest);
- lihevhatina bi teorema CAP-ê: Tevhevî (pêdivî) - divê dane nûjen bin, em naxwazin ku pergala rêveberiya hişyariyê daneyên nû nestîne û hişyariyên der barê negihîştina daneyan ji bo hemî projeyan derxe; Tolerasyona Parvekirinê (pêdivî ye) - em naxwazin pergalek Mejiyê Split bistînin; Hebûn (ne krîtîk, heke kopiyek çalak hebe) - em dikarin di bûyerek qezayê de, bi karanîna kodê, bi xwe veguhezînin pergala hilanînê.
Pir ecêb e, di wê demê de MySQL ji bo me bû çareseriya îdeal. Struktura daneyên me pir hêsan bû: id server, id counter, timestamp û nirx; Nimûneya bilez a daneyên germ ji hêla hewzek tamponek mezin ve hate piştrast kirin, û nimûneya daneyên dîrokî ji hêla SSD ve hate piştrast kirin.
Bi vî rengî, me nimûneyek daneyên nû yên du-hefte, bi hûrgulî heya duyemîn 200 ms berî ku dane bi tevahî were pêşkêş kirin, bi dest xistin, û demek pir dirêj di vê pergalê de jiya.
Di vê navberê de, dem derbas bû û hêjmara daneyan mezin bû. Di sala 2016-an de, cildên daneyê gihîştin bi dehan terabytes, ku di çarçoweya hilanîna SSD-ya kirê de lêçûnek girîng bû.
Di vê demê de, databasên stûnê bi rengek çalak belav bûbûn, ku me dest bi çalak li ser fikirîn: di databasên stûnî de, dane têne hilanîn, wekî ku hûn fêm dikin, di stûnan de têne hilanîn, û heke hûn li daneyên me binihêrin, hêsan e ku meriv li daneya mezin bibîne. hejmara dubareyên ku dikarin, di Heke hûn danegehek stûnek bikar tînin, wê bi karanîna pêvekirinê bişkînin.
Lêbelê, pergala sereke ya pargîdaniyê bi îstîqrar xebata xwe domand, û min nexwest ku ez bi veguheztina tiştek din biceribînim.
Di sala 2017-an de, di konferansa Percona Live de li San Jose, pêşdebirên Clickhouse belkî ji bo yekem car xwe ragihandin. Di nihêrîna pêşîn de, pergal amade-hilberînê bû (baş e, Yandex.Metrica pergalek hilberandina hişk e), piştgirî zû û hêsan bû, û ya herî girîng, xebitandin hêsan bû. Ji sala 2018’an ve me dest bi pêvajoya derbasbûnê kiriye. Lê di wê demê de, gelek pergalên TSDB-ê yên "mezin" û dem-ceribandinî hebûn, û me biryar da ku em demek girîng veqetînin û alternatîfan bidin ber hev da ku em pê ewle bin ku li gorî daxwazên me çareseriyên alternatîf ên Clickhouse tune.
Digel hewcedariyên hilanînê yên jixwe hatine destnîşan kirin, yên nû derketine:
- pergala nû divê bi kêmanî heman performansa MySQL li ser heman hejmarê hardware peyda bike;
- hilanîna pergala nû divê cîhê girîng kêmtir bigire;
- Divê DBMS hîn jî hêsan be ku were rêvebirin;
- Min xwest dema ku DBMS-ê diguhezîne serîlêdanê hindik biguhezim.
Me dest bi nirxandina kîjan pergalê kir?
Apache Hive / Apache Impala
Stackek Hadoop a kevn, ceribandin-ceribandin. Di bingeh de, ew navgînek SQL ye ku li ser hilanîna daneyan di formatên xwemalî de li ser HDFS hatî çêkirin.
Pros.
- Bi operasyona stabîl re, pîvandina daneyan pir hêsan e.
- Ji bo hilanîna daneyê (kêm cîh) çareseriyên stûnê hene.
- Dema ku çavkanî hebin pêkanîna pir bilez a karên paralel.
Cons
- Ew Hadoop e, û karanîna wê dijwar e. Ger em ne amade bin ku çareseriyek amade di ewrê de bavêjin (û em di warê lêçûnê de ne amade ne), pêdivî ye ku tevahiya stack ji hêla destên rêvebiran ve were berhev kirin û piştgirî kirin, û em bi rastî jî naxwazin. ev.
- Daneyên berhevkirî ye .
Lêbelê:
Lezbûn bi pîvandina hejmara pêşkêşkerên komputerê tê bidestxistin. Bi hêsanî, heke em pargîdaniyek mezin in, bi analîtîk ve mijûl dibin, û ji bo karsaziyê girîng e ku agahdariya bi lez û bez berhev bike (tevî lêçûna karanîna hejmareke mezin a çavkaniyên hesabkirinê), dibe ku ev bijareya me be. Lê em ne amade bûn ku fîloya hardware zêde bikin da ku karan bilezînin.
Druid/Pinot
Di derbarê TSDB-ê de bi taybetî pir zêde heye, lê dîsa, stacka Hadoop.
Ð • n, Nûh * de .
Bi çend peyvan: Druid / Pinot ji Clickhouse çêtir xuya dike di rewşên ku:
- Xwezaya we ya heterojen a daneyan heye (di rewşa me de, em tenê rêzikên metrîkên serverê tomar dikin, û bi rastî, ev tabloyek e. Lê dibe ku rewşên din jî hebin: rêzikên dema alavên, rêzikên dema aborî, hwd. - her yek bi strukturê xwe, ku pêdivî ye ku were berhev kirin û pêvajo kirin).
- Wekî din, gelek ji van daneyan hene.
- Tablo û daneyên bi rêzikên demê xuya dibin û winda dibin (ango hin komek dane hatine, hatine analîz kirin û jêbirin).
- Pîvanek zelal tune ku bi kîjan daneyan dikare were dabeş kirin.
Di rewşên berevajî de, ClickHouse çêtir dike, û ev doza me ye.
clickhouse
- SQL-wek
- Birêvebirina hêsan.
- Mirov dibêje qey kar dike.
Ji bo ceribandinê tê navnîşa kurtkirî.
InfluxDB
Alternatîfek biyanî ya ClickHouse. Ji kêmasiyan: Hebûna Bilind tenê di guhertoya bazirganî de heye, lê pêdivî ye ku ew were berhev kirin.
Ji bo ceribandinê tê navnîşa kurtkirî.
Cassandra
Ji aliyek ve, em dizanin ku ew ji bo hilanîna rêzikên demjimêrên metrîk ji hêla pergalên çavdêriyê yên weha ve tê bikar anîn, mînakî, an jî OkMeter. Lêbelê, taybetmendî hene.
Cassandra di wateya kevneşopî de ne databasek stûnek e. Ew bêtir wekî dîmenek rêzek xuya dike, lê her rêzek dikare hejmareke cûda stûnan hebe, ku organîzekirina dîmenek stûnek hêsan dike. Di vê wateyê de, diyar e ku bi sînorê 2 mîlyar stûnan, gengaz e ku hin daneyan di stûnan de (û heman rêzikên demê) werin hilanîn. Mînakî, di MySQL de sînorek ji 4096 stûnan heye û heke hûn hewl bidin ku heman tiştî bikin hêsan e ku meriv bi koda 1117-ê xeletiyek biteqe.
Motora Cassandra balê dikişîne ser hilanîna mîqdarên mezin ên daneyê di pergalek belavkirî de bêyî master, û teorema Cassandra CAP ya jorîn li ser AP-ê ye, ango li ser hebûna daneyê û berxwedana dabeşkirinê. Ji ber vê yekê, heke hûn tenê hewce ne ku li vê databasê binivîsin û kêm kêm jê bixwînin ev amûr dikare mezin be. Û li vir mentiqî ye ku meriv Cassandra wekî depoyek "sar" bikar bîne. Ango, wekî cîhek demdirêj, pêbawer ji bo hilanîna mîqdarên mezin ên daneyên dîrokî yên ku kêm hewce ne, lê ger hewce be dikarin werin vegerandin. Lêbelê, ji bo tambûnê, em ê wê jî biceribînin. Lê, wekî ku min berê jî got, xwestek tune ku bi rengek çalak kodê ji bo çareseriya databasê ya bijartî ji nû ve binivîsin, ji ber vê yekê em ê wê hinekî bi sînor biceribînin - bêyî ku strukturên databasê bi taybetmendiyên Cassandra re biguncînin.
Prometheus
Welê, ji meraqê, me biryar da ku em performansa hilanîna Prometheus biceribînin - tenê ji bo ku em fam bikin ka em ji çareseriyên heyî zûtir an hêdîtir in û bi çi qas.
Methodolojiya ceribandinê û encamên
Ji ber vê yekê, me 5 databases di 6 vesazên jêrîn de ceriband: ClickHouse (1 node), ClickHouse (tabloya belavkirî ji bo 3 girêkan), InfluxDB, Mysql 8, Cassandra (3 nod) û Prometheus. Plana testê wiha ye:
- ji bo hefteyekê daneyên dîrokî barkirin (rojê 840 mîlyon nirx; 208 hezar metris);
- em barek tomarkirinê çêdikin (6 modên barkirinê hatin hesibandin, li jêr binêrin);
- Paralel bi tomarkirinê re, em periyodîk hilbijartinan çêdikin, daxwazên bikarhênerek ku bi nexşeyan re dixebite emûl dikin. Ji bo ku em tiştan pir tevlihev nekin, me hefteyek ji bo 10 metrîkan (ew tam li ser grafiya CPU-yê çend hene) dane hilbijartin.
Em bi emelkirina tevgerê çavdêriya xwe, ku her 15 saniyeyan carekê nirxan ji her metrikê re dişîne bar dikin. Di heman demê de, em bala xwe didin cûda:
- hejmara giştî ya metrîkên ku dane tê de têne nivîsandin;
- navber ji bo şandina nirxan ji yek metrikê;
- mezinahiya hevîrê.
Li ser mezinahiya hevîrê. Ji ber ku nayê pêşniyar kirin ku em hema hema hemî databasên xwe yên ceribandinê bi lêkdankên yekane bar bikin, em ê hewceyê relayek ku metrîkên hatîn berhev bike û wan di koman de kom bike û wan li databasê wekî pêvekek berhevokê binivîsîne.
Di heman demê de, ji bo ku em çêtir fam bikin ka meriv wê hingê çawa daneyên wergirtî şîrove dike, em bifikirin ku em ne tenê komek metrîkan dişînin, lê metrîk di nav serveran de têne organîze kirin - 125 metrîk ji bo serverê. Li vir server tenê saziyek virtual e - tenê ji bo ku fêm bikin ku, mînakî, 10000 metrîk bi qasî 80 serveran re têkildar in.
Û li vir, bi girtina van hemîyan, 6 awayên barkirina nivîsandina databasa me hene:
Li vir du xal hene. Ya yekem, ji bo Cassandra ev mezinahiyên berhevokê pir mezin derketin, li wir me nirxên 50 an 100 bikar anîn. Ya duyemîn jî, ji ber ku Prometheus bi hişkî di moda kişandinê de dixebite, yanî. ew bi xwe diçe û daneyan ji çavkaniyên metrîkan berhev dike (û tewra pushgateway, tevî navê, bi bingehîn rewşê naguhezîne), barkirinên têkildar bi karanîna tevhevek mîhengên statîk ve hatine bicîh kirin.
Encamên testê wiha ne:
Ya ku hêjayî gotinê ye: Nimûneyên bi lez û bez ji Prometheus, nimûneyên pir hêdî ji Cassandra, nimûneyên hêdî hêdî ji InfluxDB; Di warê leza tomarkirinê de, ClickHouse her kes bi dest xist, û Prometheus beşdarî pêşbirkê nabe, ji ber ku ew bi xwe navdêran çêdike û em tiştek napîvin.
Di encama vê çalakiyê,: ClickHouse û InfluxDB xwe wekî çêtirîn nîşan dan, lê komek ji Influx tenê dikare li ser bingeha guhertoya Enterprise, ku drav lê dike, were çêkirin, dema ku ClickHouse çu tişt nabe û li Rûsyayê tê çêkirin. Ev mentiqî ye ku li Dewletên Yekbûyî bijare belkî di berjewendiya inInfluxDB de ye, û li welatê me ew di berjewendiya ClickHouse de ye.
Source: www.habr.com