Ew dibêjin ku di jiyanê de her tişt bi kêmanî carekê hêjayî ceribandinê ye. Û heke hûn bi karûbarê DBMS-ên peywendîdar re bikar tînin, wê hingê hêja ye ku hûn di pratîkê de bi NoSQL re nas bikin, berî her tiştî, bi kêmanî ji bo pêşkeftina gelemperî. Naha, ji ber pêşkeftina bilez a vê teknolojiyê, li ser vê mijarê gelek ramanên nakokî û nîqaşên germ hene, ku bi taybetî berjewendiyê geş dike.
Ger hûn di eslê van hemî nakokiyan de kûr bibin, hûn dikarin bibînin ku ew ji ber nêzîkatiya xelet derdikevin. Yên ku databasên NoSQL tam li cîhê ku hewce ne bikar tînin, razî ne û hemî avantajên ji vê çareseriyê distînin. Û ceribandinên ku xwe dispêrin vê teknolojiyê wekî panacea ku ew bi tevahî nayê sepandin, bêhêvî dibin, bêyî ku bigihîjin feydeyên girîng, hêza databasên têkildar winda kirine.
Ez ê ji we re qala ezmûna me ya di pêkanîna çareseriyek li ser bingeha Cassandra DBMS-ê de bikim: em bi çi re rû bi rû mabûn, em çawa ji rewşên dijwar derketin, gelo me karîbû ji karanîna NoSQL sûd werbigirin û li ku derê me neçar ma ku hewildan / fonên din razînin. .
Karê destpêkê avakirina pergalek e ku bangan di cûreyek hilanînê de tomar dike.
Prensîba xebatê ya pergalê wiha ye. Input pelên bi avahiyek taybetî heye ku avahiya bangê diyar dike. Dûv re serîlêdan piştrast dike ku ev avahî di stûnên guncan de tê hilanîn. Di pêşerojê de, bangên tomarkirî têne bikar anîn da ku agahdariya li ser xerckirina seyrûseferê ji bo aboneyan (biha, bang, dîroka hevsengiyê) nîşan bidin.
Pir eşkere ye ku çima wan Cassandra hilbijart - ew mîna mîtralyozek dinivîse, bi hêsanî berbelav e, û xelet-tolerans e.
Ji ber vê yekê, ev e ya ku ezmûn da me
Erê, nodek têkçûyî ne trajediyek e. Ev cewhera tolerasyona xeletiya Cassandra ye. Lebê girêkek dikare zindî be û di heman demê de di performansê de dest bi cefayê bike. Wekî ku derket holê, ev tavilê bandorê li performansa tevahiya komê dike.
Cassandra dê we neparêze cihê ku Oracle we bi astengên xwe xilas kir. Û heke nivîskarê serîlêdanê ev yek pêşwext fêm nekir, wê hingê ducara ku ji bo Cassandra gihîştiye ji ya orîjînal ne xirabtir e. Dema ku ew hat, em ê têxin hundur.
IB bi tundî ji Cassandra ya belaş ji qutiyê nefret kir: Têketina kiryarên bikarhêneran, cûdahiya mafan tune. Agahdariya di derbarê bangan de wekî daneyên kesane têne hesibandin, ku tê vê wateyê ku hemî hewildanên daxwazkirina / guheztina wê bi her awayî divê bi îhtîmala lênihêrîna paşîn re bêne tomar kirin. Di heman demê de, hûn hewce ne ku ji hewcedariya veqetandina mafên di astên cûda de ji bo bikarhênerên cihêreng haydar bin. Endezyarek xebitandinê ya hêsan û rêveberek super ku dikare bi serbestî tevahiya cîhê key jêbirin, rolên cihêreng, berpirsiyariyên cihêreng û jêhatî ne. Bêyî cûdabûnek wusa ya mafên gihîştinê, nirx û yekparebûna daneyê dê tavilê ji asta hevrêziya ANY zûtir bikeve nav pirsê.
Me hesab nekir ku bang ji bo cûrbecûr şert û mercan hem analîtîkên cidî û hem jî nimûneyên periyodîk hewce dike. Ji ber ku dûv re tê xwestin ku tomarên hilbijartî werin jêbirin û ji nû ve werin nivîsandin (wek beşek ji peywirê, divê em piştgiriyê bidin pêvajoya nûvekirina daneyan dema ku dane destpêkê xelet ketin lûleya me), Cassandra ne hevalê me ye li vir. Cassandra mîna bankek berazan e - danîna tiştan hêsan e, lê hûn nekarin tê de bijmêrin.
Me di veguheztina daneyan de li herêmên ceribandinê bi pirsgirêkek re rû bi rû ma (5 nod di testê de li hember 20 di prom de). Di vê rewşê de, dump nikare were bikar anîn.
Pirsgirêka nûvekirina şemaya daneya serîlêdana nivîsandina Cassandra. Vegerandin dê gelek kevirên goran çêbike, ku dikare bibe sedema windabûna hilberînê bi awayên nediyar.. Cassandra ji bo tomarkirinê xweşbîn e, û berî nivîsandinê zêde nafikire.Her karek ku daneyên heyî tê de hebe jî tomarek e. Ango, bi jêbirina tiştên nepêwîst, em ê bi hêsanî hêj bêtir tomar çêkin, û tenê hin ji wan dê bi kevirên goran werin nîşankirin.
Demjimêr dema têxistinê. Cassandra di tomarkirinê de xweş e, lê carinan herikîna hatinê dikare wê bi girîngî şaş bike. Ev diqewime dema ku serîlêdan dest pê dike ku li dora çend tomarên ku ji ber hin sedeman nekarin têxin nav hev. Û em ê hewceyê DBA-ya rastîn a ku dê gc.log, pergalê û têketinên debugkirinê ji bo pirsên hêdî, metrîkên li ser berhevkirina li bendê bişopîne.
Gelek navendên danûstendinê di komekê de. Ji ku bixwînin û li ku binivîsin?
Dibe ku di xwendin û nivîsandinê de parçe bibe? Û heke wusa be, gelo divê DC-yek ji bo nivîsandinê an xwendinê nêzîkê serîlêdanê be? Û eger em asta hevgirtinê ya çewt hilbijêrin em ê bi mejîyek perçebûyî ya rastîn nekevin? Gelek pirs hene, gelek mîhengên nenas, îmkanên ku hûn bi rastî dixwazin bi wan re tine bikin hene.
Çawa me biryar da
Ji bo ku girêk nemîne, SWAP hate asteng kirin. Û naha, heke kêmbûna bîranînê hebe, divê girêk dakeve xwarê û rawestgehên gc yên mezin çênebe.
Ji ber vê yekê, em êdî di databasê de xwe dispêrin mantiqê. Pêşdebirên serîlêdanê xwe ji nû ve perwerde dikin û di koda xwe de bi awayekî çalak dest bi tedbîran dikin. Veqetandina zelal a îdeal a hilanîn û hilanîna daneyê.
Me piştgirî ji DataStax kirî. Pêşveçûna Cassandra ya qutkirî jixwe rawestiyaye (kombûna paşîn di Sibata 2018 de bû). Di heman demê de, Datastax ji bo çareseriyên IP-ya heyî karûbarek hêja û hejmareke mezin çareseriyên guheztin û adapteyî pêşkêşî dike.
Di heman demê de ez dixwazim bibînim ku Cassandra ji bo pirsên hilbijartinê ne pir hêsan e. Bê guman, CQL ji bo bikarhêneran gavek mezin e (li gorî Trift). Lê heke we tevahî beşên ku bi tevlêbûnên weha rehet, fîlterkirina belaş ji hêla her qadê ve û kapasîteyên xweşbîniya pirsê ve fêr bûne, û ev beşan ji bo çareserkirina gilî û qezayan dixebitin, wê hingê çareseriya li ser Cassandra ji wan re dijminahî û bêaqil xuya dike. Û me dest pê kir ku biryar da ku hevkarên me çawa nimûneyan çêbikin.
Me du vebijark li ber çavan girt.Di vebijarka yekem de, em bangan ne tenê bi C*, lê di databasa Oracle ya arşîvkirî de jî dinivîsin. Tenê, berevajî C *, ev databas tenê ji bo meha heyî bangan diparêze (kûrahiya hilanîna banga têr ji bo dozên ji nû ve barkirinê). Li vir me tavilê pirsgirêka jêrîn dît: heke em bi hevdemî binivîsin, wê hingê em hemî avantajên C * yên ku bi têketina bilez re têkildar in winda dikin; heke em asynkron binivîsin, garantiyek tune ku hemî bangên pêwîst bi tevahî ketine Oracle. Yek plusek, lê ya mezin hebû: ji bo xebitandinê heman Pêşvebirê PL/SQL naskirî dimîne, ango em bi pratîkî şêwaza "Facade" bicîh dikin. Vebijarkek alternatîf. Em mekanîzmayek bicîh dikin ku bangên ji C * vedike, hin daneyan ji bo dewlemendkirinê ji tabloyên têkildar ên Oracle dikişîne, tev li nimûneyên encam dibe û encamê dide me, ku em paşê bi rengekî bikar tînin (paş vegerînin, dubare bikin, analîz bikin, heyran bikin). Kêmasî: pêvajo pir pir-gav e, û ji bilî vê, navbeynkarek ji bo karmendên operasyonê tune.
Di dawiyê de, em li ser vebijarka duyemîn rûniştin. Apache Spark ji bo nimûneyên ji firaxên cûda hate bikar anîn. Esasê mekanîzmayê ji koda Java-yê hatî kêm kirin, ku, bi karanîna bişkojkên diyarkirî (abonet, dema bangê - bişkojkên beşê), daneyan ji C* derdixe, û hem jî daneyên pêwîst ji bo dewlemendkirinê ji databasek din derdixe. Piştî vê yekê ew di bîra xwe de bi wan re dike û encamê di tabloya encam de nîşan dide. Me rûyekî tevnekê li ser çirûskê xêz kir û ew pir bikêr derket.
Dema ku pirsgirêka nûvekirina daneyên ceribandina pîşesaziyê çareser kir, me dîsa gelek çareserî fikirîn. Hem bi rêya Sstloader veguheztin û hem jî vebijarka dabeşkirina komê li qada ceribandinê li du beşan, ku her yek ji wan bi ya danasînê ve girêdayî heman komê ye, bi vî rengî ji hêla wê ve tê hêz kirin. Dema ku ceribandinê nûve kirin, hate plan kirin ku wan biguhezînin: beşa ku di ceribandinê de xebitî tê paqij kirin û têkeve hilberînê, û ya din dest pê dike ku bi daneyan veqetandî bixebite. Lêbelê, piştî ku careke din fikirîn, me daneyên ku hêjayî veguheztinê bûn bi mentiqîtir nirxand, û me fêm kir ku bang bi xwe ji bo ceribandinan saziyek nakok e, heke hewce be zû çêdibe, û ew berhevoka daneya danasînê ye ku ji bo veguheztina ji bo îmtîhan. Gelek tiştên hilanînê hene ku hêjayî barkirinê ne, lê ev bi rastî çend tablo ne, û ne pir giran in. Ji ber vê yekê em wekî çareseriyek, Spark dîsa hat rizgariyê, bi arîkariya ku me nivîsand û dest bi karanîna çalak a skrîptek ji bo veguheztina daneyan di navbera tabloyan, prom-test kir.
Siyaseta meya bicîhkirina heyî rê dide me ku em bêyî paşvekêşanê bixebitin. Berî promoyê, ceribandinek ceribandinek mecbûrî heye, li wir xeletiyek ne ew qas biha ye. Di rewşek têkçûyî de, hûn dikarin her gav cîhê dozê bavêjin û ji destpêkê ve tevahiyek nexşeyê bişoxilînin.
Ji bo misogerkirina hebûna domdar a Cassandra, hûn ne tenê wî û ne tenê dba hewce ne. Her kesê ku bi serîlêdanê re dixebite divê fêm bike ku li ku û çawa li rewşa heyî binêre û meriv çawa pirsgirêkan di wextê xwe de teşhîs bike. Ji bo kirina vê yekê, em bi aktîvî DataStax OpsCenter (Rêveberî û şopandina barkêşan), metrîkên pergala Cassandra Driver (hejmara demjimêrên ji bo nivîsandina C*, hejmara demên ji bo xwendina ji C *, derengiya herî zêde, hwd.), operasyonê bişopînin. ya serîlêdanê bixwe, bi Cassandra re dixebite.
Dema ku em li ser pirsa berê fikirîn, me fêm kir ku xetera meya sereke li ku derê dibe. Ev formên pêşandana daneyê ne ku daneyan ji çend pirsên serbixwe heya hilanînê nîşan didin. Bi vî awayî em dikarin agahdariya pir nehevgirtî bistînin. Lê heke em bi tenê navendek daneyê bixebitin dê ev pirsgirêk bi heman rengî têkildar be. Ji ber vê yekê tiştê herî maqûl li vir ev e, bê guman, afirandina fonksiyonek berhevokê ji bo xwendina daneyan li ser serîlêdanek sêyemîn, ku dê piştrast bike ku dane di yek heyamê de têne wergirtin. Di derbarê dabeşkirina xwendin û nivîsandinê de di warê performansê de, li vir em ji ber xetera ku bi hin windabûna pêwendiya di navbera DC-yan de, em dikarin du komikên ku bi tevahî bi hevûdu re naguncînin bi dawî bibin.
Di encamê de, ji bo niha ji bo nivîsandina EACH_QUORUM, ji bo xwendinê - LOCAL_QUORUM li asta hevgirtî rawestiya
Encam û encamên kurt
Ji bo ku em çareseriya encam ji hêla piştgirîya operasyonê û perspektîfên pêşkeftina pêşdetir ve binirxînin, me biryar da ku em bifikirin ka li ku derê pêşkeftinek weha dikare were sepandin.
Rasterast, dûv re ji bo bernameyên wekî "Dema ku xweş be bidin" (em agahdarî li C* bar dikin, bi karanîna tîpên Spark re hesab dikin), hesabkirina îdîayên bi berhevkirina li gorî deverê, hilanîna rolan û hesabkirina mafên gihîştina bikarhêner li gorî rola matrix.
Wekî ku hûn dibînin, repertuwara pirfireh û cihêreng e. Û heke em kampa alîgir/dijberên NoSQL hilbijêrin, wê hingê em ê beşdarî piştgiran bibin, ji ber ku me avantajên xwe wergirtin, û tam cihê ku me hêvî dikir.
Tewra vebijarka Cassandra ji qutiyê rê dide pîvandina horizontî di wextê rast de, bi tevahî bê êş pirsgirêka zêdekirina daneyan di pergalê de çareser dike. Me karî mekanîzmayek pir zêde ya ji bo hesabkirina berhevokên bangê biguhezînin nav çemberek cihê, û di heman demê de şema serîlêdanê û mantiqê jî ji hev veqetînin, ji pratîka xirab a nivîsandina kar û tiştên xwerû di databasê bixwe de xilas bibin. Me fersenda hilbijartinê û mîhengan, bilezkirina, em ê li ser kîjan DC-yan hesaban bikin û li ser kîjanan em ê daneyan tomar bikin, bi dest xist, me xwe li hember têkçûna her du girêkên takekesî û bi tevahî DC-yê sîgorte kir.
Bi sepandina mîmariya xwe li ser projeyên nû, û jixwe xwedan hin ezmûnek e, ez dixwazim tavilê hûrguliyên ku li jor hatine destnîşan kirin bihesibînim, û pêşî li hin xeletiyan bigirim, hin quncikên tûj ên ku di destpêkê de nedihatin dûrxistin xweş bikin.
Ji bo nimûne, nûvekirinên Cassandra di wextê xwe de bişopîninji ber ku gelek ji pirsgirêkên ku me bi dest xistibûn jixwe dihatin zanîn û çareser kirin.
Hem databasa xwe û hem jî Spark li ser heman girêkan nexin (an jî bi hişkî li gorî mêjera karanîna çavkaniya destûr dabeş bikin), ji ber ku Spark dikare ji ya hêvîkirî bêtir OP-ê bixwe, û em ê zû pirsgirêka hejmara 1 ji navnîşa xwe bistînin.
Di qonaxa ceribandina projeyê de çavdêrî û jêhatiya xebitandinê baştir bikin. Di destpêkê de, bi qasî ku gengaz e hemî xerîdarên potansiyel ên çareseriya me li ber çavan bigirin, ji ber ku ev e ya ku avahiya databasê dê di dawiyê de pê ve girêdayî be.
Ji bo optîmîzekirina mimkun çerxa encam çend caran bizivirînin. Hilbijêre ka kîjan zevî dikarin bêne rêz kirin. Fêm bikin ka divê em çi tabloyên zêde çêkin da ku em herî rast û çêtirîn li ber çavan bigirin, û dûv re li gorî daxwazê agahdariya hewce peyda bikin (mînak, bi texmîna ku em dikarin heman daneyan di tabloyên cihêreng de hilînin, li gorî veqetandinên cûda li ber çavan bigirin. pîvanên cihêreng, em dikarin bi girîngî dema CPU-yê ji bo daxwazên xwendinê xilas bikin).
Ne xirab Tavilê ji bo girêdana TTL û paqijkirina daneyên kevnar peyda bikin.
Dema ku daneyên ji Cassandra dakêşin Mantiqa serîlêdanê divê li ser prensîba FETCH-ê bixebite, da ku ne hemî rêz bi yekcarê di bîranînê de werin barkirin, lê di koman de têne hilbijartin.
Berî ku projeyê veguhezînin çareseriya diyarkirî, tê pêşniyar kirin bi pêkanîna rêzek ceribandinên têkçûnê, tolerasyona xeletiya pergalê kontrol bikin, wek windabûna daneyê di navendek daneyê de, sererastkirina daneyên zirardar di heyamek diyar de, avêtina torê di navbera navendên daneyê de. Testên weha dê ne tenê bihêle ku meriv erênî û neyînîyên mîmariya pêşniyarkirî binirxîne, lê di heman demê de dê pratîka germbûna baş jî ji endezyarên ku wan dimeşîne peyda bike, û jêhatîbûna bidestxistî dê ji zêdebûnê dûr be heke têkçûnên pergalê di hilberînê de werin dubare kirin.
Ger em bi agahdariya krîtîk re bixebitin (mînakî daneyên ji bo fatûreyê, hesabkirina deynê abonetiyê), wê hingê hêja ye ku bala xwe bidin amûrên ku dê xetereyên ku ji ber taybetmendiyên DBMS derdikevin kêm bikin. Mînakî, kargêriya nodesync (Datastax) bikar bînin, ku ji bo karanîna wê stratejiyek çêtirîn çêkiriye. ji bo hevgirtinê, barek zêde li ser Cassandra neafirînin û wê di heyamek diyar de tenê ji bo hin tabloyan bikar bînin.
Piştî şeş mehên jiyana Cassandra çi dibe? Bi gelemperî, pirsgirêkên ku ne çareserkirî ne. Me jî rê neda qezayên giran û windakirina daneyan. Erê, diviyabû em li ser telafîkirina hin pirsgirêkên ku berê derneketibûn bifikirin, lê di dawiyê de vê yekê çareseriya meya mîmarî pir nepenî kir. Heke hûn dixwazin û natirsin ku hûn tiştek nû biceribînin, û di heman demê de naxwazin ku pir bêhêvî bin, wê hingê ji vê rastiyê re amade bibin ku tiştek belaş nîne. Hûn ê neçar bin ku têbigihîjin, di nav belgeyan de bigerin û ji çareseriya mîrateya kevn bêtir rahêja xweya kesane bicivînin, û tu teoriyek ji we re pêşwext nabêje ka kîjan rake li benda we ye.
Source: www.habr.com