🥇NewSQL = NeiSQL+SÍR

Þar til nýlega geymdi Odnoklassniki um 50 TB af gögnum sem voru unnin í rauntíma í SQL Server. Fyrir slíkt magn er nánast ómögulegt að veita skjótan og áreiðanlegan og jafnvel bilunarþolinn aðgang með því að nota SQL DBMS. Venjulega, í slíkum tilfellum, er ein af NoSQL geymslunum notuð, en ekki er hægt að flytja allt yfir í NoSQL: Sumir aðilar krefjast ACID viðskiptaábyrgðar.

Þetta leiddi til þess að við notuðum NewSQL geymslu, það er DBMS sem veitir bilanaþol, sveigjanleika og afköst NoSQL kerfa, en á sama tíma viðhalda ACID ábyrgðum sem klassísk kerfi þekkja. Það eru fá starfandi iðnaðarkerfi af þessum nýja flokki, þannig að við innleiddum slíkt kerfi sjálf og settum það í atvinnurekstur.

Hvernig það virkar og hvað gerðist - lestu undir klippunni.

Í dag eru mánaðarlegir áhorfendur Odnoklassniki meira en 70 milljónir einstakra gesta. Við Við erum í topp fimm stærstu samfélagsnet í heimi og meðal þeirra tuttugu vefsvæða sem notendur eyða mestum tíma á. OK innviðir höndla mjög mikið álag: meira en milljón HTTP beiðnir/sek á framhlið. Hlutar netþjónaflota sem eru meira en 8000 stykki eru staðsettir nálægt hver öðrum - í fjórum gagnaverum í Moskvu, sem gerir það mögulegt að tryggja netleynd sem er minna en 1 ms á milli þeirra.

Við höfum notað Cassandra síðan 2010, frá og með útgáfu 0.6. Í dag eru nokkrir tugir klasa í rekstri. Hraðasta þyrpingin vinnur meira en 4 milljónir aðgerða á sekúndu og sá stærsti geymir 260 TB.

Hins vegar eru þetta allt venjulegir NoSQL klasar sem notaðir eru til geymslu veikt samræmt gögn. Okkur langaði að skipta út helstu samræmdu geymslunni, Microsoft SQL Server, sem hefur verið notuð frá stofnun Odnoklassniki. Geymslan samanstóð af meira en 300 SQL Server Standard Edition vélum, sem innihéldu 50 TB af gögnum - viðskiptaeiningum. Þessum gögnum er breytt sem hluti af ACID viðskiptum og krefjast þess mikil samkvæmni.

Til að dreifa gögnum yfir SQL Server hnúta notuðum við bæði lóðrétt og lárétt skipting (klippa). Sögulega notuðum við einfalt gagnaskiptingarkerfi: hver eining var tengd tákni - fall af auðkenni einingarinnar. Aðilar með sama auðkenni voru settir á sama SQL netþjón. Samband aðal- og smáatriða var útfært þannig að auðkenni aðal- og barnaskrár passuðu alltaf saman og voru staðsett á sama netþjóni. Í félagslegu neti eru næstum allar færslur búnar til fyrir hönd notandans - sem þýðir að öll notendagögn innan eins starfhæfs undirkerfis eru geymd á einum netþjóni. Það er að segja, viðskiptafærsla snerti nánast alltaf töflur frá einum SQL netþjóni, sem gerði það mögulegt að tryggja gagnasamkvæmni með því að nota staðbundin ACID viðskipti, án þess að þurfa að nota hægt og óáreiðanlegt dreifð ACID viðskipti.

Þökk sé klippingu og til að flýta fyrir SQL:

Við notum ekki takmarkanir á erlendum lyklum, þar sem við sundrun getur auðkenni einingarinnar verið staðsett á öðrum netþjóni.
Við notum ekki geymdar aðferðir og kveikjur vegna viðbótarálags á DBMS CPU.
Við notum ekki JOINs vegna alls ofangreinds og mikið af handahófi lesið af diski.
Utan viðskipta notum við einangrunarstigið Read Uncommitted til að draga úr deadlocks.
Við gerum aðeins stutt viðskipti (að meðaltali styttri en 100 ms).
Við notum ekki multi-row UPDATE og DELETE vegna mikils fjölda deadlocks - við uppfærum aðeins eina skrá í einu.
Við framkvæmum alltaf fyrirspurnir eingöngu á vísitölum - fyrirspurn með fullri töfluskannaáætlun fyrir okkur þýðir að ofhlaða gagnagrunninn og valda því að hann mistekst.

