🥇Daghang developers ang angay mahibalo niini bahin sa mga database

Nota. transl.: Si Jaana Dogan usa ka eksperyensiyadong inhenyero sa Google nga karon nagtrabaho sa obserbasyon sa mga serbisyo sa produksiyon sa kompanya nga gisulat sa Go. Niini nga artikulo, nga nakabaton ug dakong pagkapopular sa mga mamiminaw nga nagsultig Iningles, nakolekta niya sa 17 ka punto ang importanteng teknikal nga mga detalye bahin sa mga DBMS (ug usahay gipang-apod-apod nga mga sistema sa kinatibuk-an) nga mapuslanong tagdon alang sa mga nag-develop sa dagkong/demanding nga mga aplikasyon.

Ang kadaghanan sa mga sistema sa kompyuter nagsubay sa ilang estado ug, sa ingon, nanginahanglan usa ka matang sa sistema sa pagtipig sa datos. Natigom nako ang kahibalo bahin sa mga database sa taas nga yugto sa panahon, subay sa paghimo sa mga sayop sa disenyo nga misangpot sa pagkawala sa datos ug pagkawala. Sa mga sistema nga nagproseso sa daghang mga volume sa impormasyon, ang mga database nahimutang sa kasingkasing sa arkitektura sa sistema ug naglihok isip usa ka mahinungdanong elemento sa pagpili sa labing maayo nga solusyon. Bisan pa sa kamatuoran nga ang suod nga pagtagad gihatag ngadto sa buhat sa database, ang mga problema nga ang mga developers sa aplikasyon naningkamot sa pagpaabut sa kasagaran lamang sa tumoy sa iceberg. Niini nga serye sa mga artikulo, gipaambit nako ang pipila ka mga ideya nga mapuslanon alang sa mga developer nga dili espesyalista sa kini nga natad.

Swerte ka kung 99,999% sa panahon nga ang network wala magpahinabog mga problema.
Ang ACID nagkahulogan ug daghang lain-laing mga butang.
Ang matag database adunay kaugalingon nga mga mekanismo alang sa pagsiguro sa pagkamakanunayon ug pagkahimulag.
Ang malaumon nga pagbabag moabut sa pagluwas kung lisud ang pagpadayon sa naandan.
Adunay ubang mga anomaliya gawas sa hugaw nga pagbasa ug pagkawala sa datos.
Ang database ug ang user dili kanunay magkauyon sa dagan sa aksyon.
Ang sharding sa lebel sa aplikasyon mahimong ibalhin sa gawas sa aplikasyon.
Ang autoincrement mahimong delikado.
Ang stale data mahimong mapuslanon ug dili kinahanglan nga i-lock.
Ang mga pagtuis kasagaran sa bisan unsang mga tinubdan sa panahon.
Ang paglangan adunay daghang kahulugan.
Ang mga kinahanglanon sa pasundayag kinahanglan nga susihon alang sa usa ka piho nga transaksyon.
Ang mga nested nga transaksyon mahimong delikado.
Ang mga transaksyon kinahanglan dili mahigot sa kahimtang sa aplikasyon.
Ang mga tigplano sa pangutana makasulti kanimo og daghan mahitungod sa mga database.
Lisud ang online migration, pero posible.
Ang usa ka mahinungdanon nga pag-uswag sa database nagkinahanglan og pagtaas sa dili matag-an.

Gusto nakong pasalamatan si Emmanuel Odeke, Rein Henrichs ug uban pa sa ilang feedback sa mas sayo nga bersyon niini nga artikulo.

Swerte ka kung 99,999% sa panahon nga ang network wala magpahinabog mga problema.

Ang pangutana nagpabilin kung unsa ka kasaligan ang modernong mga teknolohiya sa network ug kung unsa ka sagad ang mga sistema nahulog tungod sa mga kapakyasan sa network. Ang impormasyon bahin niini nga isyu nihit ug ang panukiduki sagad gidominar sa dagkong mga organisasyon nga adunay espesyal nga mga network, kagamitan ug kawani.

