VÄl nesen Odnoklassniki uzglabÄja aptuveni 50 TB datu, kas tika apstrÄdÄti reÄllaikÄ SQL serverÄ«. Å Ädam apjomam ir gandrÄ«z neiespÄjami nodroÅ”inÄt Ätru un uzticamu un pat datu centra kļūmju tolerantu piekļuvi, izmantojot SQL DBVS. Parasti Å”Ädos gadÄ«jumos tiek izmantota viena no NoSQL krÄtuvÄm, taÄu ne visu var pÄrsÅ«tÄ«t uz NoSQL: dažÄm entÄ«tijÄm ir nepiecieÅ”amas ACID darÄ«jumu garantijas.
Tas lika mums izmantot NewSQL krÄtuvi, tas ir, DBVS, kas nodroÅ”ina NoSQL sistÄmu kļūdu toleranci, mÄrogojamÄ«bu un veiktspÄju, bet tajÄ paÅ”Ä laikÄ saglabÄ klasiskajÄm sistÄmÄm pazÄ«stamÄs ACID garantijas. Å Ä«s jaunÄs klases industriÄlo sistÄmu ir maz strÄdÄjoÅ”u, tÄpÄc paÅ”i ieviesÄm Å”Ädu sistÄmu un nodevÄm komerciÄlÄ ekspluatÄcijÄ.
KÄ tas darbojas un kas notika - lasiet zem griezuma.
Å odien Odnoklassniki ikmÄneÅ”a auditorija ir vairÄk nekÄ 70 miljoni unikÄlo apmeklÄtÄju. MÄs lielÄkajiem sociÄlajiem tÄ«kliem pasaulÄ un starp divdesmit vietnÄm, kurÄs lietotÄji pavada visvairÄk laika. OK infrastruktÅ«ra apstrÄdÄ Ä¼oti lielas slodzes: vairÄk nekÄ miljons HTTP pieprasÄ«jumu sekundÄ katrÄ priekÅ”pusÄ. VairÄk nekÄ 8000 vienÄ«bu serveru flotes daļas atrodas tuvu viena otrai - Äetros Maskavas datu centros, kas pieļauj tÄ«kla latentumu starp tiem mazÄku par 1 ms.
MÄs izmantojam Cassandra kopÅ” 2010. gada, sÄkot ar versiju 0.6. MÅ«sdienÄs darbojas vairÄki desmiti kopu. ÄtrÄkais klasteris apstrÄdÄ vairÄk nekÄ 4 miljonus operÄciju sekundÄ, bet lielÄkais glabÄ 260 TB.
TomÄr tÄs visas ir parastÄs NoSQL kopas, ko izmanto glabÄÅ”anai datus. MÄs vÄlÄjÄmies aizstÄt galveno konsekvento krÄtuvi Microsoft SQL Server, kas tika izmantota kopÅ” Odnoklassniki dibinÄÅ”anas. KrÄtuve sastÄvÄja no vairÄk nekÄ 300 SQL Server Standard Edition maŔīnÄm, kas saturÄja 50 TB datu - biznesa vienÄ«bas. Å ie dati tiek modificÄti kÄ daļa no ACID darÄ«jumiem un ir nepiecieÅ”ami .
Lai izplatÄ«tu datus pa SQL Server mezgliem, mÄs izmantojÄm gan vertikÄlo, gan horizontÄlo (skaldÄ«Å”ana). VÄsturiski mÄs izmantojÄm vienkÄrÅ”u datu sadalÄ«Å”anas shÄmu: katra entÄ«tija bija saistÄ«ta ar marÄ·ieri ā entÄ«tijas ID funkciju. EntÄ«tijas ar vienu un to paÅ”u pilnvaru tika ievietotas tajÄ paÅ”Ä SQL serverÄ«. GalvenÄs un detaļas attiecÄ«bas tika ieviestas tÄ, lai galvenÄ un pakÄrtotÄ ieraksta marÄ·ieri vienmÄr sakristu un atrastos vienÄ serverÄ«. SociÄlajÄ tÄ«klÄ gandrÄ«z visi ieraksti tiek Ä£enerÄti lietotÄja vÄrdÄ ā tas nozÄ«mÄ, ka visi lietotÄja dati vienas funkcionÄlÄs apakÅ”sistÄmas ietvaros tiek glabÄti vienÄ serverÄ«. Tas nozÄ«mÄ, ka biznesa darÄ«jums gandrÄ«z vienmÄr ietvÄra tabulas no viena SQL servera, kas ļÄva nodroÅ”inÄt datu konsekvenci, izmantojot lokÄlÄs ACID transakcijas, neizmantojot izplatÄ«ti ACID darÄ«jumi.
Pateicoties sadalÄ«Å”anai un SQL paÄtrinÄÅ”anai:
- MÄs neizmantojam sveÅ”Äs atslÄgas ierobežojumus, jo sadalot entÄ«tijas ID var atrasties citÄ serverÄ«.
- MÄs neizmantojam saglabÄtÄs procedÅ«ras un trigerus DBVS CPU papildu slodzes dÄļ.
- MÄs neizmantojam JOIN visu iepriekÅ”minÄto un daudzu nejauÅ”u nolasÄ«jumu dÄļ no diska.
- Ärpus darÄ«juma mÄs izmantojam Read Uncommitted izolÄcijas lÄ«meni, lai samazinÄtu strupceļus.
- Veicam tikai Ä«sus darÄ«jumus (vidÄji Ä«sÄkus par 100 ms).
- MÄs neizmantojam vairÄku rindu UPDATE un DELETE lielÄ strupceļu skaita dÄļ - vienlaikus atjaunojam tikai vienu ierakstu.
- MÄs vienmÄr veicam vaicÄjumus tikai indeksiem ā vaicÄjums ar pilnu tabulu skenÄÅ”anas plÄnu mums nozÄ«mÄ datu bÄzes pÄrslogoÅ”anu un tÄs neveiksmi.
Å Ä«s darbÄ«bas ļÄva mums izspiest gandrÄ«z maksimÄlu veiktspÄju no SQL serveriem. TomÄr problÄmas kļuva arvien vairÄk un vairÄk. ApskatÄ«sim tos.
ProblÄmas ar SQL
- TÄ kÄ mÄs izmantojÄm paÅ”u rakstÄ«tu sadalÄ«Å”anu, administratori manuÄli pievienoja jaunus fragmentus. Visu Å”o laiku mÄrogojamÄs datu kopijas neapkalpoja pieprasÄ«jumus.
- Pieaugot ierakstu skaitam tabulÄ, ievietoÅ”anas un modifikÄcijas Ätrums samazinÄs; pievienojot indeksus esoÅ”ai tabulai, Ätrums samazinÄs par koeficientu; indeksu izveide un atkÄrtota izveide notiek ar dÄ«kstÄvi.
- Neliels Windows for SQL Server skaits ražoÅ”anÄ apgrÅ«tina infrastruktÅ«ras pÄrvaldÄ«bu
Bet galvenÄ problÄma ir
kļūdu tolerance
Klasiskajam SQL serverim ir slikta kļūdu tolerance. PieÅemsim, ka jums ir tikai viens datu bÄzes serveris, un tas neizdodas reizi trijos gados. Å ajÄ laikÄ vietne nedarbojas uz 20 minÅ«tÄm, kas ir pieÅemami. Ja jums ir 64 serveri, vietne nedarbojas reizi trÄ«s nedÄļÄs. Un, ja jums ir 200 serveri, vietne nedarbojas katru nedÄļu. TÄ ir problÄma.
Ko var darÄ«t, lai uzlabotu SQL servera kļūdu toleranci? Wikipedia aicina mÅ«s veidot : kur jebkuras sastÄvdaļas atteices gadÄ«jumÄ ir rezerves.
Tas prasa dÄrgu iekÄrtu parku: daudzas dublÄÅ”anÄs, optiskÄ Å”Ä·iedra, kopÄ«ga krÄtuve, un rezerves iekļauÅ”ana nedarbojas droÅ”i: aptuveni 10% pÄrslÄgÅ”anu beidzas ar rezerves mezgla atteici kÄ vilcienam aiz galvenÄ mezgla.
Bet galvenais Å”Äda ļoti pieejamÄ klastera trÅ«kums ir nulles pieejamÄ«ba, ja datu centrs, kurÄ tas atrodas, nedarbojas. Odnoklassniki ir Äetri datu centri, un mums ir jÄnodroÅ”ina darbÄ«ba pilnÄ«gas kļūmes gadÄ«jumÄ vienÄ no tiem.
Å im nolÅ«kam mÄs varÄtu izmantot SQL serverÄ« iebÅ«vÄta replikÄcija. Å is risinÄjums ir daudz dÄrgÄks programmatÅ«ras izmaksu dÄļ un cieÅ” no labi zinÄmÄm problÄmÄm ar replikÄciju - neparedzamu darÄ«jumu aizkavi ar sinhrono replikÄciju un replikÄciju (un lÄ«dz ar to zaudÄto modifikÄciju) pielietoÅ”anas aizkavÄÅ”anos ar asinhrono replikÄciju. NoklusÄtais padara Å”o iespÄju mums pilnÄ«gi nepiemÄrojamu.
VisÄm Ŕīm problÄmÄm bija nepiecieÅ”ams radikÄls risinÄjums, un mÄs sÄkÄm tÄs detalizÄti analizÄt. Å eit jÄiepazÄ«stas ar to, ar ko SQL Server galvenokÄrt nodarbojas ā ar transakcijÄm.
VienkÄrÅ”s darÄ«jums
ApskatÄ«sim vienkÄrÅ”Äko darÄ«jumu no lietiÅ”Ä·Ä SQL programmÄtÄja viedokļa: fotoattÄla pievienoÅ”ana albumam. Albumi un fotogrÄfijas tiek glabÄti dažÄdÄs plÄksnÄs. Albumam ir publisks foto skaitÄ«tÄjs. Tad Å”Äds darÄ«jums tiek sadalÄ«ts Å”Ädos posmos:
- MÄs bloÄ·Äjam albumu ar atslÄgu.
- Izveidojiet ierakstu fotoattÄlu tabulÄ.
- Ja fotoattÄlam ir publisks statuss, pievienojiet albumam publisku fotoattÄlu skaitÄ«tÄju, atjauniniet ierakstu un veiciet darÄ«jumu.
Vai pseidokodÄ:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(ā¦);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();MÄs redzam, ka visizplatÄ«tÄkais biznesa darÄ«juma scenÄrijs ir datu nolasÄ«Å”ana no datu bÄzes lietojumprogrammu servera atmiÅÄ, kaut kas jÄmaina un jaunÄs vÄrtÄ«bas tiek saglabÄtas atpakaļ datu bÄzÄ. Parasti Å”ÄdÄ darÄ«jumÄ mÄs atjaunojam vairÄkas entÄ«tijas, vairÄkas tabulas.
Veicot darÄ«jumu, vienlaikus var notikt to paÅ”u datu modifikÄcijas no citas sistÄmas. PiemÄram, Antispam var nolemt, ka lietotÄjs ir kaut kÄ aizdomÄ«gs un tÄpÄc visas lietotÄja fotogrÄfijas vairs nedrÄ«kst bÅ«t publiski pieejamas, tÄs jÄnosÅ«ta moderÄÅ”anai, kas nozÄ«mÄ mainÄ«t photo.status uz kÄdu citu vÄrtÄ«bu un izslÄgt atbilstoÅ”os skaitÄ«tÄjus. AcÄ«mredzot, ja Ŕī darbÄ«ba notiek bez garantijÄm par pielietojuma atomitÄti un konkurÄjoÅ”o modifikÄciju izolÄciju, kÄ tas ir , tad rezultÄts nebÅ«s tas, kas vajadzÄ«gs - vai nu foto skaitÄ«tÄjs rÄdÄ«s nepareizu vÄrtÄ«bu, vai arÄ« visas fotogrÄfijas netiks nosÅ«tÄ«tas moderÄÅ”anai.
VisÄ Odnoklassniki pastÄvÄÅ”anas laikÄ ir rakstÄ«ts daudz lÄ«dzÄ«gu kodu, kas viena darÄ«juma ietvaros manipulÄ ar dažÄdÄm biznesa vienÄ«bÄm. Pamatojoties uz pieredzi migrÄcijÄ uz NoSQL no MÄs zinÄm, ka lielÄkais izaicinÄjums (un laika ieguldÄ«jums) ir koda izstrÄde, lai saglabÄtu datu konsekvenci. TÄpÄc mÄs uzskatÄ«jÄm, ka galvenÄ prasÄ«ba jaunajai krÄtuvei ir nodroÅ”inÄt reÄlus ACID darÄ«jumus lietojumprogrammu loÄ£ikai.
Citas, ne mazÄk svarÄ«gas prasÄ«bas bija:
- Ja datu centrs neizdodas, ir jÄbÅ«t pieejamai gan lasÄ«Å”anai, gan rakstÄ«Å”anai jaunajÄ krÄtuvÄ.
- SaglabÄjot paÅ”reizÄjo attÄ«stÄ«bas Ätrumu. Tas ir, strÄdÄjot ar jaunu repozitoriju, koda daudzumam jÄbÅ«t aptuveni vienÄdam, nevajadzÄtu neko pievienot repozitorijam, izstrÄdÄt algoritmus konfliktu risinÄÅ”anai, sekundÄro indeksu uzturÄÅ”anai utt.
- JaunÄs krÄtuves Ätrumam bija jÄbÅ«t diezgan lielam gan nolasot datus, gan apstrÄdÄjot transakcijas, kas faktiski nozÄ«mÄja, ka nebija piemÄrojami akadÄmiski stingri, universÄli, bet lÄni risinÄjumi, kÄ, piemÄram, .
- AutomÄtiska mÄrogoÅ”ana lidojuma laikÄ.
- Izmantojot parastos lÄtos serverus, bez nepiecieÅ”amÄ«bas iegÄdÄties eksotisku aparatÅ«ru.
- KrÄtuves izstrÄdes iespÄja uzÅÄmuma izstrÄdÄtÄjiem. Citiem vÄrdiem sakot, prioritÄte tika pieŔķirta patentÄtiem vai atvÄrtÄ pirmkoda risinÄjumiem, vÄlams Java.
LÄmumi, lÄmumi
AnalizÄjot iespÄjamos risinÄjumus, mÄs nonÄcÄm pie divÄm iespÄjamÄm arhitektÅ«ras izvÄlÄm:
Pirmais ir izmantot jebkuru SQL serveri un ieviest nepiecieÅ”amo kļūdu toleranci, mÄrogoÅ”anas mehÄnismu, kļūmjpÄrlÄces kopu, konfliktu risinÄÅ”anu un izplatÄ«tus, uzticamus un Ätrus ACID darÄ«jumus. MÄs novÄrtÄjÄm Å”o iespÄju kÄ Ä¼oti nenozÄ«mÄ«gu un darbietilpÄ«gu.
OtrÄ iespÄja ir paÅemt gatavu NoSQL krÄtuvi ar ieviestu mÄrogoÅ”anu, kļūmjpÄrlÄces klasteri, konfliktu risinÄÅ”anu un paÅ”am ieviest transakcijas un SQL. No pirmÄ acu uzmetiena pat SQL ievieÅ”anas uzdevums, nemaz nerunÄjot par ACID darÄ«jumiem, izskatÄs pÄc uzdevuma, kas prasÄ«s vairÄkus gadus. Bet tad mÄs sapratÄm, ka praksÄ izmantojamÄ SQL funkciju kopa ir tik tÄlu no ANSI SQL tÄlu no ANSI SQL. VÄl tuvÄk apskatot CQL, mÄs sapratÄm, ka tas ir diezgan tuvu tam, kas mums nepiecieÅ”ams.
Kasandra un CQL
TÄtad, kas ir interesants KasandrÄ, kÄdas ir tÄs iespÄjas?
PirmkÄrt, Å”eit varat izveidot tabulas, kas atbalsta dažÄdus datu tipus; primÄrajÄ atslÄgÄ varat veikt SELECT vai UPDATE.
CREATE TABLE photos (id bigint KEY, owner bigint,ā¦);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET ā¦ WHERE id=?;Lai nodroÅ”inÄtu replikas datu konsekvenci, Cassandra izmanto . VisvienkÄrÅ”ÄkajÄ gadÄ«jumÄ tas nozÄ«mÄ, ka tad, kad trÄ«s vienas rindas kopijas tiek ievietotas dažÄdos klastera mezglos, rakstÄ«Å”ana tiek uzskatÄ«ta par veiksmÄ«gu, ja lielÄkÄ daļa mezglu (tas ir, divi no trim) apstiprina Ŕīs rakstÄ«Å”anas darbÄ«bas panÄkumus. . Rindas dati tiek uzskatÄ«ti par konsekventiem, ja lasÄ«Å”anas laikÄ lielÄkÄ daļa mezglu tika aptaujÄti un apstiprinÄti. TÄdÄjÄdi ar trim replikÄm pilnÄ«ga un tÅ«lÄ«tÄja datu konsekvence tiek garantÄta, ja viens mezgls neizdodas. Å Ä« pieeja ļÄva mums ieviest vÄl uzticamÄku shÄmu: vienmÄr sÅ«tiet pieprasÄ«jumus uz visÄm trim replikÄm, gaidot atbildi no divÄm ÄtrÄkajÄm. TreÅ”Äs kopijas novÄlotÄ atbilde Å”ajÄ gadÄ«jumÄ tiek atmesta. MezglÄ, kas novÄloti reaÄ£Ä, var bÅ«t nopietnas problÄmas - bremzes, atkritumu savÄkÅ”ana JVM, tieÅ”a atmiÅas atgÅ«Å”ana Linux kodolÄ, aparatÅ«ras kļūme, atvienoÅ”ana no tÄ«kla. TaÄu tas nekÄdÄ veidÄ neietekmÄ klienta darbÄ«bas vai datus.
Tiek izsaukta pieeja, kad mÄs sazinÄmies ar trim mezgliem un saÅemam atbildi no diviem : pieprasÄ«jums pÄc papildu replikÄm tiek nosÅ«tÄ«ts pat pirms tas ānokrÄ«tā.
VÄl viens Cassandra ieguvums ir Batchlog ā mehÄnisms, kas nodroÅ”ina, ka jÅ«su veikto izmaiÅu grupa tiek pilnÄ«bÄ piemÄrota vai netiek piemÄrota vispÄr. Tas ļauj mums atrisinÄt A SKÄBÄ - atomiskums Ärpus kastes.
VistuvÄk darÄ«jumiem KasandrÄ ir tÄ sauktie ā". Bet tie ir tÄlu no āÄ«stiemā ACID darÄ«jumiem: patiesÄ«bÄ Å”Ä« ir iespÄja to izdarÄ«t uz datiem tikai no viena ieraksta, izmantojot vienprÄtÄ«bu, izmantojot smagsvara Paxos protokolu. TÄpÄc Å”Ädu darÄ«jumu Ätrums ir zems.
Kas mums pietrÅ«ka KasandrÄ
TÄtad mums bija jÄievieÅ” reÄli ACID darÄ«jumi KasandrÄ. Izmantojot to, mÄs varÄtu viegli ieviest divas citas Ärtas klasiskÄs DBVS funkcijas: konsekventus Ätrus indeksus, kas ļautu veikt datu atlasi ne tikai pÄc primÄrÄs atslÄgas, un parastu monotonu automÄtiski pieaugoÅ”u ID Ä£eneratoru.
C*Viens
TÄdÄjÄdi radÄs jauna DBVS C*Viens, kas sastÄv no trÄ«s veidu servera mezgliem:
- UzglabÄÅ”ana ā (gandrÄ«z) standarta Cassandra serveri, kas atbild par datu glabÄÅ”anu lokÄlajos diskos. Pieaugot datu slodzei un apjomam, to daudzumu var viegli mÄrogot lÄ«dz desmitiem un simtiem.
- Darījumu koordinatori - nodroŔina darījumu izpildi.
- Klienti ir lietojumprogrammu serveri, kas Ä«steno biznesa operÄcijas un iniciÄ darÄ«jumus. Å Ädu klientu var bÅ«t tÅ«kstoÅ”iem.
Visu veidu serveri ir daļa no kopÄjÄ klastera, izmanto iekÅ”Äjo Cassandra ziÅojumu protokolu, lai sazinÄtos savÄ starpÄ un klasteru informÄcijas apmaiÅai. Ar Heartbeat serveri uzzina par savstarpÄjÄm kļūmÄm, uztur vienotu datu shÄmu ā tabulas, to struktÅ«ru un replikÄciju; sadalÄ«Å”anas shÄma, klasteru topoloÄ£ija utt.
Klienti
Standarta draiveru vietÄ tiek izmantots Fat Client režīms. Å Äds mezgls neuzglabÄ datus, bet var darboties kÄ pieprasÄ«juma izpildes koordinators, tas ir, Klients pats darbojas kÄ savu pieprasÄ«jumu koordinators: tas vaicÄ krÄtuves replikas un atrisina konfliktus. Tas ir ne tikai uzticamÄks un ÄtrÄks par standarta draiveri, kas prasa saziÅu ar attÄlo koordinatoru, bet arÄ« ļauj kontrolÄt pieprasÄ«jumu pÄrsÅ«tÄ«Å”anu. Ärpus klienta atvÄrtÄ darÄ«juma pieprasÄ«jumi tiek nosÅ«tÄ«ti uz krÄtuvÄm. Ja klients ir atvÄris darÄ«jumu, tad visi pieprasÄ«jumi darÄ«juma ietvaros tiek nosÅ«tÄ«ti darÄ«juma koordinatoram.
C*One darījumu koordinators
Koordinators ir tas, ko mÄs ieviesÄm C*One no nulles. TÄ ir atbildÄ«ga par darÄ«jumu pÄrvaldÄ«bu, slÄdzenÄm un darÄ«jumu piemÄroÅ”anas secÄ«bu.
Katram apkalpotajam darÄ«jumam koordinators Ä£enerÄ laikspiedolu: katrs nÄkamais darÄ«jums ir lielÄks par iepriekÅ”Äjo darÄ«jumu. TÄ kÄ Kasandras konfliktu risinÄÅ”anas sistÄma ir balstÄ«ta uz laikspiedoliem (no diviem konfliktÄjoÅ”iem ierakstiem tiek uzskatÄ«ts tas, kuram ir jaunÄkais laikspiedols), konflikts vienmÄr tiks atrisinÄts par labu nÄkamajam darÄ«jumam. TÄ mÄs Ä«stenojÄm - lÄts veids, kÄ atrisinÄt konfliktus sadalÄ«tÄ sistÄmÄ.
SlÄdzenes
Lai nodroÅ”inÄtu izolÄciju, mÄs nolÄmÄm izmantot vienkÄrÅ”Äko metodi - pesimistiskÄs slÄdzenes, kuru pamatÄ ir ieraksta primÄrÄ atslÄga. Citiem vÄrdiem sakot, darÄ«jumÄ ieraksts vispirms ir jÄbloÄ·Ä, tikai pÄc tam jÄlasa, jÄmaina un jÄsaglabÄ. Tikai pÄc veiksmÄ«gas apÅemÅ”anÄs ierakstu var atbloÄ·Ät, lai to varÄtu izmantot konkurÄjoÅ”i darÄ«jumi.
Å Ädas bloÄ·ÄÅ”anas ievieÅ”ana neizplatÄ«tÄ vidÄ ir vienkÄrÅ”a. SadalÄ«tÄ sistÄmÄ ir divas galvenÄs iespÄjas: vai nu ieviest klasterÄ« izplatÄ«to bloÄ·ÄÅ”anu, vai izplatÄ«t transakcijas, lai transakcijas, kas ietver vienu un to paÅ”u ierakstu, vienmÄr apkalpotu viens un tas pats koordinators.
TÄ kÄ mÅ«su gadÄ«jumÄ dati jau ir sadalÄ«ti starp lokÄlo transakciju grupÄm SQL, tika nolemts koordinatoriem pieŔķirt lokÄlÄs transakciju grupas: viens koordinators veic visus darÄ«jumus ar marÄ·ieriem no 0 lÄ«dz 9, otrs - ar marÄ·ieriem no 10 lÄ«dz 19, un tÄ tÄlÄk. RezultÄtÄ katra koordinatora instance kļūst par darÄ«jumu grupas galveno.
PÄc tam slÄdzenes koordinatora atmiÅÄ var ieviest banÄlas HashMap veidÄ.
Koordinatora kļūmes
TÄ kÄ viens koordinators apkalpo tikai darÄ«jumu grupu, ir ļoti svarÄ«gi Ätri noteikt tÄ neveiksmes faktu, lai otrais darÄ«juma izpildes mÄÄ£inÄjums beigtos. Lai to padarÄ«tu Ätru un uzticamu, mÄs izmantojÄm pilnÄ«bÄ savienotu kvoruma dzirdes protokolu:
KatrÄ datu centrÄ ir vismaz divi koordinatora mezgli. Periodiski katrs koordinators nosÅ«ta sirdsdarbÄ«bas ziÅojumu citiem koordinatoriem un informÄ viÅus par tÄ darbÄ«bu, kÄ arÄ« par to, kÄdus sirdsdarbÄ«bas ziÅojumus tas pÄdÄjo reizi saÅÄmis no kuriem koordinatoriem klasterÄ«.
SaÅemot lÄ«dzÄ«gu informÄciju no citiem kÄ daļu no saviem sirdsdarbÄ«bas ziÅojumiem, katrs koordinators pats izlemj, kuri klastera mezgli darbojas un kuri ne, vadoties pÄc kvoruma principa: ja mezgls X ir saÅÄmis informÄciju no lielÄkÄs daļas klastera mezglu par normÄlu darbÄ«bu. ziÅojumu saÅemÅ”ana no mezgla Y, tad darbojas , Y. Un otrÄdi, tiklÄ«dz lielÄkÄ daļa ziÅo par trÅ«kstoÅ”iem ziÅojumiem no mezgla Y, tad Y ir atteicies. Interesanti, ka, ja kvorums informÄ mezglu X, ka tas vairs nesaÅem ziÅojumus no tÄ, tad pats mezgls X uzskatÄ«s sevi par neveiksmÄ«gu.
SirdsdarbÄ«bas ziÅojumi tiek sÅ«tÄ«ti ar augstu frekvenci, apmÄram 20 reizes sekundÄ, ar 50 ms periodu. Java ir grÅ«ti garantÄt lietojumprogrammas atbildi 50 ms laikÄ, jo atkritumu savÄcÄja radÄ«tÄs pauzes ir lÄ«dzÄ«gas. MÄs varÄjÄm sasniegt Å”o reakcijas laiku, izmantojot G1 atkritumu savÄcÄju, kas ļauj mums norÄdÄ«t mÄrÄ·i GC paužu ilgumam. TomÄr dažreiz, diezgan reti, kolektora pauzes pÄrsniedz 50 ms, kas var novest pie kļūdainas kļūdas noteikÅ”anas. Lai tas nenotiktu, koordinators neziÅo par attÄlÄ mezgla atteici, kad no tÄ pazÅ«d pirmais sirdsdarbÄ«bas ziÅojums, tikai tad, ja pazuduÅ”i vairÄki pÄc kÄrtas.TÄ mums izdevÄs atklÄt koordinatora mezgla atteici 200. jaunkundze.
Bet nepietiek, lai Ätri saprastu, kurÅ” mezgls ir pÄrtraucis darboties. Mums kaut kas ir jÄdara lietas labÄ.
RezervÄcija
KlasiskÄ shÄma paredz, ka galvenÄs neveiksmes gadÄ«jumÄ tiek sÄktas jaunas vÄlÄÅ”anas, izmantojot vienu no algoritmi. TomÄr Å”Ädiem algoritmiem ir labi zinÄmas problÄmas ar laika konverÄ£enci un paÅ”a vÄlÄÅ”anu procesa ilgumu. MÄs varÄjÄm izvairÄ«ties no Å”Ädas papildu kavÄÅ”anÄs, izmantojot koordinatora aizstÄÅ”anas shÄmu pilnÄ«bÄ savienotÄ tÄ«klÄ:
PieÅemsim, ka vÄlamies izpildÄ«t darÄ«jumu grupÄ 50. IepriekÅ” noteiksim aizstÄÅ”anas shÄmu, tas ir, kuri mezgli veiks darÄ«jumus grupÄ 50 galvenÄ koordinatora atteices gadÄ«jumÄ. MÅ«su mÄrÄ·is ir uzturÄt sistÄmas funkcionalitÄti datu centra kļūmes gadÄ«jumÄ. Noteiksim, ka pirmÄ rezerve bÅ«s mezgls no cita datu centra, bet otrÄ rezerve bÅ«s mezgls no treÅ”Ä. Å Ä« shÄma tiek atlasÄ«ta vienreiz un nemainÄs, lÄ«dz mainÄs klastera topoloÄ£ija, tas ir, lÄ«dz tajÄ ienÄk jauni mezgli (kas notiek ļoti reti). Jauna aktÄ«vÄ meistara izvÄles procedÅ«ra, ja vecais neizdodas, vienmÄr bÅ«s Å”Äda: pirmÄ rezerve kļūs par aktÄ«vo meistaru, un, ja tÄ ir pÄrtraukusi darboties, otrÄ rezerve kļūs par aktÄ«vo meistaru.
Å Ä« shÄma ir uzticamÄka par universÄlo algoritmu, jo, lai aktivizÄtu jaunu meistaru, pietiek noteikt vecÄ kļūmi.
Bet kÄ klienti sapratÄ«s, kurÅ” meistars Å”obrÄ«d strÄdÄ? Nav iespÄjams nosÅ«tÄ«t informÄciju tÅ«kstoÅ”iem klientu 50 ms laikÄ. IespÄjama situÄcija, kad klients nosÅ«ta pieprasÄ«jumu atvÄrt darÄ«jumu, vÄl nezinot, ka Å”is meistars vairs nedarbojas, un pieprasÄ«juma noildze beigsies. Lai tas nenotiktu, klienti spekulatÄ«vi nosÅ«ta pieprasÄ«jumu atvÄrt darÄ«jumu grupas meistaram un abÄm viÅa rezervÄm uzreiz, taÄu uz Å”o pieprasÄ«jumu atbildÄs tikai tas, kurÅ” uz doto brÄ«di ir aktÄ«vais saimnieks. Visu turpmÄko saziÅu darÄ«juma ietvaros klients veiks tikai ar aktÄ«vo meistaru.
Rezerves meistari saÅemtos pieprasÄ«jumus par darÄ«jumiem, kas nav viÅu paÅ”u, ievieto nedzimuÅ”o transakciju rindÄ, kur tos kÄdu laiku glabÄ. Ja aktÄ«vais galvenais nomirst, jaunais galvenais apstrÄdÄ pieprasÄ«jumus atvÄrt transakcijas no savas rindas un atbild klientam. Ja klients jau ir atvÄris darÄ«jumu ar vecmeistaru, tad otrÄ atbilde tiek ignorÄta (un, acÄ«mredzot, Å”Äds darÄ«jums netiks pabeigts un klients to atkÄrtos).
KÄ notiek darÄ«jums
PieÅemsim, ka klients nosÅ«tÄ«ja koordinatoram pieprasÄ«jumu atvÄrt darÄ«jumu Å”Ädai un tÄdai entÄ«tijai ar Å”Ädu un tÄdu primÄro atslÄgu. Koordinators bloÄ·Ä Å”o entÄ«tiju un ievieto to atmiÅÄ bloÄ·ÄÅ”anas tabulÄ. Ja nepiecieÅ”ams, koordinators nolasa Å”o entÄ«tiju no krÄtuves un saglabÄ iegÅ«tos datus darÄ«juma stÄvoklÄ« koordinatora atmiÅÄ.
Ja klients vÄlas mainÄ«t datus darÄ«jumÄ, tas koordinatoram nosÅ«ta pieprasÄ«jumu modificÄt entÄ«tiju, un koordinators ievieto jaunos datus transakcijas statusa tabulÄ atmiÅÄ. TÄdÄjÄdi ierakstÄ«Å”ana tiek pabeigta ā krÄtuvÄ netiek veikts ieraksts.
Kad klients aktÄ«vÄ darÄ«juma ietvaros pieprasa savus mainÄ«tos datus, koordinators rÄ«kojas Å”Ädi:
- ja ID jau ir darÄ«jumÄ, tad dati tiek Åemti no atmiÅas;
- ja atmiÅÄ nav ID, tad trÅ«kstoÅ”ie dati tiek nolasÄ«ti no uzglabÄÅ”anas mezgliem, apvienoti ar jau atmiÅÄ esoÅ”ajiem, un rezultÄts tiek nodots klientam.
TÄdÄjÄdi klients var lasÄ«t savas izmaiÅas, bet citi klienti Ŕīs izmaiÅas neredz, jo tÄs tiek saglabÄtas tikai koordinatora atmiÅÄ, tÄs vÄl neatrodas Cassandra mezglos.
Kad klients nosÅ«ta saistÄ«bu izpildi, statusu, kas bija pakalpojuma atmiÅÄ, koordinators saglabÄ reÄ£istrÄtÄ paketÄ un nosÅ«ta kÄ reÄ£istrÄtu partiju uz Cassandra krÄtuvi. Veikali dara visu nepiecieÅ”amo, lai Ŕī pakete tiktu atomiski (pilnÄ«bÄ) uzklÄta, un atgriež atbildi koordinatoram, kurÅ” atbrÄ«vo slÄdzenes un apstiprina klientam darÄ«juma veiksmÄ«gu izpildi.
Un, lai atsauktu, koordinatoram ir tikai jÄatbrÄ«vo atmiÅa, ko aizÅem darÄ«juma stÄvoklis.
IepriekÅ” minÄto uzlabojumu rezultÄtÄ mÄs ieviesÄm ACID principus:
- Atomiskums. TÄ ir garantija, ka neviens darÄ«jums netiks daļÄji ierakstÄ«ts sistÄmÄ; vai nu tiks pabeigtas visas tÄs apakÅ”operÄcijas, vai arÄ« netiks pabeigta neviena. MÄs ievÄrojam Å”o principu, izmantojot reÄ£istrÄto partiju Cassandra.
- Konsekvence. Katrs veiksmÄ«gs darÄ«jums pÄc definÄ«cijas reÄ£istrÄ tikai derÄ«gus rezultÄtus. Ja pÄc darÄ«juma atvÄrÅ”anas un daļu darbÄ«bu veikÅ”anas tiek atklÄts, ka rezultÄts ir nederÄ«gs, tiek veikta atcelÅ”ana.
- IzolÄcija. Kad darÄ«jums tiek izpildÄ«ts, vienlaicÄ«giem darÄ«jumiem nevajadzÄtu ietekmÄt tÄ iznÄkumu. KonkurÄjoÅ”ie darÄ«jumi tiek izolÄti, izmantojot koordinatora pesimistiskus slÄdzenes. LasÄ«Å”anai Ärpus darÄ«juma izolÄcijas princips tiek ievÄrots Read Committed lÄ«menÄ«.
- StabilitÄte. NeatkarÄ«gi no problÄmÄm zemÄkos lÄ«meÅos ā sistÄmas aptumÅ”oÅ”ana, aparatÅ«ras kļūme ā veiksmÄ«gi pabeigta darÄ«juma rezultÄtÄ veiktajÄm izmaiÅÄm ir jÄpaliek saglabÄtÄm, kad darbÄ«ba tiek atsÄkta.
LasÄ«Å”ana pÄc indeksiem
Å emsim vienkÄrÅ”u tabulu:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
ā¦)Tam ir ID (primÄrÄ atslÄga), Ä«paÅ”nieks un modifikÄcijas datums. Jums ir jÄiesniedz ļoti vienkÄrÅ”s pieprasÄ«jums - atlasiet datus par Ä«paÅ”nieku ar maiÅas datumu āpar pÄdÄjo dienuā.
SELECT *
WHERE owner=?
AND modified>?Lai Å”Äds vaicÄjums tiktu Ätri apstrÄdÄts, klasiskajÄ SQL DBVS ir jÄveido indekss pa kolonnÄm (Ä«paÅ”nieks, modificÄts). MÄs to varam izdarÄ«t pavisam vienkÄrÅ”i, jo tagad mums ir ACID garantijas!
Indeksi C*One
Ir avota tabula ar fotogrÄfijÄm, kurÄs ieraksta ID ir primÄrÄ atslÄga.
Indeksam C*One izveido jaunu tabulu, kas ir oriÄ£inÄla kopija. AtslÄga ir tÄda pati kÄ indeksa izteiksme, un tajÄ ir iekļauta arÄ« ieraksta primÄrÄ atslÄga no avota tabulas:
Tagad vaicÄjumu āÄ«paÅ”nieks par pÄdÄjo dienuā var pÄrrakstÄ«t kÄ atlasi no citas tabulas:
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Datu konsekvenci avota tabulas fotoattÄlos un indeksu tabulÄ i1 automÄtiski uztur koordinators. Pamatojoties tikai uz datu shÄmu, kad tiek saÅemtas izmaiÅas, koordinators Ä£enerÄ un saglabÄ izmaiÅas ne tikai galvenajÄ tabulÄ, bet arÄ« kopijÄs. Ar indeksu tabulu netiek veiktas nekÄdas papildu darbÄ«bas, žurnÄli netiek lasÄ«ti un netiek izmantoti bloÄ·ÄtÄji. Tas nozÄ«mÄ, ka indeksu pievienoÅ”ana gandrÄ«z nepatÄrÄ resursus un praktiski neietekmÄ modifikÄciju ievieÅ”anas Ätrumu.
Izmantojot ACID, mÄs varÄjÄm ieviest SQL lÄ«dzÄ«gus indeksus. Tie ir konsekventi, mÄrogojami, Ätri, saliekami un iebÅ«vÄti CQL vaicÄjumu valodÄ. Lai atbalstÄ«tu indeksus, nav nepiecieÅ”amas nekÄdas izmaiÅas lietojumprogrammas kodÄ. Viss ir tikpat vienkÄrÅ”i kÄ SQL. Un pats galvenais, indeksi neietekmÄ sÄkotnÄjÄs darÄ«jumu tabulas modifikÄciju izpildes Ätrumu.
Kas notika
MÄs izstrÄdÄjÄm C*One pirms trim gadiem un uzsÄkÄm to komerciÄlÄ darbÄ«bÄ.
Ko mÄs galu galÄ ieguvÄm? NovÄrtÄsim to, izmantojot fotoattÄlu apstrÄdes un uzglabÄÅ”anas apakÅ”sistÄmas piemÄru, kas ir viens no svarÄ«gÄkajiem datu veidiem sociÄlajÄ tÄ«klÄ. MÄs nerunÄjam par paÅ”u fotogrÄfiju korpusiem, bet gan par visa veida metainformÄciju. Tagad Odnoklassniki ir aptuveni 20 miljardi Å”Ädu ierakstu, sistÄma apstrÄdÄ 80 tÅ«kstoÅ”us lasÄ«Å”anas pieprasÄ«jumu sekundÄ, lÄ«dz 8 tÅ«kstoÅ”iem ACID darÄ«jumu sekundÄ, kas saistÄ«ti ar datu modifikÄciju.
Kad mÄs izmantojÄm SQL ar replikÄcijas koeficientu = 1 (bet RAID 10), fotoattÄlu metainformÄcija tika glabÄta ļoti pieejamÄ 32 maŔīnu klasterÄ«, kurÄ darbojas Microsoft SQL Server (plus 11 dublÄjumkopijas). DublÄjumu glabÄÅ”anai tika atvÄlÄti arÄ« 10 serveri. KopÄ 50 dÄrgas maŔīnas. TajÄ paÅ”Ä laikÄ sistÄma darbojÄs ar nominÄlo slodzi, bez rezerves.
PÄc migrÄÅ”anas uz jauno sistÄmu saÅÄmÄm replikÄcijas koeficientu = 3 ā kopiju katrÄ datu centrÄ. SistÄma sastÄv no 63 Cassandra uzglabÄÅ”anas mezgliem un 6 koordinatora maŔīnÄm, kopÄ 69 serveriem. TaÄu Ŕīs maŔīnas ir daudz lÄtÄkas, to kopÄjÄs izmaksas ir aptuveni 30% no SQL sistÄmas izmaksÄm. TajÄ paÅ”Ä laikÄ slodze tiek saglabÄta 30%.
IevieÅ”ot C*One, samazinÄjÄs arÄ« latentums: SQL sistÄmÄ rakstÄ«Å”anas darbÄ«ba aizÅÄma aptuveni 4,5 ms. C*One - apmÄram 1,6 ms. DarÄ«juma ilgums vidÄji ir mazÄks par 40 ms, commit tiek pabeigts 2 ms, lasÄ«Å”anas un rakstÄ«Å”anas ilgums ir vidÄji 2 ms. 99. procentile - tikai 3-3,1 ms, taimautu skaits ir samazinÄjies 100 reizes - tas viss ir saistÄ«ts ar plaÅ”o spekulÄciju izmantoÅ”anu.
LÄ«dz Å”im lielÄkÄ daļa SQL Server mezglu ir pÄrtraukti; jauni produkti tiek izstrÄdÄti, tikai izmantojot C*One. MÄs pielÄgojÄm C*One darbam mÅ«su mÄkonÄ« , kas ļÄva paÄtrinÄt jaunu klasteru izvietoÅ”anu, vienkÄrÅ”ot konfigurÄciju un automatizÄt darbÄ«bu. Bez pirmkoda to izdarÄ«t bÅ«tu daudz grÅ«tÄk un apgrÅ«tinoÅ”Äk.
Tagad mÄs strÄdÄjam pie pÄrÄjÄs mÅ«su krÄtuves pÄrvietoÅ”anas uz mÄkoni, taÄu tas ir pavisam cits stÄsts.
Avots: www.habr.com