🥇Divê bêtir pêşdebiran di derheqê databasan de vê yekê zanibin

Not. werger.: Jaana Dogan endezyarek pispor e li Google ku niha li ser çavdêriya karûbarên hilberîna pargîdaniyê yên ku di Go de hatine nivîsandin de dixebite. Di vê gotarê de, ku di nav temaşevanên îngilîzîaxêv de populerbûnek mezin bi dest xist, wê di 17 xalan de hûrguliyên teknîkî yên girîng ên di derbarê DBMS-an de (û carinan pergalên belavkirî bi gelemperî) berhev kir ku ji bo pêşdebirên serîlêdanên mezin / daxwazkar têne hesibandin.

Piraniya pergalên komputerê rewşa xwe dişopînin û, li gorî vê yekê, pergala hilanîna daneyê hewce dikin. Min di demek dirêj de zanyarî di derheqê databasan de berhev kir, di rê de xeletiyên sêwiranê yên ku bûn sedema windabûna daneyê û qutbûnê. Di pergalên ku cildên mezin ên agahdariyê pêvajoyê dikin, databas di dilê mîmariya pergalê de ne û di hilbijartina çareseriya çêtirîn de wekî hêmanek bingehîn tevdigerin. Digel vê rastiyê ku baldariyek nêzîk ji xebata databasê re tê dayîn, pirsgirêkên ku pêşdebirên serîlêdanê hewl didin pêşbîniyê bikin, bi gelemperî tenê serê berfê ne. Di vê rêze gotaran de, ez hin ramanan parve dikim ku dê ji bo pêşdebirên ku di vî warî de ne pispor in kêrhatî bin.

Ger 99,999% ji dema ku tora pirsgirêkan dernekeve hûn bextewar in.
ACID tê wateya gelek tiştên cuda.
Her databas mekanîzmayên xwe hene ji bo dabînkirina hevgirtin û veqetandinê.
Astengkirina xweşbîn digihîje alîkariyê dema ku domandina ya asayî dijwar be.
Ji xeynî xwendina qirêj û windakirina daneyan, anomaliyên din jî hene.
Database û bikarhêner her gav li ser qursa çalakiyê li hev nakin.
Parvekirina asta serîlêdanê dikare li derveyî serîlêdanê were guheztin.
Xwe zêdekirin dikare xeternak be.
Daneyên kevnar dikarin bikêr bin û ne hewce ne ku werin girtin.
Texrîbat ji bo her çavkaniyên demkî tîpîk in.
Derengmayîn gelek wateyên xwe hene.
Pêdiviyên performansê divê ji bo danûstendinek taybetî bêne nirxandin.
Danûstandinên nested dikarin xeternak bin.
Divê danûstandin bi dewleta serîlêdanê ve neyên girêdan.
Plansazên pirsê dikarin di derheqê databasan de gelek tiştan ji we re bibêjin.
Koçberiya serhêl dijwar e, lê gengaz e.
Zêdebûnek girîng a di databasê de zêdebûnek nebaweriyê vedigire.

Ez dixwazim spasiya Emmanuel Odeke, Rein Henrichs û yên din bikim ji bo nerînên wan ên li ser guhertoyek berê ya vê gotarê.

Ger 99,999% ji dema ku tora pirsgirêkan dernekeve hûn bextewar in.

Pirs di derbarê teknolojiyên torê yên nûjen de çiqas pêbawer in û çend caran pergal ji ber têkçûna torê têk diçin dimîne. Agahiyên li ser vê mijarê kêm in û lêkolîn bi gelemperî ji hêla rêxistinên mezin ên bi torên pispor, amûr û personel ve têne serdest kirin.

Bi rêjeya hebûna 99,999% ji bo Spanner (danûstendina Google-ê ya gerdûnî ya belavkirî), Google îdîa dike ku tenê 7,6% pirsgirêk bi torê ve girêdayî ne. Di heman demê de, pargîdanî tora xwe ya pispor wekî "stûna sereke" ya hebûna bilind bi nav dike. Xwendina zanko Bailis û Kingsbury, ku di sala 2014 de hat kirin, yek ji "têgihiştinên şaş di derbarê komputera belavkirî de", ku Peter Deutsch di sala 1994 de formule kir. Ma tora bi rastî pêbawer e?

Lêkolîna berfereh li derveyî pargîdaniyên giyanî, ku ji bo înterneta berfirehtir têne kirin, bi tenê tune. Di heman demê de ji lîstikvanên sereke daneyên têr tune ku ji sedî çend pirsgirêkên xerîdarên wan bi torê ve girêdayî ne. Em baş ji qutbûnan di stûna torê ya pêşkêşkerên ewr ên mezin de dizanin ku dikarin perçeyek tevahî ya Înternetê ji bo çend demjimêran hilweşînin, tenê ji ber ku ew bûyerên payebilind in ku bandorê li hejmareke mezin ji kes û pargîdaniyan dikin. Qutbûna torê dikare di gelek rewşan de bibe sedema pirsgirêkan, hetta ku ne hemî van bûyeran di ber çavan de bin. Xerîdarên karûbarên cloudê jî di derbarê sedemên pirsgirêkan de tiştek nizanin. Ger têkçûnek hebe, hema ne gengaz e ku meriv wê bi xeletiyek torê ya li alîyê pêşkêşvanê karûbarê ve girêbide. Ji bo wan, karûbarên sêyemîn qutiyên reş in. Ne gengaz e ku meriv bandorê binirxîne bêyî ku pêşkêşvanek karûbarek mezin be.