Uban sa availability rate nga 99,999% alang sa Spanner (Google's globally distributed database), Google nag-angkon nga lamang 7,6% Ang mga problema adunay kalabotan sa network. Sa samang higayon, ang kompanya nagtawag sa iyang espesyal nga network nga "panguna nga haligi" sa taas nga pagkaanaa. Pagtuon Bailis ug Kingsbury, nga gipahigayon niadtong 2014, naghagit sa usa sa "sayop nga pagsabot bahin sa distributed computing", nga giporma ni Peter Deutsch niadtong 1994. Kasaligan ba gyud ang network?

Ang komprehensibo nga panukiduki sa gawas sa mga higanteng kompanya, nga gihimo alang sa mas lapad nga Internet, wala gyud. Wala usab igo nga datos gikan sa mga dagkong magdudula bahin sa kung pila ka porsyento sa mga problema sa ilang mga kostumer ang adunay kalabotan sa network. Kami nahibalo pag-ayo sa mga outages sa network stack sa dagkong cloud providers nga makawagtang sa tibuok tipik sa Internet sulod sa pipila ka oras tungod lang kay kini mga high-profile nga panghitabo nga makaapekto sa daghang tawo ug kompanya. Ang mga pagkawala sa network mahimong hinungdan sa mga problema sa daghang mga kaso, bisan kung dili tanan nga mga kaso naa sa sulud. Ang mga kliyente sa mga serbisyo sa panganod wala usab nahibal-an bahin sa mga hinungdan sa mga problema. Kung adunay kapakyasan, hapit imposible nga ipasangil kini sa usa ka sayup sa network sa kilid sa service provider. Alang kanila, ang mga serbisyo sa ikatulo nga partido mga itom nga kahon. Imposible nga masusi ang epekto kung dili usa ka dako nga tighatag sa serbisyo.

Gihatag kung unsa ang gitaho sa dagkong mga magdudula bahin sa ilang mga sistema, luwas nga isulti nga swerte ka kung ang mga kalisud sa network hinungdan sa gamay nga porsyento sa mga potensyal nga isyu sa downtime. Ang mga komunikasyon sa network nag-antus gihapon sa mga kalibutanon nga butang sama sa pagkapakyas sa hardware, pagbag-o sa topology, pagbag-o sa administratibo nga pag-configure, ug pagkawala sa kuryente. Bag-o lang, natingala ko sa pagkahibalo nga ang listahan sa posibleng mga problema gidugang pinaakan sa iho (oo, husto ang imong nadungog).

Ang ACID nagkahulogan ug daghang lain-laing mga butang

Ang acronym nga ACID nagpasabot sa Atomicity, Consistency, Isolation, Reliability. Kini nga mga kabtangan sa mga transaksyon gituyo aron masiguro ang ilang pagkabalido kung adunay mga kapakyasan, mga sayup, pagkapakyas sa hardware, ug uban pa. Kung wala ang ACID o parehas nga mga laraw, lisud alang sa mga nag-develop sa aplikasyon sa paglainlain tali sa kung unsa ang ilang responsibilidad ug kung unsa ang responsable sa database. Kadaghanan sa mga relational transactional database naningkamot nga mahimong ACID compliant, apan ang mga bag-ong pamaagi sama sa NoSQL nakahatag og daghang mga database nga walay mga transaksyon sa ACID tungod kay kini mahal nga ipatuman.

Sa una nakong pagsulod sa industriya, ang among teknikal nga nanguna naghisgot kung unsa ka kalambigitan ang konsepto sa ACID. Aron mahimong patas, ang ACID giisip nga usa ka dili maayo nga paghulagway kaysa usa ka estrikto nga sumbanan sa pagpatuman. Karon nakit-an nako nga labi ka mapuslanon tungod kay nagpatungha kini usa ka piho nga kategorya sa mga isyu (ug nagsugyot usa ka lainlaing posible nga mga solusyon).

Dili tanang DBMS kay ACID compliant; Sa samang higayon, ang mga pagpatuman sa database nga nagsuporta sa ACID nakasabut sa hugpong sa mga kinahanglanon sa lahi nga paagi. Usa sa mga hinungdan ngano nga ang mga pagpatuman sa ACID dili maayo tungod sa daghang mga trade-off nga kinahanglan buhaton aron mapatuman ang mga kinahanglanon sa ACID. Mahimong ipresentar sa mga tiglalang ang ilang mga database ingon nga nagsunod sa ACID, apan ang interpretasyon sa mga kaso sa edge mahimong lahi kaayo, ingon usab ang mekanismo sa pagdumala sa "dili mahimo" nga mga panghitabo. Sa labing gamay, ang mga developers makakuha og taas nga lebel nga pagsabot sa mga kakuti sa base nga mga pagpatuman aron makabaton og tukmang pagsabot sa ilang espesyal nga kinaiya ug disenyo nga mga trade-off.

Ang debate bahin sa kung ang MongoDB nagsunod sa mga kinahanglanon sa ACID nagpadayon bisan pagkahuman sa pagpagawas sa bersyon 4. Ang MongoDB wala gisuportahan sa dugay nga panahon logging, bisan tuod pinaagi sa default data gitugyan ngadto sa disk dili labaw pa kay sa makausa sa matag 60 segundos. Hunahunaa ang mosunod nga senaryo: ang aplikasyon nag-post ug duha ka sinulat (w1 ug w2). Malampuson nga gitipigan sa MongoDB ang w1, apan nawala ang w2 tungod sa pagkapakyas sa hardware.

Diagram nga naghulagway sa senaryo. Ang MongoDB nahagsa sa wala pa kini makasulat og data sa disk

Ang pagtugyan sa disk usa ka mahal nga proseso. Pinaagi sa paglikay sa kanunay nga mga pasalig, ang mga developer nagpauswag sa recording performance sa gasto sa kasaligan. Gisuportahan karon sa MongoDB ang pag-log, apan ang mga hugaw nga pagsulat mahimo gihapon nga makaapekto sa integridad sa datos tungod kay ang mga troso makuha matag 100ms nga default. Kana mao, ang usa ka susama nga senaryo posible pa alang sa mga troso ug ang mga pagbag-o nga gipresentar niini, bisan kung ang peligro labi ka ubos.

Ang matag database adunay kaugalingon nga pagkamakanunayon ug mga mekanismo sa pagkahimulag

Sa mga kinahanglanon sa ACID, ang pagkamakanunayon ug pagkahimulag gipasigarbo ang pinakadako nga ihap sa lainlaing mga pagpatuman tungod kay ang sakup sa mga trade-off mas lapad. Kinahanglang isulti nga ang pagkamakanunayon ug pag-inusara usa ka mahal nga mga gimbuhaton. Nagkinahanglan sila og koordinasyon ug pagdugang sa kompetisyon alang sa pagkamakanunayon sa datos. Ang pagkakomplikado sa problema modako pag-ayo kung gikinahanglan ang pagsukod sa database nga pinahigda sa daghang mga sentro sa datos (ilabi na kung kini nahimutang sa lain-laing geographic nga mga rehiyon). Ang pagkab-ot sa taas nga lebel sa pagkamakanunayon lisud kaayo, tungod kay kini usab nagpamenos sa pagkaanaa ug nagdugang sa pagbahin sa network. Alang sa mas kinatibuk-ang katin-awan sa kini nga panghitabo, gitambagan ko ikaw nga maghisgot Teorama sa CAP. Angayan usab nga hinumdoman nga ang mga aplikasyon makahimo sa pagdumala sa gamay nga kantidad sa pagkadili makanunayon, ug ang mga programmer makasabut sa mga nuances sa problema nga igo nga ipatuman aron mapatuman ang dugang nga lohika sa aplikasyon aron madumala ang pagkadili makanunayon nga dili magsalig pag-ayo sa database sa pagdumala niini.

Ang mga DBMS kanunay nga naghatag lainlain nga lebel sa pag-inusara. Ang mga developers sa aplikasyon makapili sa labing epektibo base sa ilang gusto. Ang mubu nga pagkahimulag nagtugot alang sa dugang nga katulin, apan nagdugang usab ang peligro sa usa ka lumba sa datos. Ang taas nga insulasyon makapakunhod niini nga kalagmitan, apan makapahinay sa trabaho ug mahimong mosangpot sa kompetisyon, nga mosangpot sa maong mga preno sa base nga magsugod ang mga kapakyasan.

Pagrepaso sa kasamtangan nga mga modelo sa concurrency ug mga relasyon tali kanila

Ang sukaranan sa SQL naghubit lamang sa upat ka lebel sa pagkalainlain, bisan kung sa teorya ug praktis adunay daghan pa. Jepson.io nagtanyag sa usa ka maayo kaayo nga kinatibuk-ang panglantaw sa kasamtangan nga concurrency mga modelo. Pananglitan, gigarantiyahan sa Google Spanner ang eksternal nga serializability nga adunay pag-synchronize sa orasan, ug bisan kung kini usa ka mas estrikto nga layer sa isolation, wala kini gihubit sa standard isolation layers.

Ang sukaranan sa SQL naghisgot sa mosunod nga lebel sa pagkahimulag:

Serializable (labing higpit ug mahal): Serializable execution adunay parehas nga epekto sa pipila ka sequential transaction execution. Ang sequential execution nagpasabot nga ang matag sunod nga transaksyon magsugod lamang human makompleto ang nauna. Kini kinahanglan nga nakita nga ang lebel Serializable kasagarang gipatuman isip gitawag nga snapshot isolation (pananglitan, sa Oracle) tungod sa mga kalainan sa interpretasyon, bisan tuod ang snapshot isolation mismo wala girepresentar sa SQL standard.
Gibalikbalik nga mga pagbasa: Ang wala mapasalig nga mga rekord sa kasamtangan nga transaksyon anaa sa kasamtangan nga transaksyon, apan ang mga kausaban nga gihimo sa ubang mga transaksyon (sama sa bag-ong mga laray) dili makita.
Gipasalig sa pagbasa: Ang wala pasalig nga datos dili magamit alang sa mga transaksyon. Sa kini nga kaso, ang mga transaksyon makakita lamang sa nahimo nga datos, ug ang mga pagbasa sa phantom mahimong mahitabo. Kung ang usa ka transaksyon mosal-ot ug mohimo ug bag-ong mga laray, ang kasamtangan nga transaksyon makakita niini kung gipangutana.
Basaha nga walay pasalig (labing menos estrikto ug mahal nga lebel): Gitugotan ang mga hugaw nga pagbasa, ang mga transaksyon makakita sa wala mabuhat nga mga pagbag-o nga gihimo sa ubang mga transaksyon. Sa praktis, kini nga lebel mahimong mapuslanon alang sa dili maayo nga mga pagbanabana, sama sa mga pangutana COUNT(*) sa lamesa.

nga ang-ang Serializable gipakunhod ang risgo sa mga lumba sa datos, samtang kini ang pinakamahal nga ipatuman ug moresulta sa pinakataas nga kompetisyon nga load sa sistema. Ang ubang mga lebel sa pagkahimulag mas sayon nga ipatuman, apan dugangan ang posibilidad sa mga lumba sa datos. Gitugotan ka sa ubang mga DBMS nga magbutang usa ka naandan nga lebel sa pagkahimulag, ang uban adunay kusgan nga mga gusto ug dili tanan nga lebel gisuportahan.

Ang suporta alang sa mga lebel sa pag-inusara kanunay nga gi-anunsyo sa usa ka gihatag nga DBMS, apan ang usa ka mabinantayon nga pagtuon sa pamatasan niini ang makapadayag kung unsa ang tinuod nga nahitabo.

Pagrepaso sa mga anomaliya sa concurrency sa lain-laing lebel sa pagkahimulag alang sa lain-laing mga DBMS

Martin Kleppmann sa iyang proyekto ermitanyo Itandi ang lainlaing lebel sa pagkahimulag, paghisgot bahin sa mga anomaliya sa panagsama, ug kung ang database makahimo sa pagsunod sa usa ka partikular nga lebel sa pagkahimulag. Ang panukiduki ni Kleppmann nagpakita kung unsa ka lahi ang gihunahuna sa mga developer sa database bahin sa lebel sa pagkalain.

Ang malaumon nga pagbabag moabut sa pagluwas kung lisud ang pagpadayon sa naandan.

Ang pag-block mahimong mahal kaayo, dili lamang tungod kay kini nagdugang sa kompetisyon sa database, apan tungod usab kay kini nagkinahanglan sa mga server sa aplikasyon nga kanunay nga magkonektar sa database. Ang pagbahin sa network mahimong makapasamot sa eksklusibong mga sitwasyon sa pag-lock ug mosangpot sa mga deadlock nga lisud mailhan ug masulbad. Sa mga kaso diin ang eksklusibo nga pag-lock dili angay, ang malaumon nga pag-lock makatabang.

Malaumon nga kandado usa ka paagi diin kung magbasa sa usa ka hilo, gikonsiderar ang bersyon, checksum, o oras sa katapusan nga pagbag-o. Kini nagtugot kanimo sa pagsiguro nga walay atomic nga bersyon nga kausaban sa dili pa mag-ilis sa usa ka entry:

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

Sa kini nga kaso, pag-update sa lamesa products dili ipahigayon kung ang lain nga operasyon kaniadto nagbag-o sa kini nga linya. Kung wala’y ubang mga operasyon nga gihimo sa kini nga laray, ang pagbag-o sa usa ka laray mahitabo ug mahimo naton isulti nga malampuson ang pag-update.

Adunay ubang mga anomaliya gawas sa hugaw nga pagbasa ug pagkawala sa datos

Kung bahin sa pagkamakanunayon sa datos, ang pokus mao ang potensyal alang sa mga kondisyon sa lumba nga mahimong mosangpot sa hugaw nga pagbasa ug pagkawala sa datos. Bisan pa, ang mga anomaliya sa datos wala mohunong didto.

Usa ka pananglitan sa maong mga anomaliya mao ang pagrekord sa pagtuis (isulat ang mga liko). Lisod mahibal-an ang mga pagtuis tungod kay dili kini aktibo nga gipangita. Dili kini tungod sa hugaw nga pagbasa o pagkawala sa datos, apan sa mga paglapas sa lohikal nga mga pagpugong nga gibutang sa datos.

Pananglitan, atong tagdon ang usa ka aplikasyon sa pag-monitor nga nagkinahanglan sa usa ka operator nga on-call sa tanang panahon:

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;

Sa sitwasyon sa ibabaw, ang usa ka rekord nga korapsyon mahitabo kung ang duha ka mga transaksyon malampuson nga nahimo. Bisan kung wala’y hugaw nga pagbasa o pagkawala sa datos, ang integridad sa datos nakompromiso: karon duha ka tawo ang gikonsiderar nga on-call sa parehas nga oras.

Makatabang sa pagwagtang sa korapsyon sa pagsulat ang serializable isolation, schema design, o database constraints. Kinahanglan nga mahibal-an sa mga developer ang ingon nga mga anomaliya sa panahon sa pag-uswag aron malikayan kini sa produksiyon. Sa parehas nga oras, ang pagrekord sa mga pagtuis labi ka lisud nga pangitaon sa base sa code. Ilabi na sa dagkong mga sistema, kung ang lain-laing mga development team ang responsable sa pagpatuman sa mga gimbuhaton base sa parehas nga mga lamesa ug dili magkauyon sa mga detalye sa pag-access sa datos.

Ang database ug ang tiggamit dili kanunay magkauyon kung unsa ang buhaton

Usa sa mga mahinungdanong bahin sa mga database mao ang garantiya sa order sa pagpatuman, apan kini nga order mismo mahimong dili transparent sa software developer. Ang mga database nagpatuman sa mga transaksyon sa han-ay nga ilang nadawat, dili sa order nga gitinguha sa mga programmer. Ang han-ay sa mga transaksyon lisud matagna, labi na sa daghang mga parallel nga sistema.

Atol sa pag-uswag, ilabi na sa pagtrabaho uban sa dili-block nga mga librarya, ang dili maayo nga estilo ug ubos nga pagkabasa mahimong hinungdan sa mga tiggamit sa pagtuo nga ang mga transaksyon gipatuman sunod-sunod, sa diha nga sa pagkatinuod sila moabut sa database sa bisan unsa nga han-ay.

Sa una nga pagtan-aw, sa programa sa ubos, ang T1 ug T2 gitawag nga sunud-sunod, apan kung kini nga mga gimbuhaton dili pag-block ug ibalik dayon ang resulta sa porma gisaad, unya ang han-ay sa mga tawag matino sa mga higayon nga sila misulod sa database:

resulta1 = T1() // ang tinuod nga resulta kay mga saad
resulta2 = T2()

Kung gikinahanglan ang atomicity (nga mao, ang tanan nga mga operasyon kinahanglan makompleto o i-abort) ug ang pagkasunod-sunod nga mga butang, nan ang mga operasyon nga T1 ug T2 kinahanglan nga himuon sulod sa usa ka transaksyon.

Ang sharding sa lebel sa aplikasyon mahimong ibalhin sa gawas sa aplikasyon

Ang Sharding usa ka paagi sa pagbahin sa usa ka database nga horizontally. Ang ubang mga database mahimong awtomatik nga magbahin sa datos nga pinahigda, samtang ang uban dili, o dili kaayo maayo niini. Kung ang mga arkitekto/debeloparyo sa datos makahimo sa pagtagna sa tukma kon sa unsang paagi ma-access ang datos, makahimo silag pinahigda nga mga partisyon sa luna sa user imbes nga itugyan kini nga trabaho ngadto sa database. Kini nga proseso gitawag nga "application-level sharding" (pagbahin sa lebel sa aplikasyon).

Ikasubo, kini nga ngalan kanunay nga nagmugna sa sayop nga pagsabut nga ang sharding nagpuyo sa mga serbisyo sa aplikasyon. Sa tinuud, mahimo kini ipatuman ingon usa ka bulag nga layer sa atubangan sa database. Depende sa pagtubo sa datos ug mga pag-uli sa schema, ang mga kinahanglanon sa sharding mahimong labi ka komplikado. Ang ubang mga estratehiya mahimong makabenepisyo gikan sa abilidad sa pag-uli nga dili kinahanglan nga i-redeploy ang mga server sa aplikasyon.

Usa ka pananglitan sa usa ka arkitektura diin ang mga server sa aplikasyon gibulag gikan sa serbisyo sa sharding

Ang pagbalhin sa sharding ngadto sa usa ka bulag nga serbisyo nagpalapad sa abilidad sa paggamit sa lain-laing mga estratehiya sa sharding nga dili kinahanglan nga i-redeploy ang mga aplikasyon. Vitess usa ka pananglitan sa ingon nga sistema sa sharding sa lebel sa aplikasyon. Naghatag ang Vitess og pinahigda nga sharding alang sa MySQL ug gitugotan ang mga kliyente nga makonektar niini pinaagi sa protocol sa MySQL. Gibahin sa sistema ang datos sa lainlaing mga node sa MySQL nga wala’y nahibal-an bahin sa usag usa.

Ang autoincrement mahimong delikado

Ang AUTOINCREMENT usa ka kasagarang paagi sa pagmugna sa mga nag-unang yawe. Adunay kasagaran nga mga kaso kung ang mga database gigamit isip mga generator sa ID, ug ang database adunay mga lamesa nga gidisenyo aron makamugna og mga identifier. Adunay ubay-ubay nga mga rason ngano nga ang paghimo sa mga nag-unang yawe gamit ang auto-incrementing dili maayo:

Sa usa ka gipang-apod-apod nga database, ang auto-incrementing usa ka seryoso nga problema. Aron makamugna og ID, gikinahanglan ang global lock. Hinunoa, makahimo ka og UUID: wala kini magkinahanglan og interaksyon tali sa lain-laing mga database node. Ang pag-auto-increment gamit ang mga kandado mahimong mosangpot sa panagbingkil ug makapakunhod pag-ayo sa performance sa mga insert sa gipang-apod-apod nga mga sitwasyon. Ang ubang mga DBMS (pananglitan, MySQL) mahimong manginahanglan ug espesyal nga pag-configure ug mas mabinantayon nga pagtagad sa hustong pag-organisar sa master-master replication. Ug dali nga masayop kung mag-configure, nga mosangpot sa mga kapakyasan sa pagrekord.
Ang ubang mga database adunay partitioning algorithm base sa primary keys. Ang sunud-sunod nga mga ID mahimong mosangpot sa dili matag-an nga mga hot spot ug dugang nga load sa pipila ka mga partisyon samtang ang uban nagpabilin nga walay pulos.
Ang panguna nga yawe mao ang labing paspas nga paagi sa pag-access sa usa ka laray sa usa ka database. Uban sa mas maayo nga mga paagi sa pag-ila sa mga rekord, ang mga sequential ID makahimo sa labing importante nga kolum sa mga lamesa ngadto sa usa ka walay pulos nga kolum nga puno sa walay kahulogan nga mga bili. Busa, kung mahimo, palihog pagpili ug usa ka talagsaon ug natural nga pangunang yawe sa tibuok kalibotan (eg username).

Sa dili pa magdesisyon sa usa ka pamaagi, hunahunaa ang epekto sa auto-incrementing nga mga ID ug UUID sa pag-indeks, pagbahin, ug sharding.

Ang stale data mahimong mapuslanon ug wala magkinahanglan og pag-lock

Ang Multiversion Concurrency Control (MVCC) nagpatuman sa daghang mga kinahanglanon sa pagkamakanunayon nga gihisgutan sa ibabaw. Ang ubang mga database (pananglitan, Postgres, Spanner) migamit sa MVCC sa “pagpakaon” sa mga transaksyon nga adunay mga snapshot—karaan nga mga bersyon sa database. Ang mga transaksyon sa snapshot mahimo usab nga serialized aron masiguro ang pagkamakanunayon. Kung nagbasa gikan sa usa ka daan nga snapshot, gibasa ang daan nga datos.

Mahimong mapuslanon ang pagbasa sa gamay nga lipas nga datos, pananglitan, kung maghimo mga analytics gikan sa datos o pagkalkula sa gibanabana nga mga kantidad.

Ang unang bentaha sa pagtrabaho uban sa kabilin nga data mao ang ubos nga latency (ilabi na kon ang database giapod-apod sa lain-laing mga geographies). Ang ikaduha mao nga ang read-only nga mga transaksyon kay walay lock. Kini usa ka hinungdanon nga bentaha alang sa mga aplikasyon nga daghang pagbasa, basta mahimo nila madumala ang mga stale data.

Ang server sa aplikasyon nagbasa sa datos gikan sa lokal nga replika nga 5 segundos nga wala na sa petsa, bisan kung ang pinakabag-o nga bersyon anaa sa pikas bahin sa Dagat Pasipiko

Ang mga DBMS awtomatik nga naglimpyo sa mas daan nga mga bersyon ug, sa pipila ka mga kaso, nagtugot kanimo sa pagbuhat niini sa hangyo. Pananglitan, gitugotan sa Postgres ang mga tiggamit nga buhaton VACUUM sa hangyo, ug usab sa matag karon ug unya sa pagbuhat niini nga operasyon awtomatikong. Gipadagan ni Spanner ang usa ka tigkolekta sa basura aron makuha ang mga snapshot nga sobra sa usa ka oras.

Ang bisan unsang mga tinubdan sa panahon mahimong madaot

Ang labing gitago nga sekreto sa siyensya sa kompyuter mao nga ang tanan nga timing API bakak. Sa tinuud, ang among mga makina wala mahibal-an ang eksakto nga oras karon. Ang mga kompyuter adunay mga kristal nga quartz nga nagpatunghag mga vibrations nga gigamit sa pagtipig sa oras. Bisan pa, kini dili igo nga tukma ug mahimo nga mag-una / malangan sa eksaktong oras. Ang pagbalhin mahimong moabot sa 20 segundos kada adlaw. Busa, ang oras sa among mga kompyuter kinahanglan nga matag karon ug unya nga i-synchronize sa usa nga network.

Ang mga server sa NTP gigamit alang sa pag-synchronize, apan ang proseso sa pag-synchronize mismo gipailalom sa mga paglangan sa network. Bisan ang pag-synchronize sa usa ka NTP server sa parehas nga data center nagkinahanglag panahon. Kini mao ang tin-aw nga ang pagtrabaho uban sa usa ka publiko nga NTP server mahimong mosangpot sa mas dako nga pagtuis.

Ang mga orasan sa atomic ug ang ilang mga katugbang sa GPS mas maayo alang sa pagtino sa karon nga oras, apan kini mahal ug nanginahanglan komplikado nga pag-setup, mao nga dili kini ma-install sa matag awto. Tungod niini, ang mga sentro sa datos naggamit sa usa ka tiered nga pamaagi. Atomic ug/o GPS nga mga orasan nagpakita sa eksakto nga oras, pagkahuman gisibya kini sa ubang mga makina pinaagi sa mga sekondaryang server. Kini nagpasabot nga ang matag makina makasinati og usa ka piho nga offset gikan sa eksaktong oras.

Ang sitwasyon gipasamot sa kamatuoran nga ang mga aplikasyon ug mga database sagad nahimutang sa lain-laing mga makina (kon dili sa lain-laing mga data centers). Sa ingon, ang oras magkalainlain dili lamang sa mga DB node nga giapod-apod sa lainlaing mga makina. Lahi usab kini sa server sa aplikasyon.

Ang Google TrueTime nagkuha ug lahi nga pamaagi. Kadaghanan sa mga tawo nagtuo nga ang pag-uswag sa Google sa kini nga direksyon gipatin-aw sa banal nga pagbalhin sa atomic ug GPS nga mga orasan, apan kini bahin lamang sa dako nga litrato. Ania kung giunsa ang TrueTime nagtrabaho:

Gigamit sa TrueTime ang duha ka lainlaing gigikanan: GPS ug mga orasan sa atomic. Kini nga mga orasan adunay non-correlated failure modes. [tan-awa ang panid 5 para sa mga detalye dinhi - gibanabana. transl.), mao nga ang ilang hiniusang paggamit nagdugang sa pagkakasaligan.
Ang TrueTime adunay dili kasagaran nga API. Gibalik niini ang oras ingon usa ka agwat nga adunay sayup sa pagsukod ug kawalay kasiguruhan nga natukod niini. Ang aktuwal nga gutlo sa panahon anaa sa taliwala sa taas ug ubos nga mga utlanan sa agwat. Ang Spanner, ang gipang-apod-apod nga database sa Google, maghulat lang hangtod luwas nga isulti nga ang karon nga oras wala sa sakup. Kini nga pamaagi nagpaila sa pipila ka latency sa sistema, labi na kung ang kawalay kasiguruhan sa mga agalon taas, apan gisiguro ang pagkatul-id bisan sa usa ka kahimtang nga giapod-apod sa tibuuk kalibutan.

Ang mga sangkap sa Spanner naggamit sa TrueTime, diin ang TT.now() nagbalik sa usa ka agwat, mao nga ang Spanner matulog lang hangtod sa punto diin kini makasalig nga ang karon nga oras milabay sa usa ka piho nga punto.

Ang pagkunhod sa katukma sa pagtino sa karon nga oras nagpasabut nga pagtaas sa gidugayon sa mga operasyon sa Spanner ug pagkunhod sa pasundayag. Kini ang hinungdan ngano nga hinungdanon ang pagpadayon sa labing taas nga posible nga katukma bisan kung imposible nga makakuha usa ka hingpit nga tukma nga relo.

Ang paglangan adunay daghang kahulugan

Kung mangutana ka sa usa ka dosena nga mga eksperto bahin sa kung unsa ang paglangan, tingali makakuha ka ug lainlaing mga tubag. Sa DBMS latency sagad gitawag nga "database latency" ug lahi sa kung unsa ang nakita sa kliyente. Ang kamatuoran mao nga ang kliyente nag-obserbar sa sumada sa paglangan sa network ug sa paglangan sa database. Ang katakus nga ihimulag ang tipo sa latency hinungdanon kung mag-debug sa nagkadako nga mga problema. Kung nagkolekta ug nagpakita sa mga sukatan, sulayi kanunay nga bantayan ang duha nga mga tipo.

Ang mga kinahanglanon sa pasundayag kinahanglan nga susihon alang sa usa ka piho nga transaksyon

Usahay ang mga kinaiya sa pasundayag sa usa ka DBMS ug ang mga limitasyon niini gipiho sa termino sa pagsulat/pagbasa sa throughput ug latency. Naghatag kini og usa ka kinatibuk-ang pagtan-aw sa yawe nga mga parameter sa sistema, apan kung magtimbang-timbang sa paghimo sa usa ka bag-ong DBMS, usa ka labi ka komprehensibo nga pamaagi mao ang gilain nga pagtimbang-timbang sa mga kritikal nga operasyon (alang sa matag pangutana ug / o transaksyon). Mga pananglitan:

Isulat ang throughput ug latency sa dihang magsal-ot ug bag-ong row sa table X (nga adunay 50 ka milyon nga row) nga adunay espesipikong mga limitasyon ug row padding sa may kalabutan nga mga lamesa.
Paglangan sa pagpakita sa mga higala sa mga higala sa usa ka tiggamit kung ang kasagaran nga gidaghanon sa mga higala kay 500.
Latency sa pagkuha sa top 100 entries gikan sa kasaysayan sa usa ka user kung ang user musunod sa 500 ka ubang user nga adunay X entry kada oras.

Ang pagtimbang-timbang ug pag-eksperimento mahimong maglakip sa mga kritikal nga kaso hangtod nga masaligon ka nga ang database nakab-ot ang mga kinahanglanon sa pasundayag. Ang susamang lagda sa kumagko usab nagkonsiderar niini nga pagkahugno sa dihang nagkolekta ug latency metrics ug nagtino sa mga SLO.

Pagmatngon sa taas nga kardinal sa pagkolekta sa mga sukatan alang sa matag operasyon. Paggamit og mga log, pagkolekta sa panghitabo, o gipang-apod-apod nga pagsubay aron makakuha og high-power debugging data. Sa artikulo nga "Gusto nga I-debug ang Latency?»mahimo nimong pamilyar ang imong kaugalingon sa mga pamaagi sa paglangan sa pag-debug.

Ang mga nested nga transaksyon mahimong delikado

Dili tanan nga DBMS nagsuporta sa mga nested nga mga transaksyon, apan kung buhaton nila, ang ingon nga mga transaksyon mahimong moresulta sa wala damha nga mga sayup nga dili kanunay sayon nga makit-an (nga mao, kini kinahanglan nga tataw nga adunay usa ka matang sa anomaliya).

Mahimo nimong malikayan ang paggamit sa mga nested nga transaksyon gamit ang mga librarya sa kliyente nga makamatikod ug makalaktaw niini. Kung dili mabiyaan ang mga nested transactions, pag-amping pag-ayo sa ilang pagpatuman aron malikayan ang wala damha nga mga sitwasyon diin ang mga nahuman nga transaksyon aksidenteng na-abort tungod sa mga nested.

Ang pag-encapsulate sa mga transaksyon sa lain-laing mga layer mahimong mosangpot sa wala damha nga nested nga mga transaksyon, ug gikan sa usa ka code readability point of view, kini makapalisud sa pagsabut sa mga intensyon sa tagsulat. Tan-awa ang mosunod nga programa:

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

Unsa ang mahimong output sa code sa ibabaw? I-roll back ba niini ang duha ka transaksyon, o ang sulod lang? Unsa ang mahitabo kon kita mosalig sa daghang mga lut-od sa mga librarya nga naglangkob sa paghimo sa mga transaksyon alang kanato? Mahimo ba naton mahibal-an ug mapaayo ang ingon nga mga kaso?

Hunahunaa ang usa ka layer sa datos nga adunay daghang mga operasyon (eg. newAccount) gipatuman na sa kaugalingon nga mga transaksyon. Unsa ang mahitabo kung gipadagan nimo kini isip bahin sa mas taas nga lebel nga lohika sa negosyo nga nagdagan sulod sa kaugalingon nga transaksyon? Unsa ang pagkahimulag ug pagkamakanunayon niini nga kaso?

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

Imbes nga mangita og mga tubag sa maong walay katapusan nga mga pangutana, mas maayo nga likayan ang mga nested transactions. Human sa tanan, ang imong data layer dali nga makahimo sa taas nga lebel nga mga operasyon nga dili maghimo sa kaugalingon nga mga transaksyon. Dugang pa, ang lohika sa negosyo mismo makahimo sa pagsugod sa usa ka transaksyon, paghimo sa mga operasyon niini, paghimo o pag-abort sa usa ka transaksyon.

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.

Ang mga transaksyon kinahanglan dili mahigot sa kahimtang sa aplikasyon

Usahay makatintal ang paggamit sa estado sa aplikasyon sa mga transaksyon aron mabag-o ang pipila nga mga kantidad o pag-tweak sa mga parameter sa pangutana. Ang kritikal nga nuance nga tagdon mao ang husto nga sakup sa aplikasyon. Ang mga kliyente kanunay nga mag-restart sa mga transaksyon kung adunay mga problema sa network. Kung ang transaksyon nagdepende sa usa ka estado nga gibag-o sa ubang proseso, mahimo’g pilion ang sayup nga kantidad depende sa posibilidad sa usa ka lumba sa datos. Kinahanglang tagdon sa mga transaksyon ang risgo sa mga kondisyon sa lumba sa datos sa aplikasyon.

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

Ang transaksyon sa ibabaw magdugang sa sequence number sa matag higayon nga kini ipatuman, bisan unsa pa ang katapusan nga resulta. Kung ang commit mapakyas tungod sa mga problema sa network, ang hangyo ipatuman sa lain nga sequence number kung imong sulayan pag-usab.

Ang mga tigplano sa pangutana makasulti kanimo og daghan mahitungod sa usa ka database

Ang mga tigplano sa pangutana nagtino kung giunsa ang usa ka pangutana ipatuman sa usa ka database. Gi-analisar usab nila ang mga hangyo ug gi-optimize kini sa wala pa ipadala kini. Ang mga tigplano makahatag lamang ug pipila ka posibleng pagbanabana base sa mga signal nga ilang magamit. Pananglitan, unsa ang pinakamaayo nga paagi sa pagpangita alang sa mosunod nga pangutana?

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

Ang mga resulta mahimong makuha sa duha ka paagi:

Bug-os nga lamesa scan: Mahimo nimong tan-awon ang matag entry sa lamesa ug ibalik ang mga artikulo nga adunay parehas nga ngalan sa tagsulat, ug dayon i-order kini.
Pag-scan sa indeks: Mahimo nimong gamiton ang usa ka index aron makit-an ang mga katugbang nga ID, pagkuha sa mga linya, ug dayon i-order kini.

Ang trabaho sa tigplano sa pangutana mao ang pagtino kung unsang estratehiya ang labing maayo. Angay nga hunahunaon nga ang mga tigplano sa pangutana adunay limitado nga mga kapabilidad sa pagtagna. Kini mahimong mosangpot sa dili maayo nga mga desisyon. Mahimong gamiton kini sa mga DBA o developer sa pag-diagnose ug pag-ayo sa dili maayo nga mga pangutana. Ang mga bag-ong bersyon sa DBMS mahimong ma-configure ang mga tigplano sa pangutana, ug ang pag-diagnose sa kaugalingon makatabang kung ang pag-update sa database kung ang bag-ong bersyon magdala sa mga problema sa pasundayag. Ang hinay nga query logs, latency issue reports, o execution time statistics makatabang sa pag-ila sa mga pangutana nga nagkinahanglan og optimization.

Ang ubang mga metrics nga gipresentar sa query planner mahimong mapailalom sa kasaba (ilabi na kung gibanabana ang latency o oras sa CPU). Ang usa ka maayong pagdugang sa mga scheduler mao ang mga himan alang sa pagsubay ug pagsubay sa agianan sa pagpatuman. Gitugotan ka nila sa pagdayagnos sa ingon nga mga problema (alaut, dili tanan nga mga DBMS naghatag sa ingon nga mga himan).

Lisod ang online migration pero posible

Ang online migration, live migration, o real-time nga paglalin nagpasabot sa pagbalhin gikan sa usa ka database ngadto sa lain nga walay downtime o data corruption. Ang live migration mas sayon nga buhaton kung ang transisyon mahitabo sulod sa samang DBMS/engine. Ang sitwasyon mahimong mas komplikado kung gikinahanglan ang pagbalhin ngadto sa usa ka bag-ong DBMS nga adunay lain-laing mga kinahanglanon sa performance ug schema.

Adunay lainlaing mga modelo sa online nga paglalin. Ania ang usa kanila:

I-enable ang double entry sa duha ka database. Ang bag-ong database sa kini nga yugto wala ang tanan nga datos, apan gidawat lamang ang pinakabag-o nga datos. Kung sigurado ka niini, mahimo ka nga magpadayon sa sunod nga lakang.
I-enable ang pagbasa gikan sa duha ka database.
I-configure ang sistema aron ang pagbasa ug pagsulat gihimo una sa bag-ong database.
Hunonga ang pagsulat sa daan nga database samtang nagpadayon sa pagbasa sa datos gikan niini. Niini nga yugto, ang bag-ong database wala gihapon sa pipila ka datos. Kinahanglang kopyahon kini gikan sa daan nga database.
Ang daan nga database kay read-only. Kopyaha ang nawala nga datos gikan sa daan nga database ngadto sa bag-o. Human makompleto ang paglalin, ibalhin ang mga agianan sa bag-ong database, ug ihunong ang daan ug tangtangon kini gikan sa sistema.

Alang sa dugang nga impormasyon, girekomendar nako ang pagkontak artikulo, nga nagdetalye sa estratehiya sa paglalin ni Stripe base niini nga modelo.

Ang usa ka mahinungdanon nga pag-uswag sa database nagkinahanglan og pagtaas sa dili matag-an

Ang pag-uswag sa database nagdala sa dili matag-an nga mga problema nga may kalabutan sa sukod niini. Kon mas daghan ang atong nahibal-an mahitungod sa internal nga istruktura sa usa ka database, mas maayo nga atong matagna kung giunsa kini pag-scale. Bisan pa, ang pipila ka mga gutlo imposible gihapon nga makita.
Samtang nagkadako ang base, ang mga nangaging mga pangagpas ug mga gilauman bahin sa gidaghanon sa datos ug mga kinahanglanon sa bandwidth sa network mahimong ma-outdated. Kini kung ang pangutana motungha sa dagkong mga pag-ayo sa disenyo, dagkong mga pagpaayo sa operasyon, paghunahuna pag-usab sa mga deployment, o paglalin ngadto sa ubang mga DBMS aron malikayan ang posibleng mga problema.

Apan ayaw paghunahuna nga ang labing maayo nga kahibalo sa internal nga istruktura sa kasamtangan nga database mao lamang ang gikinahanglan. Ang bag-ong mga timbangan magdala uban kanila og bag-ong mga wala mailhi. Ang dili matag-an nga mga punto sa kasakit, dili patas nga pag-apod-apod sa datos, wala damha nga bandwidth ug mga isyu sa hardware, kanunay nga pagtaas sa trapiko ug bag-ong mga bahin sa network magpugos kanimo sa paghunahuna pag-usab sa imong database approach, data model, deployment model, ug database size.

...

Sa panahon nga nagsugod ako sa paghunahuna bahin sa pagmantala niini nga artikulo, aduna nay lima ka dugang nga mga butang sa akong orihinal nga listahan. Unya miabut ang usa ka dako nga gidaghanon bag-ong mga ideya mahitungod sa unsa pa ang mahimong matabonan. Busa, ang artikulo nagtandog sa labing gamay nga klaro nga mga problema nga nanginahanglan labing taas nga atensyon. Bisan pa, wala kini magpasabut nga ang hilisgutan nahurot na ug dili na ako mobalik niini sa akong umaabot nga mga materyales ug dili na magbag-o sa karon.

PS

Basaha usab sa among blog:

Source: www.habr.com

Daghang mga developer ang kinahanglan mahibal-an kini bahin sa mga database