Þessi skref gerðu okkur kleift að kreista næstum hámarksafköst út úr SQL netþjónum. Vandamálin urðu hins vegar æ fleiri. Við skulum skoða þær.

Vandamál með SQL

Þar sem við notuðum sjálfskrifaða klippingu var það að bæta við nýjum klippum handvirkt af stjórnendum. Allan þennan tíma voru stigstærðar eftirlíkingar af gögnum ekki að þjónusta beiðnir.
Eftir því sem fjöldi skráa í töflunni eykst minnkar hraði innsetningar og breytinga; þegar vísitölum er bætt við núverandi töflu lækkar hraðinn um einn þátt; stofnun og endurgerð vísitölu á sér stað með niður í tíma.
Að hafa lítið magn af Windows fyrir SQL Server í framleiðslu gerir innviðastjórnun erfitt

En aðalvandamálið er

bilanaþol

Klassíski SQL netþjónninn hefur lélegt bilanaþol. Segjum að þú hafir aðeins einn gagnagrunnsþjón og hann bilar einu sinni á þriggja ára fresti. Á þessum tíma er síðan niðri í 20 mínútur, sem er ásættanlegt. Ef þú ert með 64 netþjóna, þá er síðan niðri einu sinni á þriggja vikna fresti. Og ef þú ert með 200 netþjóna, þá virkar síðan ekki í hverri viku. Þetta er vandamál.

Hvað er hægt að gera til að bæta bilanaþol SQL netþjóns? Wikipedia býður okkur að byggja mjög fáanlegur klasi: þar sem ef einhver íhlutanna bilar er varabúnaður.

Þetta krefst flota af dýrum búnaði: fjölmargar afritanir, ljósleiðara, sameiginleg geymsla og innsetning varaforða virkar ekki á áreiðanlegan hátt: um 10% skipta enda með bilun í varahnútnum eins og lest á bak við aðalhnútinn.

En helsti ókosturinn við svona mjög tiltækan klasa er núll aðgengi ef gagnaverið sem hann er staðsett í bilar. Odnoklassniki hefur fjögur gagnaver og við þurfum að tryggja rekstur ef algjör bilun verður í einu þeirra.

Fyrir þetta gætum við notað Fjölmeistari afritun innbyggð í SQL Server. Þessi lausn er mun dýrari vegna kostnaðar við hugbúnað og glímir við vel þekkt vandamál með afritun - ófyrirsjáanlegar viðskiptatafir með samstilltri afritun og tafir á að beita afritunum (og þar af leiðandi tapaðar breytingar) með ósamstilltri afritun. Hið gefið í skyn handvirk lausn ágreinings gerir þennan möguleika algjörlega óviðeigandi fyrir okkur.

Öll þessi vandamál kröfðust róttækrar lausnar og við byrjuðum að greina þau í smáatriðum. Hér þurfum við að kynna okkur hvað SQL Server gerir aðallega - viðskipti.

Einföld viðskipti

Við skulum íhuga einföldustu viðskiptin, frá sjónarhóli beitts SQL forritara: að bæta mynd við albúm. Albúm og ljósmyndir eru geymdar á mismunandi plötum. Albúmið er með opinberum myndateljara. Þá er slíkum viðskiptum skipt í eftirfarandi skref:

Við læsum albúminu með lykli.
Búðu til færslu í myndatöflunni.
Ef myndin hefur opinbera stöðu, bættu þá opinberum myndateljara við albúmið, uppfærðu skrána og framkvæmdu viðskiptin.

Eða í gervikóða:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