Ji ber tiştê ku lîstikvanên mezin di derheqê pergalên xwe de radigihînin, bi ewle ye ku hûn bibêjin ku hûn bi şens in ger ku dijwariyên torê tenê ji sedî piçûk a pirsgirêkên domdar ên potansiyel hesab bikin. Têkiliyên torê hîn jî ji tiştên din ên wekî têkçûna hardware, guhertinên topolojiyê, guheztinên veavakirina îdarî, û qutbûna elektrîkê dikişînin. Di van demên dawî de, ez şaş bûm ku fêr bûm ku navnîşa pirsgirêkên mimkun hate zêdekirin şikên şorkan (erê, te rast bihîst).

ACID tê wateya gelek tiştên cuda

Akronîm ACID ji bo Atomicity, Consistency, Isolation, Reliability radiweste. Van taybetmendiyên danûstendinê têne armanc kirin ku di bûyera têkçûn, xeletî, têkçûna hardware, hwd de rastdariya wan piştrast bikin. Bêyî ACID an nexşeyên mîna wan, ji bo pêşdebirên serîlêdanê dê dijwar be ku cûdahiyê bikin di navbera tiştê ku ew berpirsiyar in û ya ku databas jê berpirsiyar e. Piraniya databasên danûstendinê yên pêwendîdar hewl didin ku bi ACID re lihevhatî bin, lê nêzîkatiyên nû yên mîna NoSQL gelek databasên bêyî danûstendinên ACID-ê peyda kirine ji ber ku pêkanîna wan biha ye.

Dema ku ez yekem car ketim pîşesaziyê, rêberiya meya teknîkî behsa ku têgeha ACID çiqas têkildar bû. Ji bo ku rast be, ACID ji bilî standardek pêkanînek hişk wekî ravekek hişk tê hesibandin. Îro ez pir bikêr dibînim ji ber ku ew kategoriyek taybetî ya pirsgirêkan radixe ber çavan (û cûrbecûr çareseriyên mimkun pêşniyar dike).

Ne her DBMS li gorî ACID e; Di heman demê de, pêkanînên databasê yên ku ACID piştgirî dikin, komek hewcedariyên cûda fêm dikin. Yek ji sedemên ku sepandinên ACID-ê qels in ji ber gelek danûstendinên ku ji bo bicîhanîna daxwazên ACID-ê têne çêkirin e. Dibe ku afirîner databasên xwe wekî ACID-lihevhatî pêşkêş bikin, lê şirovekirina dozên qeraxê dibe ku bi rengek berbiçav cûda bibe, wekî mekanîzmaya birêvebirina bûyerên "bêhtimal". Bi kêmanî, pêşdebiran dikarin têgihiştinek astek bilind a tevliheviyên pêkanînên bingehîn bi dest bixin da ku têgihîştinek rast a behremendiya wan a taybetî û bazirganiya sêwiranê bistînin.

Nîqaşa li ser gelo MongoDB bi daxwazên ACID re tevdigere heya piştî berdana guhertoya 4-ê jî berdewam dike. MongoDB ji bo demek dirêj ve nehatiye piştgirî kirin logging, her çend ji hêla xwerû ve daneya bi dîskê ve ji 60 saniyeyan carekê zêdetir nehate kirin. Senaryoya jêrîn bifikirin: serîlêdanek du nivîsan diweşîne (w1 û w2). MongoDB bi serfirazî w1 hilîne, lê w2 ji ber têkçûna hardware winda dibe.

Diagrama ku senaryoyê nîşan dide. MongoDB berî ku ew daneyên li ser dîskê binivîsîne têk diçe

Dabeşkirina dîskê pêvajoyek biha ye. Bi dûrketina ji peywirên pir caran, pêşdebiran performansa tomarkirinê li gorî pêbaweriyê baştir dikin. MongoDB niha têketinê piştgirî dike, lê nivîsên qirêj hîn jî dikarin bandorê li yekparebûna daneyê bikin ji ber ku têketin her 100ms ji hêla xwerû ve têne girtin. Ango, senaryoyek weha hîn jî ji bo têketin û guheztinên ku di wan de têne pêşkêş kirin gengaz e, her çend xetere pir kêmtir e.

Her databas xwedan mekanîzmayên hevgirtin û veqetandinê ye

Di nav hewcedariyên ACID de, hevgirtin û veqetandin bi hejmareke herî mezin a pêkanînên cihêreng pesnê xwe dide ji ber ku qada bazirganiyê berfirehtir e. Divê bê gotin ku hevgirtin û îzolekirin fonksiyonên pir biha ne. Ew ji bo hevgirtina daneyan hevrêziyê û pêşbaziyê zêde dikin. Tevliheviya pirsgirêkê bi girîngî zêde dibe dema ku pêdivî ye ku databasê bi rengek horizontî li seranserê navendên daneyê yên pirjimar (nemaze heke ew li herêmên cûda yên erdnîgarî ne) were pîvandin. Gihîştina astek bilind a hevgirtinê pir dijwar e, ji ber ku ew jî hebûna kêm dike û dabeşkirina torê zêde dike. Ji bo ravekirinek gelemperî ya vê diyardeyê, ez ji we re şîret dikim ku hûn serî lê bidin teorema CAP. Di heman demê de hêjayî gotinê ye ku serîlêdan dikarin hûrgelên piçûk ên lihevnekirinê bi rê ve bibin, û bernamenûs dikarin hûrgelên pirsgirêkê bi têra xwe baş fam bikin ku mentiqek zêde di serîlêdanê de bicîh bikin da ku nerazîbûnê bigire bêyî ku bi giranî xwe bispêre databasê ku wê hilde.

