Note. iwwersat.: D'Jaana Dogan ass en erfuerene Ingenieur bei Google, deen de Moment un der Beobachtbarkeet vun de Produktiounsservicer vun der Firma schafft, déi am Go geschriwwen ass. An dësem Artikel, dee grouss Popularitéit ënnert dem engleschsproochege Publikum gewonnen huet, huet si an 17 Punkte wichteg technesch Detailer iwwer DBMSs (an heiansdo verdeelt Systemer am Allgemengen) gesammelt, déi nëtzlech si fir Entwéckler vu groussen / exigent Uwendungen ze berücksichtegen.
Déi grouss Majoritéit vun Computersystemer verfollegen hiren Zoustand an erfuerderen deementspriechend eng Aart vun Datelagerungssystem. Ech hunn Wëssen iwwer Datenbanken iwwer eng laang Zäit gesammelt, laanscht de Wee Designfehler gemaach, déi zu Datenverloscht an Ausfall gefouert hunn. A Systemer déi grouss Bänn vun Informatioun veraarbechten, leien Datenbanken am Häerz vun der Systemarchitektur an handelen als Schlësselelement bei der Wiel vun der optimaler Léisung. Trotz der Tatsaach, datt eng Opmierksamkeet op d'Aarbecht vun der Datebank bezuelt gëtt, sinn d'Problemer, déi d'Applikatiounsentwéckler probéieren virauszesoen, dacks just den Tipp vum Äisbierg. An dëser Serie vun Artikelen deelen ech e puer Iddien, déi nëtzlech sinn fir Entwéckler déi net an dësem Beräich spezialiséiert sinn.
- Dir hutt Gléck wann 99,999% vun der Zäit d'Netzwierk keng Problemer mécht.
- ACID bedeit vill verschidde Saachen.
- All Datebank huet seng eege Mechanismen fir Konsistenz an Isolatioun ze garantéieren.
- Optimistesch Blockéierung kënnt zur Rettung wann et schwéier ass déi üblech ze erhalen.
- Et ginn aner Anomalien nieft dreckeg Liesungen an Dateverloscht.
- D'Datebank an de Benotzer sinn net ëmmer d'accord iwwer den Handlungsverlaf.
- Applikatiounsniveau Sharing kann ausserhalb vun der Applikatioun geréckelt ginn.
- Autoincrementing kann geféierlech sinn.
- Stale Daten kënnen nëtzlech sinn a musse net gespaart ginn.
- Verzerrunge sinn typesch fir all Zäitquellen.
- Verzögerung huet vill Bedeitungen.
- Leeschtung Ufuerderunge solle fir eng spezifesch Transaktioun bewäert ginn.
- Nestéiert Transaktioune kënne geféierlech sinn.
- Transaktioune sollen net un d'Applikatiounsstat gebonnen ginn.
- Query Planer kënnen Iech vill iwwer Datenbanken soen.
- Online Migratioun ass schwéier, awer méiglech.
- Eng bedeitend Erhéijung vun der Datebank bréngt eng Erhéijung vun der Onberechenbarkeet mat.
Ech soen dem Emmanuel Odeke, dem Rein Henrichs an anere Merci fir hire Feedback op eng fréier Versioun vun dësem Artikel.
Dir hutt Gléck wann 99,999% vun der Zäit d'Netzwierk keng Problemer mécht.
D'Fro bleift iwwer wéi zouverlässeg modern Netzwierktechnologien sinn a wéi dacks Systemer erof sinn wéinst Netzwierkfehler. Informatioun iwwer dëst Thema ass knapp a Fuerschung gëtt dacks vu groussen Organisatiounen mat spezialiséierten Netzwierker, Ausrüstung a Personal dominéiert.
Mat enger Disponibilitéitsquote vun 99,999% fir Spanner (Google's global verdeelt Datebank), behaapt Google datt nëmmen Problemer sinn am Reseau Zesummenhang. Zur selwechter Zäit nennt d'Firma säi spezialiséiert Netzwierk den "Haaptpilier" vun der héijer Disponibilitéit. Etude , am Joer 2014 duerchgefouert, fuerdert ee vun de "", deen de Peter Deutsch 1994 formuléiert huet. Ass d'Netzwierk wierklech zouverlässeg?
Eng ëmfaassend Fuerschung ausserhalb vu riesegen Firmen, déi fir de breeden Internet gemaach gëtt, existéiert einfach net. Et gëtt och net genuch Daten vun de grousse Spiller iwwer wéi ee Prozentsaz vun de Probleemer vun hire Clienten Reseau-Zesummenhang sinn. Mir si gutt bewosst iwwer Ausbroch am Netzstack vu grousse Cloud-Provider, déi e ganze Stéck vum Internet fir e puer Stonnen erofhuelen kënnen einfach well se héichprofiléiert Eventer sinn, déi eng grouss Zuel vu Leit a Firmen beaflossen. Netzausbréch kënnen a vill méi Fäll Problemer verursaachen, och wann net all dës Fäll am Luucht sinn. Clientë vu Cloud-Servicer wëssen och näischt iwwer d'Ursaache vu Probleemer. Wann et e Feeler ass, ass et bal onméiglech et un engem Netzwierkfehler op der Säit vum Serviceprovider ze zouzeschreiwen. Fir si sinn Drëtt Partei Servicer schwaarz Këschte. Et ass onméiglech den Impakt ze bewäerten ouni e grousse Serviceprovider ze sinn.
Gitt wat déi grouss Spiller iwwer hir Systemer berichten, et ass sécher ze soen datt Dir Gléck hutt wann d'Netzschwieregkeeten nëmmen e klenge Prozentsaz vu potenziellen Downtime-Problemer ausmaachen. Netzkommunikatioun leiden nach ëmmer vu sou mundane Saachen wéi Hardwarefehler, Topologieännerungen, administrativ Konfiguratiounsännerungen a Stroumausbroch. Viru kuerzem war ech iwwerrascht ze léieren datt d'Lëscht vu méigleche Probleemer bäigefüügt gouf (jo, Dir hutt richteg héieren).
ACID bedeit vill verschidde Saachen
Den Akronym ACID steet fir Atomizitéit, Konsistenz, Isolatioun, Zouverlässegkeet. Dës Eegeschafte vun Transaktiounen sollen hir Validitéit am Fall vu Feeler, Feeler, Hardwarefehler, etc. Ouni ACID oder ähnlech Schemaen wier et schwéier fir Applikatiounsentwéckler ze ënnerscheeden tëscht deem wat se verantwortlech sinn a fir wat d'Datebank verantwortlech ass. Déi meescht relational Transaktiounsdatenbanken probéieren ACID-kompatibel ze sinn, awer nei Approche wéi NoSQL hunn zu villen Datenbanken ouni ACID Transaktiounen entstoen well se deier sinn fir ëmzesetzen.
Wéi ech fir d'éischt an d'Industrie koumen, huet eisen technesche Lead geschwat wéi relevant d'ACID Konzept war. Fir fair ze sinn, gëtt ACID als eng rau Beschreiwung ugesinn anstatt e strikte Implementéierungsstandard. Haut fannen ech et meeschtens nëtzlech well et eng spezifesch Kategorie vun Themen ophëlt (a proposéiert eng Rei vu méigleche Léisungen).
Net all DBMS ass ACID konform; Zur selwechter Zäit verstinn d'Datebankimplementatiounen déi ACID ënnerstëtzen de Set vun Ufuerderungen anescht. Ee vun de Grënn firwat ACID Implementatioune flësseg sinn ass wéinst de ville Trade-offs déi musse gemaach ginn fir ACID Ufuerderunge ëmzesetzen. D'Creatoren kënnen hir Datenbanken als ACID-kompatibel presentéieren, awer d'Interpretatioun vu Randfäll kann dramatesch variéieren, sou wéi de Mechanismus fir "onwahrscheinlech" Eventer ze handhaben. Op d'mannst kënnen d'Entwéckler en héije Verständnis vun de Schwieregkeete vun de Basisimplementatiounen kréien fir e richtegt Verständnis vun hirem speziellen Verhalen an Design Trade-offs ze kréien.
D'Debatt iwwer ob MongoDB mat ACID Ufuerderunge entsprécht geet weider och no der Verëffentlechung vun der Versioun 4. MongoDB gouf fir eng laang Zäit net ënnerstëtzt , obwuel Par défaut Daten op Disk net méi wéi eemol all 60 Sekonnen engagéiert goufen. Stellt Iech de folgende Szenario vir: eng Applikatioun postt zwee Schreiwen (w1 a w2). MongoDB späichert w1 erfollegräich, awer w2 ass verluer wéinst engem Hardwarefehler.
Diagramm deen den Szenario illustréiert. MongoDB crasht ier et Daten op Disk ka schreiwen
Engagement op Disk ass en deiere Prozess. Andeems Dir heefeg Engagementer vermeit, verbesseren d'Entwéckler d'Opnameleistung op Käschte vun der Zouverlässegkeet. MongoDB ënnerstëtzt de Moment Logging, awer dreckeg Schreiwen kënnen nach ëmmer d'Datenintegritéit beaflossen, well d'Logbicher all 100ms als Standard erfaasst ginn. Dat ass, en ähnlechen Szenario ass nach ëmmer méiglech fir Logbicher an d'Ännerungen, déi an hinnen presentéiert ginn, obwuel de Risiko vill méi niddereg ass.
All Datebank huet seng eege Konsequenz an Isolatioun Mechanismen
Vun den ACID Ufuerderunge, Konsistenz an Isolatioun prägen déi gréisst Zuel vu verschiddenen Implementatiounen, well d'Gamme vu Trade-offs méi breet ass. Et muss gesot ginn datt Konsequenz an Isolatioun zimlech deier Funktiounen sinn. Si verlaangen Koordinatioun an Erhéijung Konkurrenz fir Daten Konsequenz. D'Komplexitéit vum Problem erhéicht wesentlech wann et néideg ass d'Datebank horizontal iwwer verschidde Datenzenteren ze skaléieren (besonnesch wa se a verschiddene geographesche Regioune sinn). En héijen Niveau vu Konsistenz z'erreechen ass ganz schwéier, well et och d'Disponibilitéit reduzéiert an d'Netzsegmentéierung erhéicht. Fir eng méi allgemeng Erklärung vun dësem Phänomen, roden ech Iech ze referenzéieren . Et ass och derwäert ze notéieren datt d'Applikatioune kleng Quantitéiten un Inkonsistenz handhaben kënnen, an d'Programméierer kënnen d'Nuancen vum Problem gutt genuch verstoen fir zousätzlech Logik an der Applikatioun ëmzesetzen fir Inkonsistenz ze handhaben ouni vill op d'Datebank ze vertrauen fir se ze handhaben.
DBMSs bidden dacks verschidden Niveaue vun Isolatioun. Applikatioun Entwéckler kënnen déi effektivst wielen op Basis vun hire Virléiften. Niddereg Isolatioun erlaabt eng erhéicht Geschwindegkeet, awer erhéicht och de Risiko vun enger Datenrennen. Héich Isolatioun reduzéiert dës Wahrscheinlechkeet, awer verlangsamt d'Aarbecht a kann zu Konkurrenz féieren, wat zu esou Bremsen an der Basis féiert, datt d'Feeler ufänken.
Iwwerpréiwung vun bestehend concurrency Modeller a Relatiounen tëscht hinnen
De SQL Standard definéiert nëmme véier Isolatiounsniveauen, obwuel et an der Theorie an der Praxis vill méi sinn. bitt en exzellenten Iwwerbléck iwwer existent Konkurrenzmodeller. Zum Beispill, Google Spanner garantéiert extern Serialiséierung mat Auer Synchroniséierung, an obwuel dëst eng méi streng Isolatioun Layer ass, ass et net an Standard Isolatioun Schichten definéiert.
De SQL Standard ernimmt déi folgend Isolatiounsniveauen:
- Serialiséierbar (strengst an deier): Serializable Ausféierung huet déi selwecht Effekt wéi e puer sequenziell Transaktiounen Ausféierung. Sequentiell Ausféierung bedeit datt all spéider Transaktioun eréischt ufänkt nodeems déi virdrun ofgeschloss ass. Et soll feststellen, datt den Niveau Serialiséierbar dacks als sougenannte Snapshot Isolatioun ëmgesat (zum Beispill am Oracle) wéinst Differenzen an der Interpretatioun, obwuel d'Snapshot Isolatioun selwer net am SQL Standard vertruede gëtt.
- Widderhuelend Liesungen: Onengagéiert records an der aktueller Transaktioun sinn fir déi aktuell Transaktioun verfügbar, awer Ännerungen déi vun aneren Transaktioune gemaach goufen (wéi nei Zeilen) .
- Liesen engagéiert: Onengagéiert Donnéeën sinn net fir Transaktiounen verfügbar. An dësem Fall kënnen Transaktiounen nëmmen engagéiert Donnéeën gesinn, a Phantomliesen kënnen optrieden. Wann eng Transaktioun nei Zeilen asetzt an engagéiert, kann déi aktuell Transaktioun se gesinn wann se gefrot ginn.
- Liesen unengagéiert (mannst strikt an deier Niveau): Dreckeg liesen sinn erlaabt, Transaktiounen kann uncommitted Ännerungen vun aneren Transaktiounen gesinn. An der Praxis kann dësen Niveau nëtzlech sinn fir rau Schätzungen, wéi Ufroen
COUNT(*)um Dësch.
Niveau Serialiséierbar miniméiert de Risiko vun Datenrennen, wärend déi deierste fir ëmzesetzen an déi héchst kompetitiv Belaaschtung op de System resultéiert. Aner Isolatiounsniveauen si méi einfach ze implementéieren, awer erhéijen d'Wahrscheinlechkeet vun Datenrennen. E puer DBMS erlaaben Iech e personaliséierten Isolatiounsniveau ze setzen, anerer hu staark Virléiften an net all Niveauen ginn ënnerstëtzt.
Ënnerstëtzung fir Isolatiounsniveauen gëtt dacks an enger bestëmmter DBMS ugekënnegt, awer nëmmen eng virsiichteg Studie vu sengem Verhalen kann opdecken wat tatsächlech geschitt.
Iwwerpréiwung vun concurrency Anomalien op verschidden Isolatioun Niveauen fir verschidden DBMSs
Martin Kleppmann a sengem Projet Vergläicht verschidden Isolatiounsniveauen, schwätzt iwwer Concurrency Anomalien, an ob d'Datebank fäeg ass un e bestëmmten Isolatiounsniveau ze halen. Dem Kleppmann seng Fuerschung weist wéi anescht Datenbankentwéckler iwwer Isolatiounsniveauen denken.
Optimistesch Blockéierung kënnt zur Rettung wann et schwéier ass déi üblech ze erhalen.
Blockéieren kann ganz deier sinn, net nëmme well et d'Konkurrenz an der Datebank erhéicht, awer och well et d'Applikatiounsserver erfuerdert fir stänneg mat der Datebank ze verbannen. Network Segmentatioun kann exklusiv Sperrungssituatiounen verschäerfen an zu Deadlocks féieren, déi schwéier z'identifizéieren an ze léisen. A Fäll wou exklusiv Sperrung net gëeegent ass, hëlleft optimistesch Sperrung.
ass eng Method an där wann Dir e String liest, et seng Versioun, Checksum oder Zäit vun der leschter Ännerung berücksichtegt. Dëst erlaabt Iech sécherzestellen datt et keng atomar Versiounsännerung gëtt ier Dir eng Entrée ännert:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
An dësem Fall, d'Aktualiséierung vun der Tabell products wäert net duerchgefouert ginn wann eng aner Operatioun virdrun Ännerungen an dëser Rei gemaach. Wa keng aner Operatiounen op dëser Zeil ausgefouert goufen, wäert d'Ännerung fir eng Zeil geschéien a mir kënne soen datt den Update erfollegräich war.
Et ginn aner Anomalien nieft dreckeg Liesungen an Dateverloscht
Wann et ëm Datekonsistenz kënnt, ass de Fokus op d'Potenzial fir Rennbedéngungen, déi zu dreckeg Liesungen an Dateverloscht féieren. Wéi och ëmmer, Dateanomalien stoppen net do.
E Beispill vu sou Anomalien ass d'Verzerrung opzehuelen (Schreifweis schreiwen). Verzerrunge si schwéier z'entdecken, well se normalerweis net aktiv gesicht ginn. Si sinn net wéinst dreckeg Liesen oder Datenverloscht, mee vu Verstouss géint logesch Aschränkungen, déi op d'Daten gesat ginn.
Zum Beispill, loosst eis eng Iwwerwaachungsapplikatioun betruechten déi e Bedreiwer erfuerdert fir zu all Moment opruffen:
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;An der uewe genannter Situatioun wäert eng Rekordkorruptioun optrieden wa béid Transaktiounen erfollegräich engagéiert sinn. Obwuel et keng dreckeg Liesungen oder Datenverloscht goufen, gouf d'Integritéit vun den Donnéeën kompromittéiert: elo ginn zwee Leit zur selwechter Zäit ugesinn.
Serializéierbar Isolatioun, Schemadesign oder Datebankbeschränkungen kënnen hëllefen Schreifkorruptioun ze eliminéieren. Entwéckler mussen fäeg sinn esou Anomalien während der Entwécklung z'identifizéieren fir se an der Produktioun ze vermeiden. Zur selwechter Zäit sinn Opnamverzerrungen extrem schwéier fir an der Codebasis ze sichen. Besonnesch a grousse Systemer, wann verschidden Entwécklungsteams verantwortlech sinn fir Funktiounen ëmzesetzen op Basis vun de selwechten Dëscher an net averstanen iwwer d'Spezifizitéiten vum Datezougang.
D'Datebank an de Benotzer sinn net ëmmer eens iwwer wat ze maachen
Ee vun de Schlësselmerkmale vun Datenbanken ass d'Garantie vun der Ausféierungsbestellung, awer dës Bestellung selwer ass vläicht net transparent fir de Softwareentwéckler. Datebanken ausféieren Transaktiounen an der Uerdnung déi se kritt hunn, net an der Uerdnung déi d'Programméierer virgesinn hunn. D'Uerdnung vun Transaktiounen ass schwéier virauszesoen, besonnesch an héich gelueden parallel Systemer.
Wärend der Entwécklung, besonnesch wann Dir mat net-blockéierende Bibliothéiken schafft, e schlechte Stil a geréng Liesbarkeet kënnen d'Benotzer gleewen datt Transaktioune sequenziell ausgefouert ginn, wa se tatsächlech an der Datebank an all Uerdnung ukommen.
Op den éischte Bléck, am Programm hei ënnen, ginn T1 an T2 sequenziell genannt, awer wann dës Funktiounen net blockéieren an direkt d'Resultat an der Form zréckginn , da gëtt d'Uerdnung vun den Uruff bestëmmt duerch d'Momenter wou se an d'Datebank erakomm sinn:
result1 = T1 () // real Resultater sinn Verspriechen
Resultat2 = T2()
Wann Atomitéit erfuerderlech ass (dat heescht, entweder all Operatioune mussen ofgeschloss oder ofgebrach ginn) an d'Sequenz ass wichteg, da mussen d'Operatiounen T1 an T2 bannent enger eenzeger Transaktioun ausgefouert ginn.
Applikatiounsniveau Sharing kann ausserhalb vun der Applikatioun geréckelt ginn
Sharding ass eng Method fir eng Datebank horizontal ze partitionéieren. E puer Datenbanken kënnen automatesch Donnéeën horizontal opdeelen, anerer kënnen dat net oder net ganz gutt sinn. Wann Datenarchitekten / Entwéckler fäeg sinn genau virauszesoen wéi d'Donnéeën zougänglech sinn, kënne se horizontal Partitionen am Benotzerraum erstellen anstatt dës Aarbecht an d'Datebank ze delegéieren. Dëse Prozess gëtt "Uwendungsniveau Sharding" genannt (Sharding op Applikatiounsniveau).
Leider schaaft dësen Numm dacks de Mëssverständnis datt Sharding an Applikatiounsservicer lieft. Tatsächlech kann et als separat Schicht virun der Datebank ëmgesat ginn. Ofhängeg vum Datewuesstum a Schema Iteratiounen, kënnen d'Sharding Ufuerderunge zimmlech komplex ginn. E puer Strategien kënne profitéieren vun der Fäegkeet ze iteréieren ouni Applikatiounsserver nei z'installéieren.
E Beispill vun enger Architektur an där Applikatiounsserver vum Sharding Service getrennt sinn
Plënneren Sharding an e separaten Service erweidert d'Fäegkeet fir verschidde Shardingstrategien ze benotzen ouni d'Notzung vun Uwendungen nei z'installéieren. ass e Beispill vun esou engem Sharding System um Applikatioun Niveau. Vitess liwwert horizontale Sharding fir MySQL an erlaabt Clienten et iwwer de MySQL Protokoll ze verbannen. De System segmentéiert d'Donnéeën a verschidde MySQL Noden déi näischt iwwerenee wëssen.
Autoincrementing kann geféierlech sinn
AUTOINCREMENT ass e gemeinsame Wee fir primär Schlësselen ze generéieren. Et ginn dacks Fäll wou Datenbanken als ID Generatoren benotzt ginn, an d'Datebank enthält Dëscher entworf fir Identifizéierer ze generéieren. Et gi verschidde Grënn firwat Primärschlëssel generéiere mat Auto-Inkrementéierung wäit vun ideal ass:
- An enger verdeeler Datebank ass d'Auto-Inkrementéierung e seriéise Problem. Fir d'ID ze generéieren, ass e globale Spär néideg. Amplaz kënnt Dir en UUID generéieren: dëst erfuerdert keng Interaktioun tëscht verschiddenen Datebankknoten. Auto-Inkrementéierung mat Sperren kann zu Sträit féieren a wesentlech d'Performance op Inserts a verdeelt Situatiounen reduzéieren. E puer DBMSs (zum Beispill MySQL) kënne speziell Konfiguratioun a méi virsiichteg Opmierksamkeet erfuerderen fir d'Master-Master Replikatioun richteg z'organiséieren. An et ass einfach Feeler ze maachen beim Konfiguratioun, wat zu Opnamfehler féiert.
- E puer Datenbanken hunn Partitionalgorithmen baséiert op primäre Schlësselen. Konsekutiv IDen kënnen zu onberechenbaren Hotspots a verstäerkter Belaaschtung op e puer Partitionen féieren, während anerer idle bleiwen.
- E primäre Schlëssel ass de schnellste Wee fir Zougang zu enger Zeil an enger Datebank ze kréien. Mat bessere Weeër fir records z'identifizéieren, kënnen sequentiell IDen déi wichtegst Kolonn an Tabellen an eng nëtzlos Kolonn mat sënnlosen Wäerter verwandelen. Dofir, wa méiglech, wielt w.e.g. e global eenzegaartegen an natierleche primäre Schlëssel (zB Benotzernumm).
Ier Dir op eng Approche entscheet, betruecht den Impakt vun Auto-inkrementéierend IDen an UUIDs op Indexéierung, Partitionéierung a Sharding.
Stale Daten kënnen nëtzlech sinn an net Sperrung erfuerderen
Multiversion Concurrency Control (MVCC) implementéiert vill vun de Konsistenzfuerderungen, déi kuerz uewen diskutéiert goufen. E puer Datenbanken (zum Beispill Postgres, Spanner) benotzen MVCC fir Transaktioune mat Snapshots ze fidderen - eeler Versioune vun der Datebank. Snapshot Transaktiounen kënnen och serialiséiert ginn fir Konsistenz ze garantéieren. Wann Dir vun engem alen Schnappschëss liest, ginn al Daten gelies.
Liesen liicht niddergelooss Donnéeën kann nëtzlech sinn, zum Beispill, wann Analytiken aus den Donnéeën generéiert oder geschätzte aggregéiert Wäerter berechent.
Den éischte Virdeel fir mat legacy Daten ze schaffen ass niddereg latency (besonnesch wann d'Datebank iwwer verschidde Geografien verdeelt ass). Déi zweet ass datt nëmmen liest Transaktioune gespaart sinn. Dëst ass e wesentleche Virdeel fir Applikatiounen déi vill liesen, soulaang se mat alen Daten handhaben.
Den Applikatiounsserver liest Daten aus der lokaler Replika déi 5 Sekonnen net aktuell ass, och wann déi lescht Versioun op der anerer Säit vum Pazifeschen Ozean verfügbar ass
DBMSs läschen automatesch eeler Versiounen an, an e puer Fäll, erlaben Iech dëst op Ufro ze maachen. Zum Beispill, Postgres erlaabt Benotzer ze maachen VACUUM op Ufro, a mécht och periodesch dës Operatioun automatesch. Spanner bedreift e Müllsammler fir Schnappschëss méi al wéi eng Stonn ze läschen.
All Kéier Quellen ënnerleien zu Verzerrung
Dat am beschten gehalene Geheimnis an der Informatik ass datt all Timing APIs leien. Tatsächlech wëssen eis Maschinnen net déi genau aktuell Zäit. Computeren enthalen Quarzkristalle déi Schwéngungen generéieren déi benotzt gi fir Zäit ze halen. Wéi och ëmmer, si sinn net genee genuch a kënne vir/lag hannert der exakter Zäit sinn. D'Verréckelung kann 20 Sekonnen pro Dag erreechen. Dofir muss d'Zäit op eise Computer periodesch mat dem Netzwierk synchroniséiert ginn.
NTP Server gi fir Synchroniséierung benotzt, awer de Synchroniséierungsprozess selwer ass ënner Netzverzögerungen ënnerleien. Och d'Synchroniséierung mat engem NTP-Server am selwechte Rechenzentrum dauert e bëssen Zäit. Et ass kloer datt d'Aarbecht mat engem ëffentlechen NTP-Server zu nach méi grousser Verzerrung féieren kann.
Atomuhren an hir GPS Géigeparteien si besser fir déi aktuell Zäit ze bestëmmen, awer si sinn deier a erfuerderen komplexe Setup, sou datt se net op all Auto installéiert kënne ginn. Dofir benotzen d'Datenzentren eng tiered Approche. Atom- an/oder GPS-Auer weisen déi genee Zäit, duerno gëtt se iwwer sekundär Serveren op aner Maschinnen iwwerdroen. Dëst bedeit datt all Maschinn e gewëssen Offset vun der exakter Zäit erliewen.
D'Situatioun gëtt verschäerft duerch d'Tatsaach datt Uwendungen an Datenbanken dacks op verschiddene Maschinnen lokaliséiert sinn (wann net a verschiddene Rechenzentren). Also wäert d'Zäit net nëmmen op DB Noden ënnerscheeden, déi iwwer verschidde Maschinnen verdeelt sinn. Et wäert och anescht sinn um Applikatiounsserver.
Google TrueTime hëlt eng komplett aner Approche. Déi meescht Leit gleewen datt de Fortschrëtt vu Google an dëser Richtung duerch de banalen Iwwergang op Atom- a GPS-Auer erkläert gëtt, awer dëst ass nëmmen en Deel vum grousse Bild. Hei ass wéi TrueTime funktionnéiert:
- TrueTime benotzt zwou verschidde Quellen: GPS an Atomuhr. Dës Aueren hunn net-korreléiert Ausfallmodi. [kuckt Säit 5 fir Detailer — ca. Iwwersetzung), sou datt hir gemeinsame Gebrauch d'Zouverlässegkeet erhéicht.
- TrueTime huet eng ongewéinlech API. Et gëtt Zäit als Intervall zréck mat Miessfehler an Onsécherheet dran agebaut. Den eigentleche Moment an der Zäit ass iergendwou tëscht den ieweschten an ënneschte Grenze vum Intervall. Spanner, Google verdeelt Datebank, waart einfach bis et sécher ass ze soen datt déi aktuell Zäit ausserhalb vun der Rei ass. Dës Method féiert e puer latency an de System, virun allem wann d'Onsécherheet op de Meeschter héich ass, mee suergt Richtegkeet och an engem global verdeelt Situatioun.
D'Spanner Komponente benotzen TrueTime, wou TT.now () en Intervall zréckkënnt, sou datt de Spanner einfach schléift bis de Punkt wou et zouversiichtlech ka sinn datt déi aktuell Zäit e bestëmmte Punkt passéiert ass
Reduzéiert Genauegkeet bei der Bestëmmung vun der aktueller Zäit bedeit eng Erhéijung vun der Dauer vu Spanner Operatiounen an eng Ofsenkung vun der Leeschtung. Dofir ass et wichteg déi héchst méiglech Genauegkeet ze halen, och wann et onméiglech ass eng komplett korrekt Auer ze kréien.
Verzögerung huet vill Bedeitungen
Wann Dir eng Dosen Experten frot wat e Verspéidung ass, kritt Dir wahrscheinlech verschidden Äntwerten. An DBMS Latenz gëtt dacks "Datebanklatenz" genannt an ass anescht wéi wat vum Client ugesi gëtt. D'Tatsaach ass datt de Client d'Zomm vun der Netzverzögerung an der Datebankverzögerung observéiert. D'Fäegkeet fir d'Zort Latenz ze isoléieren ass kritesch beim Debugging vu wuessende Probleemer. Wann Dir Metriken sammelt an affichéiert, probéiert ëmmer eng Aa op béid Aarte ze halen.
Leeschtung Ufuerderunge solle fir eng spezifesch Transaktioun bewäert ginn
Heiansdo ginn d'Performancecharakteristike vun engem DBMS a seng Aschränkunge spezifizéiert a punkto Schreif / Liesen Duerchgang a Latenz. Dëst bitt en allgemengen Iwwerbléck iwwer Schlësselsystemparameter, awer wann Dir d'Performance vun engem neien DBMS evaluéiert, ass eng vill méi ëmfaassend Approche fir kritesch Operatiounen separat ze evaluéieren (fir all Ufro an / oder Transaktioun). Beispiller:
- Schreift Duerchsatz an Latenz wann Dir eng nei Zeil an den Dësch X setzt (mat 50 Millioune Reihen) mat spezifizéierte Aschränkungen an Zeilpadding an ähnlechen Dëscher.
- Verspéidung fir Frënn vu Frënn vun engem bestëmmte Benotzer ze weisen wann d'Moyenne Zuel vu Frënn 500 ass.
- Latency bei der Recuperatioun vun den Top 100 Entréen aus der Geschicht vun engem Benotzer wann de Benotzer 500 aner Benotzer mat X Entréen pro Stonn verfollegt.
Evaluatioun an Experimentéiere kënnen esou kritesch Fäll enthalen bis Dir zouversiichtlech sidd datt d'Datebank d'Leeschtungsfuerderunge entsprécht. Eng ähnlech Fauschtregel hëlt och dësen Decompte berücksichtegt wann Dir latency Metriken sammelt an SLOs bestëmmen.
Sidd bewosst héich Kardinalitéit wann Dir Metriken fir all Operatioun sammelt. Benotzt Logbicher, Eventsammlung oder verdeelt Tracing fir High-Power Debugging Daten ze kréien. Am Artikel "» Dir kënnt Iech mat Verzögerungs Debugging Methodologien vertraut maachen.
Nestéiert Transaktioune kënne geféierlech sinn
Net all DBMS ënnerstëtzt nestéiert Transaktiounen, awer wann se et maachen, kënnen esou Transaktiounen zu onerwaarte Feeler féieren, déi net ëmmer einfach z'entdecken (dat ass, et sollt offensichtlech sinn datt et eng Aart vun Anomalie gëtt).
Dir kënnt vermeide benotzt nested Transaktiounen mat Clientbibliothéiken déi se erkennen an ëmgoen kënnen. Wann nestéiert Transaktiounen net opginn kënnen, passt besonnesch op an hirer Ëmsetzung fir onerwaart Situatiounen ze vermeiden wou ofgeschloss Transaktiounen zoufälleg ofgebrach ginn wéinst nestéierten.
Encapsuléierend Transaktiounen a verschiddene Schichten kënnen zu onerwaarten nested Transaktioune féieren, a vun engem Code Liesbarkeet Siicht kann et schwéier maachen d'Intentiounen vum Auteur ze verstoen. Kuckt Iech de folgende Programm un:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();Wat wäert d'Ausgab vum uewe genannte Code sinn? Wäert et béid Transaktiounen zréckrollen, oder just déi bannenzeg? Wat geschitt wa mir op verschidde Schichten vu Bibliothéiken vertrauen, déi d'Schafung vun Transaktioune fir eis ëmfaassen? Kënne mir esou Fäll identifizéieren a verbesseren?
Stellt Iech eng Dateschicht mat multiple Operatiounen vir (z. newAccount) ass schonn an hiren eegene Transaktiounen ëmgesat. Wat geschitt wann Dir se als Deel vun enger méi héijer Geschäftslogik leeft déi bannent senger eegener Transaktioun leeft? Wat wier d'Isolatioun an d'Konsistenz an dësem Fall?
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}Amplaz no Äntwerten op sou endlos Froen ze sichen, ass et besser nestéiert Transaktiounen ze vermeiden. No all, kann Är Dateschicht einfach héich-Niveau Operatiounen Leeschtunge ouni seng eege Transaktiounen schafen. Zousätzlech ass d'Geschäftslogik selwer fäeg eng Transaktioun ze initiéieren, Operatiounen dorop auszeféieren, eng Transaktioun ze engagéieren oder ofzebriechen.
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.Transaktioune sollen net un d'Applikatiounsstat gebonnen ginn
Heiansdo ass et verlockend d'Applikatiounszoustand an Transaktiounen ze benotzen fir gewësse Wäerter z'änneren oder Ufroparameter ze tweaken. Déi kritesch Nuance fir ze berücksichtegen ass de korrekten Ëmfang vun der Uwendung. Clienten restarten dacks Transaktiounen wann et Netzwierkproblemer gëtt. Wann d'Transaktioun hänkt dann vun engem Staat of, deen duerch e puer anere Prozess geännert gëtt, kann et de falsche Wäert wielen, jee no der Méiglechkeet vun enger Datenrennen. Transaktiounen mussen de Risiko vun daten Rennen Konditiounen an der Applikatioun betruecht.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...Déi uewe genannte Transaktioun wäert d'Sequenznummer erhéijen all Kéier wann se ausgefouert gëtt, onofhängeg vum Endresultat. Wann d'Verpflichtung wéinst Netzproblemer feelt, gëtt d'Ufro mat enger anerer Sequenznummer ausgefouert wann Dir nach eng Kéier probéiert.
Query Planer kënnen Iech vill iwwer eng Datebank soen
Query Planer bestëmmen wéi eng Ufro an enger Datebank ausgefouert gëtt. Si analyséieren och Ufroen an optimiséieren se ier se se schécken. Planer kënnen nëmmen e puer méiglech Schätzungen ubidden op Basis vun den Signaler, déi hir zur Verfügung stinn. Zum Beispill, wat ass déi bescht Sichmethod fir déi folgend Ufro?
SELECT * FROM articles where author = "rakyll" order by title;D'Resultater kënnen op zwou Méiglechkeeten erfaasst ginn:
- Voll Dësch Scannen: Dir kënnt op all Entrée an der Tabell kucken an Artikelen mat engem passenden Auteur Numm zréck, an dann Uerdnung hinnen.
- Index Scan: Dir kënnt en Index benotze fir passende IDen ze fannen, dës Reihen ze kréien an se dann ze bestellen.
D'Aarbecht vum Ufroplaner ass ze bestëmmen wéi eng Strategie am Beschten ass. Et ass derwäert ze bedenken datt Ufroplaner nëmme limitéiert prévisiv Fäegkeeten hunn. Dëst kann zu schlechten Entscheedunge féieren. DBAs oder Entwéckler kënnen se benotze fir ënnerperforméierend Ufroen ze diagnostizéieren an ze feinjustéieren. Nei Versioune vun der DBMS kënnen Ufroplaner konfiguréieren, a Selbstdiagnos kann hëllefen wann d'Datebank aktualiséiert gëtt wann déi nei Versioun zu Leeschtungsproblemer féiert. Luesen Ufro Logbicher, Latenzprobleem Berichter oder Ausféierungszäitstatistike kënnen hëllefen Ufroen ze identifizéieren déi Optimisatioun brauchen.
E puer Metriken, déi vum Ufroplaner presentéiert ginn, kënne Kaméidi ënnerleien (besonnesch wann Dir latency oder CPU-Zäit schätzt). Eng gutt Ergänzung zu Scheduler sinn Tools fir den Ausféierungswee ze verfolgen an ze verfolgen. Si erlaben Iech esou Problemer ze diagnostizéieren (alsch, net all DBMSs bidden esou Tools).
Online Migratioun ass schwéier awer méiglech
Online Migratioun, Live Migratioun oder Echtzäit Migratioun bedeit vun enger Datebank op déi aner ze plënneren ouni Ënnerbriechung oder Datekorruptioun. Live Migratioun ass méi einfach auszeféieren wann den Iwwergank am selwechte DBMS / Motor geschitt. D'Situatioun gëtt méi komplizéiert wann et néideg ass an en neien DBMS mat verschiddene Leeschtungs- a Schema Ufuerderunge ze plënneren.
Et gi verschidde Online Migratiounsmodeller. Hei ass ee vun hinnen:
- Aktivéiert duebel Entrée a béid Datenbanken. Déi nei Datebank op dëser Etapp huet net all d'Donnéeën, mee acceptéiert nëmmen déi lescht Donnéeën. Wann Dir sécher sidd, kënnt Dir op de nächste Schrëtt weidergoen.
- Aktivéiert Liesen vu béiden Datenbanken.
- Konfiguréiert de System sou datt Liesen a Schreiwen haaptsächlech op der neier Datebank gemaach ginn.
- Stop op déi al Datebank ze schreiwen iwwerdeems weider Daten aus et liesen. Op dëser Etapp ass déi nei Datebank nach e puer Daten ouni. Si sollten aus der aler Datebank kopéiert ginn.
- Déi al Datebank ass nëmme liesen. Kopéiert déi fehlend Daten aus der aler Datebank op déi nei. Nodeems d'Migratioun fäerdeg ass, schalt d'Weeër op déi nei Datebank, a stoppt déi al a läscht se aus dem System.
Fir zousätzlech Informatioune recommandéieren ech Iech ze kontaktéieren , déi Detailer Stripe Migratiounsstrategie baséiert op dësem Modell.
Eng bedeitend Erhéijung vun der Datebank bréngt eng Erhéijung vun der Onberechenbarkeet mat
De Wuesstum vun der Datebank féiert zu onberechenbaren Probleemer verbonne mat senger Skala. Wat mir méi iwwer d'intern Struktur vun enger Datebank wëssen, dest besser kënne mir virauszesoen wéi se skala wäert. Momenter sinn awer nach onméiglech ze virauszesoen.
Wéi d'Basis wächst, kënne fréier Viraussetzungen an Erwaardungen betreffend Datevolumen an Netzwierkbandbreedungsfuerderunge verännert ginn. Dëst ass wann d'Fro vun gréisseren Design Reformen, grouss-Skala operationell Verbesserungen, Iwwerdenken Détachementer, oder Migratioun op aner DBMSs stellt fir potenziell Problemer ze vermeiden.
Awer denkt net datt excellent Kenntnisser vun der interner Struktur vun der existéierender Datebank déi eenzeg Saach ass déi néideg ass. Nei Skalen bréngen nei Onbekannten mat sech. Onberechenbar Péng Punkten, ongläiche Daten Verdeelung, onerwaart Bandbreedung an Hardware Problemer, ëmmer méi Verkéier an nei Reseau Segmenter wäert forcéiere Iech Är Datebank Approche, Datemodell, Deployment Modell, an Datebank Gréisst ze iwwerdenken.
...
Zu där Zäit wou ech ugefaang hunn iwwer dësen Artikel ze publizéieren, waren et scho fënnef méi Elementer op menger ursprénglecher Lëscht. Dunn koum eng grouss Zuel iwwer wat soss ka gedeckt ginn. Dofir beréiert den Artikel op déi mannst offensichtlech Probleemer déi maximal Opmierksamkeet erfuerderen. Dëst bedeit awer net datt d'Thema erschöpft ass an ech wäert net méi an meng zukünfteg Materialien drop zréckkommen a keng Ännerunge fir dat aktuellt maachen.
PS
Liest och op eisem Blog:
- «";
- «";
- «".
Source: will.com