Við sjáum að algengasta atburðarásin fyrir viðskipti er að lesa gögn úr gagnagrunninum inn í minni forritaþjónsins, breyta einhverju og vista nýju gildin aftur í gagnagrunninn. Venjulega í slíkum viðskiptum uppfærum við nokkrar einingar, nokkrar töflur.

Þegar viðskipti eru framkvæmd geta samhliða breytingar á sömu gögnum úr öðru kerfi átt sér stað. Til dæmis getur Antispam ákveðið að notandinn sé einhvern veginn grunsamlegur og því ættu allar myndir notandans ekki lengur að vera opinberar, þær þurfa að vera sendar til stjórnunar, sem þýðir að breyta photo.status í eitthvað annað gildi og slökkva á samsvarandi teljara. Augljóslega, ef þessi aðgerð á sér stað án trygginga fyrir atómvirkni notkunar og einangrun samkeppnisbreytinga, eins og í ACID, þá verður útkoman ekki sú sem þarf - annað hvort mun myndateljarinn sýna rangt gildi eða ekki verða allar myndir sendar til stjórnunar.

Mikið af svipuðum kóða, sem vinnur með ýmsum viðskiptaeiningum innan einnar færslu, hefur verið skrifaður í gegnum alla tilveru Odnoklassniki. Byggt á reynslu af flutningum til NoSQL frá Endanlegt samræmi Við vitum að stærsta áskorunin (og tímafjárfesting) kemur frá því að þróa kóða til að viðhalda samræmi í gögnum. Þess vegna töldum við aðalkröfuna fyrir nýju geymsluna vera að gera ráð fyrir raunverulegum ACID-viðskiptum fyrir umsóknarrökfræði.

Aðrar, ekki síður mikilvægar, kröfur voru:

Ef gagnaverið bilar þarf bæði að lesa og skrifa í nýju geymsluna að vera til staðar.
Viðhalda núverandi þróunarhraða. Það er, þegar unnið er með nýja geymslu ætti magn kóða að vera um það bil það sama; það ætti ekki að þurfa að bæta neinu við geymsluna, þróa reiknirit til að leysa árekstra, viðhalda aukavísitölum o.s.frv.
Hraði nýju geymslunnar þurfti að vera nokkuð mikill, bæði við lestur gagna og við vinnslu viðskipta, sem þýddi í raun að fræðilega strangar, alhliða en hægar lausnir, eins og td, áttu ekki við. tveggja fasa skuldbindingar.
Sjálfvirk stigstærð á flugi.
Notaðu venjulega ódýra netþjóna, án þess að þurfa að kaupa framandi vélbúnað.
Möguleiki á þróun geymslu hjá hönnuðum fyrirtækisins. Með öðrum orðum var forgangur settur á sér- eða opinn hugbúnað, helst í Java.

Ákvarðanir, ákvarðanir

Með því að greina mögulegar lausnir komumst við að tveimur mögulegum valkostum í arkitektúr:

Hið fyrsta er að taka hvaða SQL netþjón sem er og innleiða nauðsynlega bilanaþol, mælikvarða, bilunarklasa, úrlausn átaka og dreifð, áreiðanleg og hröð ACID viðskipti. Við metum þennan valkost sem mjög óléttan og vinnufrekan.

Annar valmöguleikinn er að taka tilbúna NoSQL geymslu með útfærðri stærðarstærð, bilunarklasa, úrlausn átaka og innleiða færslur og SQL sjálfur. Við fyrstu sýn lítur jafnvel verkefnið að innleiða SQL, svo ekki sé minnst á ACID viðskipti, út eins og verkefni sem mun taka mörg ár. En svo komumst við að því að SQL eiginleikasettið sem við notum í reynd er eins langt frá ANSI SQL og Cassandra CQL langt frá ANSI SQL. Þegar við skoðuðum CQL enn betur komumst við að því að það var nokkuð nálægt því sem við þurftum.

Cassandra og CQL

Svo, hvað er áhugavert við Cassöndru, hvaða getu hefur hún?

Í fyrsta lagi, hér geturðu búið til töflur sem styðja ýmsar gagnagerðir; þú getur valið eða UPDATE á aðallyklinum.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