DBMS bi gelemperî astên cûda yên îzolasyonê peyda dikin. Pêşdebirên serîlêdanê dikarin li gorî vebijarkên xwe ya herî bi bandor hilbijêrin. Tecrîda kêm rê dide leza zêde, lê di heman demê de xetera pêşbaziya daneyê jî zêde dike. Insulasyona bilind vê îhtîmalê kêm dike, lê kar hêdî dike û dibe sedema pêşbaziyê, ku dê bibe sedema şikestinên weha di bingehê de ku têkçûn dest pê bikin.

Vekolîna modelên hevedudanî yên heyî û têkiliyên di navbera wan de

Standarda SQL tenê çar astên îzolasyonê diyar dike, her çend di teorî û pratîkê de gelek zêdetir jî hene. Jepson.io li ser modelên hevedudanî yên heyî nêrînek hêja pêşkêşî dike. Mînakî, Google Spanner bi hevdemkirina demjimêrê re serialîzasyona derveyî garantî dike, û her çend ev qatek îzolasyonê hişktir e jî, ew di qatên îzolasyonê yên standard de nayê destnîşankirin.

Standarda SQL asta îzolasyonê ya jêrîn destnîşan dike:

Serualizable (Ya herî hişk û biha): Darvekirina serializable heman bandorê ye ku hin darvekirina danûstendinê ya rêzdar. Pêkanîna rêzdar tê vê wateyê ku her danûstendina paşîn tenê piştî ku ya berê qediya dest pê dike. Divê bê zanîn ku asta Serualizable ji ber cûdahiyên di şîrovekirinê de, bi gelemperî wekî bi navê îzolekirina wêneya wêneyê (mînakek, di Oracle de) tête bicîh kirin, her çend îzolekirina wêneyê bixwe di standarda SQL de nayê temsîl kirin.
Xwendinên dubarekirî: Di danûstendina heyî de tomarên bêserûber ji danûstandina heyî re hene, lê guhertinên ku ji hêla danûstendinên din ve hatine çêkirin (wek rêzikên nû) nayê dîtin.
Xwendin pêbawer: Daneyên negirêdayî ji bo danûstandinan peyda nabe. Di vê rewşê de, danûstendin tenê dikarin daneyên pêbawer bibînin, û dibe ku xwendinên fantom çêbibin. Ger danûstendinek rêzên nû têxe û pêk bîne, dema ku were pirsîn dê danûstandina heyî karibe wan bibîne.
Bêbawerî bixwînin (asta herî kêm hişk û biha): Xwendinên qirêj têne destûr kirin, danûstendin dikarin guhertinên bêserûber ên ku ji hêla danûstendinên din ve hatine çêkirin bibînin. Di pratîkê de, ev ast dibe ku ji bo texmînên hişk, wek pirsan, bikêr be COUNT(*) li ser masê.

Asta Serualizable metirsiya pêşbaziyên daneyê kêm dike, di heman demê de pêkanîna herî biha ye û di encamê de bargiraniya pêşbaziya herî bilind a pergalê pêk tîne. Asta îzolasyonê ya din hêsantir e ku were bicîh kirin, lê îhtîmala pêşbaziyên daneyê zêde dike. Hin DBMS rê didin we ku hûn astek îzolasyonek xwerû destnîşan bikin, yên din xwedan bijareyên bihêz in û ne hemî ast têne piştgirî kirin.

Piştgiriya ji bo astên veqetandinê bi gelemperî di DBMS-ek diyarkirî de tê reklam kirin, lê tenê lêkolînek baldar a behreya wê dikare eşkere bike ka bi rastî çi diqewime.

Vekolîna anomaliyên hevdemiyê di astên cihêreng ên veqetandinê de ji bo DBMS-yên cihêreng

Martin Kleppmann di projeya xwe de heramîtî Astên cihêreng ên îzolasyonê berhev dike, li ser anomaliyên hevdemiyê diaxive, û gelo databas dikare bi astek taybetî ya îzolasyonê ve girêdayî be. Lêkolîna Kleppmann destnîşan dike ka pêşdebirên databasê çiqas cûda li ser astên veqetandinê difikirin.

Astengkirina xweşbîn digihîje alîkariyê dema ku domandina ya asayî dijwar be.

Astengkirin dikare pir biha be, ne tenê ji ber ku ew pêşbaziyê di databasê de zêde dike, lê di heman demê de ji ber ku ew hewce dike ku serverên serîlêdanê bi domdarî bi databasê ve girêdayî bin. Dabeşkirina torê dikare rewşên kilîtkirina bêkêmasî xirabtir bike û bibe sedema xitimandinên ku naskirin û çareserkirin dijwar e. Di rewşên ku girtina bêkêmasî ne maqûl e, kilîtkirina xweşbîn dibe alîkar.