Til að tryggja samkvæmni eftirlíkingagagna notar Cassandra quorum nálgun. Í einfaldasta tilvikinu þýðir þetta að þegar þrjár eftirmyndir af sömu röð eru settar á mismunandi hnúta klasans telst ritunin heppnuð ef meirihluti hnúta (þ.e. tveir af hverjum þremur) staðfesti árangur þessarar skrifaðgerðar . Röð gögnin eru talin samræmd ef við lestur var meirihluti hnúta kannaður og staðfestur. Þannig, með þremur eftirlíkingum, er fullkomið og tafarlaust gagnasamkvæmni tryggt ef einn hnút mistekst. Þessi nálgun gerði okkur kleift að innleiða enn áreiðanlegra kerfi: sendu alltaf beiðnir á allar þrjár eftirmyndirnar og bíðum eftir svari frá þeim tveimur sem hraðast hafa. Seint svar þriðju eftirmyndarinnar er hent í þessu tilviki. Hnútur sem er seint að svara getur átt í alvarlegum vandamálum - bremsur, sorpsöfnun í JVM, bein endurheimt minni í Linux kjarnanum, vélbúnaðarbilun, sambandsleysi frá netinu. Hins vegar hefur þetta ekki áhrif á starfsemi eða gögn viðskiptavinarins á nokkurn hátt.

Aðferðin þegar við höfum samband við þrjá hnúta og fáum svar frá tveimur er kölluð vangaveltur: Beiðni um auka eftirlíkingar er send jafnvel áður en hún „fellur“.

Annar ávinningur Cassandra er Batchlog, vélbúnaður sem tryggir að hópur breytinga sem þú gerir er annað hvort beitt að fullu eða alls ekki beitt. Þetta gerir okkur kleift að leysa A í SÚR - atómvirkni út úr kassanum.

Það sem næst viðskiptum í Cassöndru eru svokölluð „létt viðskipti". En þau eru langt frá því að vera „raunveruleg“ SÚRU viðskipti: í raun er þetta tækifæri til að gera CAS á gögnum frá aðeins einni skrá, með því að nota samstöðu með því að nota þungavigtar Paxos siðareglur. Þess vegna er hraði slíkra viðskipta lítill.

Það sem okkur vantaði í Cassöndru

Þannig að við þurftum að innleiða alvöru ACID viðskipti í Cassöndru. Með því gætum við auðveldlega innleitt tvo aðra þægilega eiginleika klassísks DBMS: stöðugar hraðvirkar vísitölur, sem myndu gera okkur kleift að framkvæma gagnaval ekki aðeins með aðallyklinum, og venjulegur rafall eintóna sjálfkrafa auðkenni.

C*Einn

Þannig fæddist nýtt DBMS C*Einn, sem samanstendur af þremur gerðum af miðlarahnútum:

Geymsla – (næstum því) venjulegir Cassandra netþjónar sem bera ábyrgð á að geyma gögn á staðbundnum diskum. Eftir því sem álag og magn gagna eykst er auðvelt að stækka magn þeirra í tugi og hundruð.
Viðskiptastjórar - tryggja framkvæmd viðskipta.
Viðskiptavinir eru forritaþjónar sem innleiða viðskiptarekstur og hefja viðskipti. Það geta verið þúsundir slíkra viðskiptavina.

Netþjónar af öllum gerðum eru hluti af sameiginlegum klasa, nota innri Cassandra skilaboðasamskiptareglur til að hafa samskipti sín á milli og slúður til að skiptast á klasaupplýsingum. Með Heartbeat læra netþjónar um gagnkvæmar bilanir, viðhalda einu gagnaskema - töflum, uppbyggingu þeirra og afritun; skiptingarkerfi, svæðisfræði klasa o.s.frv.

Viðskiptavinir

Í stað hefðbundinna rekla er Fat Client háttur notaður. Slíkur hnútur geymir ekki gögn, en getur virkað sem samræmingaraðili fyrir framkvæmd beiðna, það er að viðskiptavinurinn sjálfur starfar sem samræmingaraðili beiðna sinna: hann leitar eftir geymsluafritum og leysir árekstra. Þetta er ekki aðeins áreiðanlegra og hraðvirkara en venjulegur bílstjóri, sem krefst samskipta við fjarstýrðan samræmingaraðila, heldur gerir þér einnig kleift að stjórna sendingu beiðna. Fyrir utan viðskipti sem eru opin á viðskiptavininum eru beiðnir sendar til geymslum. Ef viðskiptavinurinn hefur opnað færslu eru allar beiðnir innan færslunnar sendar til umsjónarmanns færslunnar.

C*One Transaction Coordinator

Umsjónarmaðurinn er eitthvað sem við innleiddum fyrir C*One frá grunni. Það er ábyrgt fyrir að stjórna færslum, læsingum og röðinni sem færslum er beitt í.

Fyrir hverja þjónustufærslu býr umsjónarmaðurinn til tímastimpil: hver síðari færslu er stærri en fyrri færslu. Þar sem ágreiningskerfi Cassöndru er byggt á tímastimplum (af tveimur færslum sem stangast á, sú sem er með nýjasta tímastimpilinn er talin vera núverandi), verður ágreiningurinn alltaf leystur í þágu síðari viðskipta. Þannig framkvæmdum við Lamport úr - ódýr leið til að leysa átök í dreifðu kerfi.

Lásar

Til að tryggja einangrun ákváðum við að nota einföldustu aðferðina - svartsýna læsa byggða á aðallykli skrárinnar. Með öðrum orðum, í viðskiptum verður fyrst að læsa færslu, aðeins síðan lesa, breyta og vista. Aðeins eftir árangursríka skuldbindingu er hægt að opna skrá svo að samkeppnisfærslur geti notað hana.

Það er einfalt að útfæra slíka læsingu í ódreifðu umhverfi. Í dreifðu kerfi eru tveir aðalvalkostir: annað hvort innleiða dreifða læsingu á klasanum eða dreifa færslum þannig að færslur sem fela í sér sömu færslu eru alltaf þjónustaðar af sama samræmingaraðila.

Þar sem í okkar tilfelli er gögnunum þegar dreift á hópa staðbundinna færslu í SQL, var ákveðið að úthluta staðbundnum færsluhópum til samræmingaraðila: einn samræmingaraðili framkvæmir allar færslur með táknum frá 0 til 9, annar - með táknum frá 10 til 19, og svo framvegis. Þar af leiðandi verður hvert samræmingartilvik aðal færsluhópsins.

Þá er hægt að útfæra læsingar í formi banal HashMap í minni samræmingarstjórans.

Bilanir í samræmingarstjóra

Þar sem einn samræmingaraðili þjónar eingöngu hópi viðskipta er mjög mikilvægt að fljótt ákvarða staðreyndina um bilun hans svo að seinni tilraunin til að framkvæma viðskiptin lýkur. Til að gera þetta hraðvirkt og áreiðanlegt notuðum við fulltengda sveitarhlustunarreglu:

Hver gagnaver hýsir að minnsta kosti tvo samræmingarhnúta. Reglulega sendir hver umsjónarmaður hjartsláttarboð til hinna umsjónarmannanna og upplýsir þá um virkni þess, sem og hvaða hjartsláttarboð hann fékk frá hvaða umsjónarmönnum í klasanum síðast.

Með því að fá svipaðar upplýsingar frá öðrum sem hluta af hjartsláttarboðum sínum, ákveður hver samræmingaraðili sjálfur hvaða klasahnútar virka og hverjir ekki, með hliðsjón af sveitarreglunni: ef hnútur X hefur fengið upplýsingar frá meirihluta hnúta í klasanum um eðlilega móttaka skilaboða frá hnút Y, þá virkar Y. Og öfugt, um leið og meirihlutinn tilkynnir að skilaboð vantar frá hnút Y, þá hefur Y neitað. Það er forvitnilegt að ef sveitin tilkynnir hnút X að hún sé ekki lengur að fá skilaboð frá henni, þá mun hnútur X sjálfur telja sig hafa mistekist.