Qefleya xweşbîn rêbazek e ku tê de dema ku rêzek dixwîne, guhertoya wê, jimareya kontrolê, an dema guherandina dawîn li ber çavan digire. Ev dihêle hûn pê ewle bibin ku berî ku navnîşek biguhezînin guhertoya atomî tune ye:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

Di vê rewşê de, nûvekirina tabloyê products heke operasyonek din berê di vê rêzê de guherandibe dê neyête kirin. Ger li ser vê rêzê operasyonên din nehatin kirin, dê guhertina rêzek çêbibe û em dikarin bibêjin ku nûvekirin serketî bû.

Ji xeynî xwendina qirêj û windakirina daneyan, anomaliyên din jî hene

Dema ku dor tê ser hevgirtina daneyan, bal tê ser potansiyela şert û mercên nijadê ku dikare bibe sedema xwendina qirêj û windakirina daneyê. Lêbelê, anomaliyên daneyê li wir naqedin.

Nimûneyek ji van anomaliyan jî tehlîlkirina tomarkirinê ye (xebatan binivîsin). Tehlîlkirina tehlîlan dijwar e ji ber ku ew bi gelemperî bi rengek çalak nayên lêgerîn. Ew ne ji ber xwendina qirêj an windabûna daneyê ne, lê ji ber binpêkirina astengiyên mantiqî yên li ser daneyan têne danîn.

Mînakî, werin em serîlêdanek çavdêriyê binirxînin ku hewce dike ku yek operator her dem li ser bangê be:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

Di rewşa jorîn de, ger her du danûstendin bi serfirazî bêne kirin dê gendeliyek tomar çêbibe. Her çend xwendinên qirêj an windakirina daneyan tune bûn, yekdestiya daneyan têk çû: naha du kes di heman demê de li ser banga têne hesibandin.

Veqetandina serializable, sêwirana şema, an astengiyên databasê dikare alîkariya rakirina gendeliya nivîsandinê bike. Pêdivî ye ku pêşdebir di dema pêşkeftinê de anomaliyên weha nas bikin da ku di hilberînê de ji wan dûr bikevin. Di heman demê de, guheztinên tomarkirinê di bingeha kodê de zehf dijwar e. Bi taybetî di pergalên mezin de, dema ku tîmên pêşkeftinê yên cihêreng ji pêkanîna fonksiyonan li ser bingeha heman tabloyan berpirsiyar in û li ser taybetmendiyên gihîştina daneyê li hev nakin.

Database û bikarhêner her gav li hev nakin ka çi bikin

Yek ji taybetmendiyên bingehîn ên databasan garantiya fermana darvekirinê ye, lê dibe ku ev ferman bixwe ji pêşdebirê nermalavê re ne zelal be. Database danûstendinan bi rêza ku têne wergirtin, ne bi rêza ku bernamenûs armanc dikin, pêk tînin. Rêzkirina danûstendinan dijwar e ku meriv pêşbîn bike, nemaze di pergalên paralel ên pir barkirî de.

Di dema pêşkeftinê de, nemaze dema ku bi pirtûkxaneyên ne-astengker re dixebitin, şêwaza belengaz û xwendina kêm dikare bibe sedem ku bikarhêner bawer bikin ku danûstendin bi rêzî têne darve kirin, dema ku di rastiyê de ew dikarin bi her rêzê bigihîjin databasê.

Di nihêrîna pêşîn de, di bernameya jêrîn de, T1 û T2 bi rêz têne gazî kirin, lê heke ev fonksiyon ne-asteng in û tavilê encamê di formê de vedigerînin. ahd, wê hingê rêza bangan dê li gorî demên ku ew ketin databasê were destnîşankirin:

encam1 = T1 () // encamên rastîn soz in
encam2 = T2()

Ger atomî hewce bike (ango, divê hemî operasyon bên qedandin an jî betal kirin) û mijarên rêzê, wê hingê divê operasyonên T1 û T2 di nav yek danûstendinê de bêne kirin.

Parvekirina asta serîlêdanê dikare li derveyî serîlêdanê were guheztin

Sharding rêbazek dabeşkirina horîzontal a databasê ye. Hin databas dikarin bixweber daneyan bi horizontî veqetînin, hinên din nekarin, an jî di wê de pir ne baş in. Gava ku mîmarên daneyan / pêşdebiran karibin bi rastî pêşbînî bikin ka dê çawa bigihîje daneyan, ew dikarin li şûna ku vî karî ji databasê re vebêjin, dabeşên horizontal li cîhê bikarhêner biafirînin. Ji vê pêvajoyê re "parvekirina asta serîlêdanê" tê gotin. (parvekirina asta serîlêdanê).

Mixabin, ev nav bi gelemperî têgihîştina xelet diafirîne ku parvekirin di karûbarên serîlêdanê de dijî. Di rastiyê de, ew dikare wekî qatek cûda li ber databasê were bicîh kirin. Bi mezinbûna daneyan û dubarekirina şema ve girêdayî, pêdiviyên parvekirinê dikarin pir tevlihev bibin. Dibe ku hin stratejî ji kapasîteya dubarekirinê bêyî ku ji nû ve sazkirina serverên serîlêdanê sûd werbigirin.

Mînakek mîmariyek ku tê de serverên serîlêdanê ji karûbarê parvekirinê têne veqetandin