Hjartsláttarboð eru send með mikilli tíðni, um 20 sinnum á sekúndu, með 50 ms tímabili. Í Java er erfitt að tryggja svörun forrita innan 50 ms vegna sambærilegrar lengdar hlés af völdum sorphirðu. Okkur tókst að ná þessum viðbragðstíma með því að nota G1 sorphirðuna, sem gerir okkur kleift að tilgreina markmið fyrir lengd GC hlé. Hins vegar, stundum, frekar sjaldan, fara hlé á safnara yfir 50 ms, sem getur leitt til rangrar bilanagreiningar. Til að koma í veg fyrir að þetta gerist tilkynnir umsjónarmaður ekki bilun í fjarhnút þegar fyrstu hjartsláttarboðin frá honum hverfa, aðeins ef nokkrir hafa horfið í röð. Þannig tókst okkur að greina bilun í samræmingarhnút árið 200 Fröken.

En það er ekki nóg að skilja fljótt hvaða hnút hefur hætt að virka. Við þurfum að gera eitthvað í þessu.

Fyrirvari

Klassíska kerfið felur í sér, ef meistarabilun verður, að hefja nýja kosningu með því að nota einn af smart alhliða reiknirit. Hins vegar eru slík reiknirit með vel þekkt vandamál með tímasamruni og lengd kosningaferilsins sjálfs. Okkur tókst að koma í veg fyrir slíkar viðbótartafir með því að nota samhæfingarkerfi fyrir skipti á fullkomlega tengdu neti:

Segjum að við viljum framkvæma færslu í hópi 50. Við skulum ákveða fyrirfram skiptikerfi, það er hvaða hnútar munu framkvæma færslur í hópi 50 ef bilun verður í aðal samræmingarstjóra. Markmið okkar er að viðhalda virkni kerfisins ef bilun verður í gagnaveri. Við skulum ákveða að fyrsti varasjóðurinn verði hnútur frá öðru gagnaveri og seinni varasjóðurinn verði hnútur frá því þriðja. Þetta kerfi er valið einu sinni og breytist ekki fyrr en staðfræði klasans breytist, það er fyrr en nýir hnútar koma inn í hana (sem gerist mjög sjaldan). Aðferðin við að velja nýjan virkan skipstjóra ef sá gamli mistekst verður alltaf sem hér segir: fyrsti varasjóðurinn verður virkur skipstjóri og ef hann hefur hætt að virka verður seinni varasjóðurinn virkur skipstjóri.

Þetta kerfi er áreiðanlegra en alhliða reikniritið, þar sem til að virkja nýjan meistara er nóg að ákvarða bilun þess gamla.

En hvernig munu viðskiptavinir skilja hvaða meistari er að vinna núna? Það er ómögulegt að senda upplýsingar til þúsunda viðskiptavina á 50 ms. Aðstæður eru mögulegar þegar viðskiptavinur sendir beiðni um að opna viðskipti, ekki enn að vita að þessi skipstjóri virkar ekki lengur, og beiðnin mun renna út. Til að koma í veg fyrir að þetta gerist, senda viðskiptavinir í spákaupmennsku beiðni um að opna viðskipti til hópstjórans og beggja varasjóða hans í einu, en aðeins sá sem er virkur húsbóndi í augnablikinu mun svara þessari beiðni. Viðskiptavinurinn mun aðeins hafa öll síðari samskipti innan viðskiptanna við virka skipstjórann.

Afritunarstjórar setja mótteknar beiðnir um færslur sem ekki eru þeirra í biðröð ófæddra færslur, þar sem þær eru geymdar í nokkurn tíma. Ef virki meistarinn deyr, vinnur nýi meistarinn úr beiðnum um að opna færslur úr biðröð sinni og svarar viðskiptavininum. Ef viðskiptavinurinn hefur þegar opnað viðskipti við gamla skipstjórann, þá er annað svar hunsað (og augljóslega mun slík viðskipti ekki ljúka og verða endurtekin af viðskiptavininum).

Hvernig viðskiptin virka

Segjum sem svo að viðskiptavinur hafi sent beiðni til samræmingarstjórans um að opna færslu fyrir svona og svo aðila með svona og svo aðallykil. Umsjónarmaðurinn læsir þessari einingu og setur hana í lástöfluna í minni. Ef nauðsyn krefur les samræmingarstjóri þessa aðila úr geymslu og geymir gögnin sem myndast í færslustöðu í minni samræmingarstjórans.

Þegar viðskiptavinur vill breyta gögnum í færslu sendir hann beiðni til samræmingarstjórans um að breyta einingunni og umsjónarmaðurinn setur nýju gögnin í færslustöðutöfluna í minni. Þetta lýkur upptökunni - engin upptaka er gerð í geymslunni.

Þegar viðskiptavinur óskar eftir eigin breyttum gögnum sem hluta af virkum viðskiptum, starfar umsjónarmaður sem hér segir:

ef auðkennið er þegar í viðskiptunum, þá eru gögnin tekin úr minni;
ef það er ekkert auðkenni í minni, þá eru þau gögn sem vantar lesin úr geymsluhnútunum, ásamt þeim sem þegar eru í minni, og niðurstaðan er gefin til viðskiptavinarins.

Þannig getur viðskiptavinurinn lesið sínar eigin breytingar, en aðrir viðskiptavinir sjá ekki þessar breytingar, vegna þess að þær eru aðeins vistaðar í minni samræmingarstjórans; þær eru ekki enn í Cassandra hnútunum.

Þegar viðskiptavinurinn sendir commit er ástandið sem var í minni þjónustunnar vistað af umsjónarmanni í skráður lotu og er sent sem skráður lotu í Cassandra geymslu. Verslanir gera allt sem þarf til að tryggja að þessi pakki sé frumeindafræðilega (alveg) beitt og skila svari til samræmingarstjórans, sem sleppir læsingunum og staðfestir árangur viðskiptanna fyrir viðskiptavininn.

Og til að snúa aftur, þarf samræmingarstjórinn aðeins að losa minni sem er upptekið af færslustöðunni.

Sem afleiðing af ofangreindum umbótum innleiddum við ACID meginreglurnar:

Atómvirkni. Þetta er trygging fyrir því að engin viðskipti verði skráð að hluta í kerfinu; annað hvort verður öllum undiraðgerðum þess lokið eða engum verður lokið. Við fylgjum þessari meginreglu með skráðri lotu í Cassandra.
Samræmi. Hver vel heppnuð viðskipti, samkvæmt skilgreiningu, skráir aðeins gildar niðurstöður. Ef í ljós kemur að niðurstaðan er ógild eftir að færslu hefur verið opnuð og hluti aðgerðanna hefur verið framkvæmt er afturköllun framkvæmd.
Einangrun. Þegar viðskipti eru framkvæmd ættu samhliða viðskipti ekki að hafa áhrif á niðurstöðu þeirra. Samkeppnisviðskipti eru einangruð með svartsýnum læsingum á samræmingarstjóranum. Fyrir lestur utan færslu er einangrunarreglunni fylgt á stigi Read Committed.
Sjálfbærni. Burtséð frá vandamálum á lægri stigum - kerfisleysi, vélbúnaðarbilun - ættu breytingar sem gerðar eru vegna vel lokið færslu að haldast þegar starfsemi hefst aftur.

Lestur eftir vísitölum

Tökum einfalda töflu:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

Það hefur auðkenni (aðallykill), eiganda og breytingardagsetningu. Þú þarft að leggja fram mjög einfalda beiðni - veldu gögn um eigandann með breytingunni „fyrir síðasta dag“.

SELECT *
WHERE owner=?
AND modified>?

Til þess að hægt sé að vinna úr slíkri fyrirspurn hratt, í klassískum SQL DBMS þarftu að byggja upp vísitölu eftir dálkum (eigandi, breytt). Við getum gert þetta frekar auðveldlega, þar sem við erum núna með sýruábyrgð!

Vísitölur í C*One

Það er heimildatafla með ljósmyndum þar sem færsluauðkenni er aðallykill.