Veguheztina parvekirinê di karûbarek cihêreng de şiyana karanîna stratejiyên dabeşkirinê yên cihêreng bêyî hewcedariya ji nû ve vekirina serîlêdanan berfireh dike. Vitesse di asta serîlêdanê de mînakek pergala parvekirinê ya weha ye. Vitess ji bo MySQL parkirina horizontî peyda dike û dihêle xerîdar bi protokola MySQL ve pê ve girêbidin. Pergal daneyan di nav girêkên MySQL yên cihêreng ên ku di derbarê hev de tiştek nizanin dabeş dike.

Xwe zêdekirin dikare xeternak be

AUTOINCREMENT rêyek hevpar e ku ji bo hilberandina mifteyên seretayî ye. Bi gelemperî rewş hene ku databas wekî hilberînerên nasnameyê têne bikar anîn, û databas tabloyên ku ji bo afirandina nasnameyan hatine çêkirin hene. Gelek sedem hene ku çima hilberîna mifteyên bingehîn bi karanîna zêdekirina otomatîkî ji îdeal dûr e:

Di databasek belavkirî de, zêdekirina otomatîk pirsgirêkek cidî ye. Ji bo afirandina nasnameyê, kilîtek gerdûnî hewce ye. Di şûna wê de, hûn dikarin UUID biafirînin: ev pêwendiya di navbera girêkên cihêreng ên databasê de hewce nake. Zêdekirina otomatîkî ya bi qefleyan dikare bibe sedema nakokiyê û di rewşên belavbûyî de performansa li ser insertan bi girîngî kêm bike. Hin DBMS (mînak, MySQL) dibe ku pêdivî bi veavakirina taybetî û baldariyek bêtir hebe da ku bi rêkûpêk birêkûpêkkirina master-master organîze bike. Û ew hêsan e ku meriv di dema mîhengkirinê de xeletiyan bike, ku dê bibe sedema têkçûna tomarkirinê.
Hin databas xwedan algorîtmayên dabeşkirinê yên li ser bingehên sereke hene. Nasnameyên li pey hev dikarin bibin sedema germên nepêşbînîkirî û barkirina zêde li ser hin dabeşan dema ku yên din bêkar bimînin.
Mifteya bingehîn awayê herî bilez e ku meriv bi rêzek di databasê de bigihîje. Bi awayên çêtir ên naskirina tomaran, nasnameyên rêzdar dikarin stûna herî girîng a tabloyan veguherînin stûnek bêkêr ku bi nirxên bêwate tije ye. Ji ber vê yekê, gava ku gengaz be, ji kerema xwe mifteyek bingehîn a gerdûnî ya bêhempa û xwezayî hilbijêrin (mînak navê bikarhêner).

Berî ku hûn li ser nêzîkbûnek biryar bidin, bandora zêdekirina nasnameyan û UUID-yên xweser ên li ser pêvekirin, dabeşkirin û parvekirinê bifikirin.

Daneyên kevnar dikarin bikêr bin û ne hewceyî kilîtkirinê ne

Kontrola Hevdemî ya Pirzimanî (MVCC) gelek hewcedariyên hevgirtinê yên ku li jor bi kurtî hatine nîqaş kirin pêk tîne. Hin databas (mînak, Postgres, Spanner) MVCC bikar tînin da ku danûstendinên bi wêneyan re "xwarin" bikar bînin - guhertoyên kevntir ên databasê. Danûstandinên Snapshot di heman demê de dikarin serialîze bibin da ku hevgirtinê misoger bikin. Dema ku ji wêneyek kevn tê xwendin, daneyên kevnar têne xwendin.

Xwendina daneyên hûrgelê yên kevin dikare bikêr be, mînakî, dema ku analîtîk ji daneyan hildiberîne an jî nirxên giştî yên teqrîb hesab dike.

Awantaja yekem a xebata bi daneyên mîras derengiya kêm e (nemaze heke databas li erdnîgariyên cihêreng were belav kirin). Ya duyemîn ev e ku danûstendinên tenê-xwendin bê kilît in. Ev ji bo serîlêdanên ku pir dixwînin avantajek girîng e, heya ku ew dikarin daneya nebatî bi rê ve bibin.

Pêşkêşkara serîlêdanê daneyên ji kopyaya herêmî dixwîne ku 5 saniye ji mêj ve ye, her çend guhertoya herî dawî li aliyê din ê Okyanûsa Pasîfîkê hebe.

DBMS bixweber guhertoyên kevntir paqij dikin û, di hin rewşan de, dihêlin ku hûn li ser daxwazê vê yekê bikin. Mînakî, Postgres destûrê dide bikarhêneran ku bikin VACUUM li ser daxwazê, û her weha demkî vê operasyonê bixweber pêk tîne. Spanner berhevkarek çopê dimeşîne da ku dîmenên ji saetek mezintir ji holê rabike.

Çavkaniyên her dem di bin tehlûkê de ne

Di zanistiya kompîturê de raza herî baş-parastî ev e ku hemî API-yên demdirêj derew in. Bi rastî, makîneyên me dema niha ya rast nizanin. Komputer krîstalên quartzê hene ku lerizînên ku ji bo domandina demê têne bikar anîn çêdikin. Lêbelê, ew bi têra xwe rast nînin û dibe ku dema rast li pêş / paşde bimînin. Guhertin dikare her roj bigihîje 20 saniyeyan. Ji ber vê yekê, dema li ser komputerên me divê demkî bi yeka torê re were hevdem kirin.