Fyrir vísitölu býr C*One til nýja töflu sem er afrit af frumritinu. Lykillinn er sá sami og vísitölutjáningin og hann inniheldur einnig aðallykill færslunnar úr upprunatöflunni:

Nú er hægt að endurskrifa fyrirspurnina um „eigandi síðasta daginn“ sem val úr annarri töflu:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

Samræmi gagna í myndum upprunatöflunnar og vísitölutöflu i1 er viðhaldið sjálfkrafa af samræmingarstjóra. Byggt á gagnaskemanu einu saman, þegar breyting er móttekin, býr samræmingarstjórinn til og geymir breytingu ekki aðeins í aðaltöflunni heldur einnig í afritum. Engar viðbótaraðgerðir eru gerðar á vísitölutöflunni, annálar eru ekki lesnar og engir læsingar eru notaðir. Það er, að bæta við vísitölum eyðir nánast engum auðlindum og hefur nánast engin áhrif á hraða beitingar breytinga.

Með því að nota ACID gátum við innleitt SQL-líkar vísitölur. Þau eru samkvæm, stigstærð, hröð, samsett og innbyggð í CQL fyrirspurnarmálið. Engar breytingar á forritakóða eru nauðsynlegar til að styðja við vísitölur. Allt er eins einfalt og í SQL. Og síðast en ekki síst, vísitölur hafa ekki áhrif á framkvæmdarhraða breytinga á upprunalegu viðskiptatöflunni.

Hvað gerðist

Við þróuðum C*One fyrir þremur árum og settum hann í atvinnurekstur.

Hvað fengum við á endanum? Við skulum meta þetta með því að nota dæmið um myndvinnslu og geymslu undirkerfi, eina mikilvægustu tegund gagna á samfélagsneti. Við erum ekki að tala um líkama ljósmyndanna sjálfra heldur alls kyns meta-upplýsingar. Nú hefur Odnoklassniki um 20 milljarða slíkra skráa, kerfið vinnur úr 80 þúsund lestrarbeiðnum á sekúndu, allt að 8 þúsund ACID færslur á sekúndu sem tengjast gagnabreytingum.

Þegar við notuðum SQL með afritunarstuðli = 1 (en í RAID 10), voru lýsiupplýsingar myndarinnar geymdar á mjög tiltækum klasa af 32 vélum sem keyrðu Microsoft SQL Server (auk 11 öryggisafrita). 10 netþjónum var einnig úthlutað til að geyma afrit. Alls 50 dýrir bílar. Á sama tíma virkaði kerfið á nafnálagi, án vara.

Eftir flutning yfir í nýja kerfið fengum við afritunarstuðul = 3 - afrit í hverri gagnaver. Kerfið samanstendur af 63 Cassandra geymsluhnútum og 6 samhæfingarvélum, fyrir samtals 69 netþjóna. En þessar vélar eru mun ódýrari, heildarkostnaður þeirra er um 30% af kostnaði við SQL kerfi. Á sama tíma er álagið haldið í 30%.

Með tilkomu C*One minnkaði leynd einnig: í SQL tók skrifaðgerð um 4,5 ms. Í C*One - um 1,6 ms. Lengd færslunnar er að meðaltali innan við 40 ms, skuldbindingunni er lokið á 2 ms, lengd lestrar og skrifa er að meðaltali 2 ms. 99. hundraðshluti - aðeins 3-3,1 ms, fjöldi leiktíma hefur fækkað um 100 sinnum - allt vegna útbreiddrar notkunar á vangaveltum.

Núna hafa flestir SQL Server hnúta verið teknir úr notkun; nýjar vörur eru aðeins þróaðar með C*One. Við aðlaguðum C*One til að vinna í skýinu okkar eitt ský, sem gerði það mögulegt að flýta fyrir uppsetningu nýrra klasa, einfalda uppsetningu og gera sjálfvirkan rekstur. Án frumkóðans væri mun erfiðara og erfiðara að gera þetta.

Nú erum við að vinna í því að flytja aðra geymsluaðstöðu okkar yfir í skýið - en það er allt önnur saga.

Heimild: www.habr.com

NewSQL = NoSQL+ACID