Pêşkêşkerên NTP-ê ji bo hevdengkirinê têne bikar anîn, lê pêvajoya hevdengkirinê bixwe di bin derengiya torê de ye. Tewra hevdengkirina bi serverek NTP-ê re di heman navenda daneyê de hin dem digire. Eşkere ye ku xebitandina bi serverek NTP-ya gelemperî dikare bibe sedema bertengiyek hîn mezintir.

Saetên atomî û hevalbendên wan ên GPS ji bo destnîşankirina dema niha çêtir in, lê ew biha ne û pêdivî bi sazkirina tevlihev heye, ji ber vê yekê ew nikarin li ser her otomobîlê werin saz kirin. Ji ber vê yekê, navendên danûstendinê rêgezek qat bi kar tînin. Saetên atomî û/an GPS demjimêra rast nîşan didin, piştî ku ew bi navgîniya serverên duyemîn ve ji makîneyên din re tê weşandin. Ev tê vê wateyê ku her makîneyek dê ji wextê rast ve deverek diyarkirî biceribîne.

Rewş ji ber vê yekê xirabtir dibe ku serîlêdan û databas bi gelemperî li ser makîneyên cihêreng têne bicîh kirin (heke ne li navendên daneyên cihêreng). Bi vî rengî, dem dê ne tenê li ser girêkên DB yên ku li ser makîneyên cihêreng têne belav kirin cûda bibe. Ew ê li ser servera serîlêdanê jî cûda be.

Google TrueTime nêzîkatiyek bi tevahî cûda digire. Pir kes bawer dikin ku pêşkeftina Google di vî warî de bi veguheztina banalî ya demjimêrên atomî û GPS ve tê ravekirin, lê ev tenê beşek ji wêneya mezin e. Li vir çawa TrueTime dixebite:

TrueTime du çavkaniyên cûda bikar tîne: GPS û demjimêrên atomî. Van demjimêran modên têkçûna ne-girêdayî hene. [Ji bo hûragahiyan li rûpela 5 binêre vir - nêzîkî. werger.), ji ber vê yekê karanîna wan a hevbeş pêbaweriyê zêde dike.
TrueTime xwedan API-yek bêhempa ye. Ew dem wekî navberek bi xeletiya pîvandinê û nezelaliya ku tê de hatî çêkirin vedigerîne. Dema rastîn di wextê de cîhek di navbera sînorên jorîn û jêrîn ên navberê de ye. Spanner, databasa belavkirî ya Google-ê, bi tenê li bendê dimîne heya ku meriv bi ewle bibêje ku dema niha ji rêzê ye. Ev rêbaz hin derengiyê dixe nav pergalê, nemaze heke nezelaliya li ser axayan zêde be, lê di rewşek belavbûyî ya gerdûnî de jî rastdariyê piştrast dike.

Parçeyên Spanner TrueTime bikar tînin, li wir TT.now() navberek vedigerîne, ji ber vê yekê Spanner bi tenê radizê heya wê nuqteyê ku dikare pê ewle bibe ku dema niha ji xalek diyar derbas bûye.

Kêmbûna rastbûna di diyarkirina dema niha de tê wateya zêdebûna dema operasyonên Spanner û kêmbûna performansê. Ji ber vê yekê girîng e ku meriv rastbûna herî zêde ya gengaz biparêze her çend ne gengaz be ku meriv demjimêrek bi tevahî rast bistîne.

Derengmayîn gelek wateyên xwe hene

Ger hûn ji dehan pisporan bipirsin ka dereng çi ye, dibe ku hûn bersivên cûda bistînin. Di DBMS de derengiya bi gelemperî wekî "derengiya databasê" tê gotin û ji ya ku ji hêla xerîdar ve tê fêm kirin cûda ye. Rastî ev e ku xerîdar berhevoka derengiya torê û derengiya databasê temaşe dike. Kapasîteya veqetandina celebê derengmayînê dema ku pirsgirêkên mezin dibin jêbirin krîtîk e. Dema ku metrîkan berhev dikin û nîşan didin, her gav hewl bidin ku çavê xwe li her du celeban bigirin.

Pêdiviyên performansê divê ji bo danûstendinek taybetî bêne nirxandin

Carinan taybetmendiyên performansê yên DBMS-ê û tixûbên wê di warê karûbarê nivîsandin / xwendinê û derengiyê de têne destnîşan kirin. Ev nihêrînek giştî ya pîvanên pergalê yên sereke peyda dike, lê dema ku performansa DBMS-ya nû dinirxîne, nêzîkatiyek pir berfirehtir ew e ku meriv operasyonên krîtîk ji hev cuda binirxîne (ji bo her pirs û / an danûstendinê). Nimûne:

Dema ku rêzek nû têxin tabloya X (bi 50 mîlyon rêzan) bi astengên diyarkirî û pêvekirina rêzê di tabloyên têkildar de rêgez û derengiyê binivîsin.
Dereng xuyangkirina hevalên hevalên bikarhênerek diyarkirî dema ku hejmara navînî ya hevalan 500 be.
Dereng di vegerandina 100 navnîşên herî pêşîn ên ji dîroka bikarhênerek de dema ku bikarhêner 500 bikarhênerên din bi X navnîşan di saetekê de dişopîne.

Dibe ku nirxandin û ceribandin dozên weha krîtîk pêk bînin heya ku hûn pê ewle nebin ku databas hewcedariyên performansê bicîh tîne. Rêgezek bişirîn di heman demê de dema ku metrîkên derengiyê berhev dike û SLO-yan destnîşan dike vê veqetandinê jî dihesibîne.

Dema ku ji bo her operasyonê metrîkan berhev dikin hay ji kardînalîteya bilind hebin. Têketin, berhevkirina bûyeran, an şopandina belavkirî bikar bînin da ku daneyên dakêşana-hêza bilind bistînin. Di gotara "Dixwazin Derengiya Debug bikin?»Hûn dikarin xwe bi metodolojiyên derengkirina xeletiyê nas bikin.

Danûstandinên nested dikarin xeternak bin

Ne her DBMS danûstendinên hêlîn piştgirî dike, lê gava ku ew dikin, danûstendinên weha dikarin bibin sedema xeletiyên nediyar ên ku her gav ne hêsan têne kifş kirin (ango, divê diyar be ku celebek anomalî heye).

Hûn dikarin ji karanîna danûstendinên hêlînê bi karanîna pirtûkxaneyên xerîdar ên ku dikarin wan tespît bikin û derbas bikin dûr bixin. Ger danûstendinên hêlînkirî nekarin dev jê berdin, di pêkanîna wan de baldariyek taybetî bigirin da ku ji rewşên nediyar dûr bikevin ku danûstendinên qedandî bi xeletî ji ber yên hêlînkirî têne sekinandin.

Veguheztina danûstendinan di qatên cihêreng de dikare bibe sedema danûstendinên hêlînên neçaverêkirî, û ji nêrînek xwendina kodê ve, ew dikare fêmkirina niyeta nivîskar dijwar bike. Li bernameya jêrîn binêrin:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

Derketina koda jorîn dê çi be? Ma ew ê her du danûstendinan, an tenê ya hundurîn paşde vegerîne? Ger em xwe bispêrin gelek qatên pirtûkxaneyên ku çêkirina danûstendinan ji bo me vedihewîne, çi dibe? Ma em ê karibin dozên weha nas bikin û baştir bikin?

Xeyalek daneyê bi gelek operasyonan bifikire (mînak. newAccount) jixwe di danûstendinên xwe de pêk tê. Ger hûn wan wekî beşek ji mantiqa karsaziya asta bilind a ku di nav danûstendina xwe de dimeşîne, çi dibe? Di vê rewşê de tecrîd û berdewamî dê çawa be?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

Li şûna ku hûn li bersivên pirsên weha yên bêdawî bigerin, çêtir e ku meriv ji danûstandinên hêlîn dûr bisekine. Beriya her tiştî, tebeqeya daneya we dikare bi hêsanî bêyî çêkirina danûstendinên xwe karûbarên asta bilind pêk bîne. Wekî din, mantiqa karsaziyê bixwe dikare danûstendinek bide destpêkirin, operasyonan li ser wê bike, danûstendinek bike an betal bike.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

Divê danûstandin bi dewleta serîlêdanê ve neyên girêdan

Carinan ceribandinek e ku meriv di danûstendinan de rewşa serîlêdanê bikar bîne da ku hin nirxan biguhezîne an pîvanên pirsê biguhezîne. Nîşaneya krîtîk ku meriv li ber çavan bigire qada rast a serîlêdanê ye. Dema ku pirsgirêkên torê hebin, xerîdar bi gelemperî danûstandinan ji nû ve dest pê dikin. Ger danûstendin wê hingê bi dewletek ve girêdayî ye ku ji hêla pêvajoyek din ve tê guheztin, dibe ku ew nirxa xelet li gorî îhtîmala pêşbaziya daneyê hilbijêrin. Divê danûstendin di serîlêdanê de xetereya şert û mercên pêşbaziya daneyê bihesibînin.

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

Danûstendina li jor her gava ku were darve kirin, bêyî ku encama dawî be, dê hejmara rêzê zêde bike. Ger commit ji ber pirsgirêkên torê têk neçe, dema ku hûn dîsa biceribînin daxwaz dê bi hejmarek rêzek cûda were darve kirin.

Plansazên pirsê dikarin di derheqê databasek de gelek tiştan ji we re bibêjin

Plansazên pirsê diyar dikin ka pirsek dê di databasê de çawa were darve kirin. Ew di heman demê de daxwaziyan analîz dikin û berî ku wan bişînin wan xweşbîn dikin. Plansaz tenê dikarin hin texmînên mimkun li ser bingeha îşaretên di destê wan de peyda bikin. Mînakî, rêbaza lêgerînê ya çêtirîn ji bo pirsa jêrîn çi ye?

SELECT * FROM articles where author = "rakyll" order by title;

Encam dikare bi du awayan were derxistin:

Sekna tabloya tevahî: Hûn dikarin li her têketina tabloyê binihêrin û gotaran bi navek nivîskarek lihevhatî vegerînin, û dûv re wan rêz bikin.
Indeks scan: Hûn dikarin indexek bikar bînin ku nasnameyên lihevhatî bibînin, wan rêzan bistînin, û paşê wan ferman bikin.

Karê plansazkerê pirsê ev e ku diyar bike ka kîjan stratejiyê çêtirîn e. Hêjayî bibîrxistinê ye ku plansazên lêpirsînê tenê xwedan kapasîteyên pêşbîniya tixûbdar in. Ev dikare bibe sedema biryarên xirab. DBA an pêşdebiran dikarin wan bikar bînin da ku lêpirsînên kêm-performandî tespît bikin û baş rast bikin. Guhertoyên nû yên DBMS-ê dikarin plansazên pirsnameyê mîheng bikin, û heke guhertoya nû bibe sedema pirsgirêkên performansê dema nûvekirina databasê dikare bixwe-naskirin bibe alîkar. Têketinên pirsê yên hêdî, raporên pirsgirêka derengbûnê, an statîstîkên dema darvekirinê dikarin alîkariya tespîtkirina pirsên ku hewceyê xweşbîniyê ne bikin.

Dibe ku hin metrîkên ku ji hêla plansazkerê pirsê ve têne pêşkêş kirin bi deng ve girêdayî bin (nemaze dema ku dereng an dema CPU-ê tê texmîn kirin). Zêdebûnek baş a plansazker amûrên ji bo şopandin û şopandina riya darvekirinê ne. Ew dihêlin hûn pirsgirêkên weha teşhîs bikin (heyf, ne hemî DBMS amûrên weha peyda dikin).

Koçberiya serhêl dijwar e lê gengaz e

Koçberiya serhêl, koçberiya zindî, an koçberiya rast-ê tê vê wateyê ku ji databasek berbi yekî din ve diçin bêyî demdirêjî an xirabûna daneyê. Ger veguheztin di heman DBMS/motorê de pêk were koça zindî hêsantir e. Rewş tevlihevtir dibe dema ku pêdivî ye ku meriv berbi DBMSek nû ya bi performans û daxwazên şema yên cihêreng vegere.

Modelên cuda yên koçberiyê yên serhêl hene. Li vir yek ji wan e:

Di herdu databasan de têketina ducar çalak bike. Databasa nû di vê qonaxê de hemî daneyan tune, lê tenê daneyên herî dawî qebûl dike. Gava ku hûn ji vê yekê piştrast bûn, hûn dikarin berbi qonaxa paşîn biçin.
Xwendina ji herdu databasan çalak bike.
Pergalê saz bikin da ku xwendin û nivîsandin di serî de li ser databasa nû were kirin.
Dema ku xwendina daneyan ji wê bidomînin dev ji nivîsandina databasa kevn berdin. Di vê qonaxê de, databasa nû hîn jî ji hin daneyan bêpar e. Divê ew ji databasa kevn werin kopî kirin.
Databasa kevn tenê-xwendin e. Daneyên wenda ji databasa kevn li ya nû kopî bikin. Piştî ku koç qediya, rê li databasa nû biguherînin, û ya kevn rawestînin û ji pergalê jêbirin.

Ji bo agahdariya bêtir, ez pêşniyar dikim ku têkilî bikin gotara, ku stratejiya koçberiyê ya Stripe li ser vê modelê hûrgulî dike.

Zêdebûnek girîng a di databasê de zêdebûnek nebaweriyê vedigire

Mezinbûna databasê bi pîvana wê re têkildar dibe sedema pirsgirêkên nediyar. Her ku em di derheqê avahiya hundurîn a databasê de zanibin, ew qas çêtir em dikarin pêşbînî bikin ka ew ê çawa pîvan bike. Lêbelê, hin deman hîn jî ne gengaz e ku meriv pêşbîn bike.
Her ku bingeh mezin dibe, texmîn û bendewariyên berê yên di derbarê qebareya daneyê û hewcedariyên bandwidahiya torê de dibe ku kevnar bibin. Ev gava ku pirs ji nûvekirinên sêwiranê yên mezin, başkirinên xebitandinê yên mezin, ji nû ve ramîna danînan, an koçkirina DBMS-yên din derdikeve holê da ku ji pirsgirêkên potansiyel dûr nekevin.

Lê nefikirin ku zanîna hêja ya strukturên hundurîn ên databasa heyî tenê tiştek hewce ye. Pîvanên nû dê nenasên nû bi xwe re bînin. Xalên êşê yên nediyar, belavkirina daneya neyeksan, kêşeyên band û hardware yên nediyar, seyrûsefera her ku diçe zêde dibe û beşên torê yên nû dê we neçar bike ku hûn nêzîkatiya databasa xwe, modela daneyê, modela bicîhkirinê, û mezinahiya databasê ji nû ve bifikirin.

...

Wextê ku min dest bi fikirîna weşandina vê gotarê kir, jixwe di navnîşa min a orjînal de pênc tiştên din jî hebûn. Piştre hejmareke mezin hat ramanên nû li ser tiştên din dikarin bên vegirtin. Ji ber vê yekê, gotar li ser pirsgirêkên herî kêm eşkere yên ku bala herî zêde hewce dike vedigire. Lêbelê, ev nayê wê wateyê ku mijar xilas bûye û ez ê êdî di materyalên xwe yên paşerojê de venegerim ser wê û guhertinan di ya heyî de nekim.

PS

Li ser bloga me jî bixwînin:

Source: www.habr.com

Divê bêtir pêşdebiran di derheqê databasan de vê yekê zanibin