3.4 Dataarkitektur och lagring

Översikt och motivation

Data överlever kod. Applikationer skrivs om vart par år, men de data de hanterar (kundregister, finansiella huvudböcker, bidragshistorik, hälsojournaler) består i decennier. Det är ofta organisationens mest värdefulla och mest reglerade tillgång. Dataarkitektur är disciplinen att besluta hur datan modelleras, var den lagras, hur den hålls konsistent, hur den utvecklas och hur den serveras tillräckligt snabbt i stor skala. För en stor organisation är dessa beslut grundläggande. Ditt val av lagringsmotorer och datamodeller begränsar vad verksamheten kan göra, hur snabbt den kan röra sig och hur mycket det kostar, under systemets hela liv.

Insatserna är högst i företag och myndigheter på grund av skala, livslängd och reglering. En banks transaktionslager får aldrig förlora eller dubbelräkna ett öre. Ett myndighetsregister måste bevara poster under lagstadgade perioder och bevisa deras integritet för revisorer. Ett hälsosystem måste upprätthålla finkorniga åtkomst- och placeringsregler. Samtidigt betjänar dessa organisationer enorma läs- och skrivvolymer och har inte råd med att varje fråga träffar en enda relationsdatabas. Dataarkitektur måste därför förena korrekthet och beständighet med prestanda och skala, och göra det medan schemat fortsätter ändras för att möta nya mandat.

Det här kapitlet behandlar de stora lagringsparadigmen och när man använder vart och ett, disciplinen polyglot persistens, datamodellering och det ofta underskattade problemet med schemautveckling och migrering, cachelagring och CDN:er (innehållsleveransnätverk) med det ökänt svåra problemet invalidering, och hur transaktioner, låsning och samtidighet beter sig när du driver dem till skala. Den röda tråden är enkel: det finns ingen universell databas. Det finns avvägningar, och god dataarkitektur betyder att välja dem medvetet, en arbetsbelastning i taget.

Nyckelprinciper

Modellera data för att passa åtkomstmönstren, inte tvärtom. Designa lagringen kring hur data kommer att läsas och skrivas, inte kring en abstrakt “korrekt” modell.
Det finns ingen databas som styr dem alla. Olika arbetsbelastningar vill ha olika motorer. Polyglot persistens är normalt i skala.
Korrekthet först för register-system. För auktoritativa data är beständighet och konsistens icke förhandlingsbara. Optimera prestanda runt dem, inte genom dem.
Schemat kommer att ändras, så planera för det. Migreringar är en förstklassig, kontinuerlig teknisk aktivitet, inte en engångsföreteelse.
Äg dina data bakom en tjänstegräns. Varje avgränsad kontext (en självständig domänmodell med sin egen uttryckliga gräns) äger sina data. Att dela en databas kopplar team och förstör autonomi.
Cachelagring är ett korrekthetsproblem förklätt till en prestandavinst. Varje cache introducerar inaktualitet och invalideringsrisk. Behandla det medvetet.
Denormalisering är en avvägning, inte en synd. Att duplicera data för läsprestanda är legitimt om du äger konsistenskonsekvenserna.
Konsistens och skala byter mot varandra. Ju starkare transaktionsgaranti, desto svårare att distribuera. Köp bara vad arbetsbelastningen behöver.

Rekommendationer

Välj lagringsparadigm utifrån arbetsbelastningen

Matcha varje arbetsbelastning mot den modell som passar den. Relationsdatabaser ger stark konsistens, joins och mogna transaktioner. De är standardvalet för register-system och allt med komplexa integritetsregler. Dokumentlager passar hierarkiska, schemaflexibla data som läses som en enhet (en hel order, en hel profil). Nyckel-värdelager ger extrem hastighet för enkla uppslag (sessioner, funktionsflaggor, cachar). Grafdatabaser utmärker sig där relationer är frågan (bedrägerinätverk, organisationsscheman, behörigheter, leveranskedjor). Kolumnorienterade lager driver analytiska frågor som skannar få kolumner över miljarder rader (datalager, rapportering). Tidsseriedatabaser optimerar för tilläggstunga, tidsstämplade data (mått, telemetri, sakernas internet (IoT)-sensorer, marknadsdata). Stå emot att tvinga en motor att göra varje jobb. Att använda en relationsdatabas som kö, eller ett dokumentlager som huvudbok, inbjuder till smärta.

Anta polyglot persistens medvetet

Stora system använder legitimt flera lager: ett relationellt register-system, ett sökindex, en cache, ett analyslager och kanske en graf- eller tidsseriemotor. Det är polyglot persistens, och det är rätt mönster när arbetsbelastningar verkligen skiljer sig. Kostnaden är operativ, eftersom du nu har fler motorer att köra, säkra, säkerhetskopiera och bemanna. Hantera den kostnaden genom att behandla varje lager som ägt av en tjänst, standardisera operativa verktyg och hålla antalet tekniker till de som förtjänar sin plats. Var försiktig med att anta en ny databas för varje mindre behov. Var och en är ett permanent operativt åtagande.

Modellera data och behandla schemautveckling som kontinuerlig

Investera i datamodellering i förväg för register-system. Normalisera för att skydda integriteten och denormalisera sedan selektivt för bevisade läsflaskhalsar. Vilken modell det än är, schemat utvecklas för alltid, så gör migreringar säkra och rutinmässiga. Använd versionerade, automatiserade, framåtgående migreringsskript incheckade i källkodshantering och tillämpade genom driftsättningspipelinen. För ändringar utan driftstopp på stora tabeller, använd mönstret expandera-dra ihop (parallell ändring): lägg till den nya kolumnen eller tabellen, fyll på och dubbelskriv, migrera läsare och ta sedan bort den gamla formen. Aldrig en enda brytande alter. Gör schemaändringar bakåtkompatibla över driftsättningar så att gammal och ny kod körs samtidigt. I händelselagrade eller meddelandebaserade system, versionera dina händelse- och meddelandescheman uttryckligen och stöd uppgradering av gamla händelser (att omvandla dem till det aktuella schemat vid läsning).

Designa cachelagring och invalidering med öppna ögon

Cachelagring och CDN:er är de mest hävstångsstarka prestandaverktygen. Ett CDN serverar statiskt och cachebart innehåll från kanten nära användare, och applikationscachar skonar databasen från upprepade läsningar. Men det svåra är invalidering: att veta när cachade data är inaktuella. Välj en strategi per fall. Använd tidsbaserad utgång (TTL) där lite inaktualitet är acceptabel och enklast. Använd uttrycklig invalidering eller skriv-genom där färskhet spelar roll. Använd cache-vid-sidan där applikationen hanterar fyllningen. Sätt TTL:er medvetet, vakta mot cachestampeder (många klienter som bygger upp samma utgångna post samtidigt) med låsning eller sammanslagning av begäranden och förhindra trampande hjordar på kalla cachar. Cachelagra aldrig data vars inaktualitet kunde orsaka ett korrekthets- eller regelefterlevnadsfel (behörigheter, saldon, samtycke) utan en uttrycklig, testad invalideringsväg. Behandla cachenycklar, TTL:er och invalidering som designade artefakter, inte tillfällig konfiguration.

Hantera transaktioner, låsning och samtidighet för skala

Förstå isoleringsnivåer och välj den svagaste som fortfarande är korrekt för varje transaktion, eftersom högre isolering kostar samtidighet. Föredra optimistisk samtidighet (versionskontroller vid skrivning) för lågkonkurrens, läsintensiva arbetsbelastningar, och sträck dig efter pessimistisk låsning först under genuin het konkurrens, och håll lås korta och konsekvent ordnade för att undvika baklås. När du skalar blir en enda skrivbar databas flaskhalsen. Inför läsrepliker för läsningsskalning (och acceptera replikeringsfördröjning), och sharda/partitionera efter en nyckel som sprider belastningen jämnt och håller relaterade data samman för att undvika transaktioner över shards. Kom ihåg att sharding byter bort enkla joins över shards och ACID-transaktioner (ACID: atomicitet, konsistens, isolering, beständighet) över flera shards, vilket ofta är därför sagor och denormalisering dyker upp. Tillför dessa tekniker först när arbetsbelastningen kräver det. Förhastad sharding lägger till permanent komplexitet.

Avvägningar: för- och nackdelar

Lagertyp	Bäst för	Styrkor	Svagheter
Relationell	Register-system, komplex integritet	ACID, joins, mogna verktyg	Svårare att skala skrivningar horisontellt
Dokument	Aggregatläsningar, flexibelt schema	Snabb läsning/skrivning av hela objekt, flexibelt	Svaga joins/transaktioner mellan dokument
Nyckel-värde	Sessioner, cachar, enkla uppslag	Extrem hastighet och skala	Ingen frågning bortom nyckeln
Graf	Relationstunga frågor	Snabba traverseringar, uttrycksfullt	Nischade driftskunskaper, skalningsgränser
Kolumnorienterad	Analys, rapportering	Snabba aggregatskanningar, komprimering	Dålig för transaktionella skrivningar på radnivå
Tidsserie	Mått, telemetri, IoT	Effektiv tillägg och tidsfrågor	Snävt syfte

Den dominerande avvägningen är konsistens och rik frågning mot horisontell skalbarhet och hastighet. Relationssystem ger de starkaste garantierna och de mest flexibla frågorna, men är svårast att skala skrivningar över många maskiner. NoSQL-familjer (icke-relationella) slappnar av joins, transaktioner eller schema för att vinna skala och hastighet. Cachelagring byter färskhet mot latens. Sharding byter transaktioner över partitioner mot skrivgenomströmning. Inget av dessa är universellt rätt. Konsten är att placera varje arbetsbelastning på den punkt av kurvan som dess korrekthets- och prestandabehov faktiskt kräver.

Frågor att diskutera med ditt team

Kan alla för varje kritisk datamängd namnge det enda register-systemet, eller behandlas cachar och projektioner i det tysta som sanning? Data överlever kod, och de mest skadliga dataincidenterna kommer av drift: en cache, ett sökindex eller en läsprojektion förväxlas med auktoritativ och avviker tyst från den verkliga källan. I ett stort team händer detta när ägarskapet är suddigt och flera tjänster skriver överlappande kopior, så att ingen kan säga vilket värde som är korrekt under en incident. Ta med en karta över era viktiga data och, för varje post, det enda lager som är auktoritativt plus de härledda kopior som måste kunna byggas upp igen från det. Inom finans och myndigheter är förmågan att bevisa vilken post som är den rättsliga källan och rekonstruera resten ofta ett regulatoriskt krav, inte en bekvämlighet. Allt ni inte kan bygga upp igen från register-systemet är i sig ett register-system, oavsett om ni menade det eller inte.
Vad kostar varje databasmotor i er egendom faktiskt att köra, säkra och säkerhetskopiera, och förtjänar var och en fortfarande sin plats? Polyglot persistens är rätt när arbetsbelastningar verkligen skiljer sig, men varje motor är ett permanent operativt åtagande: patchning, säkerhetskopior, övervakning, säkerhetsgranskning och personal som kan den klockan tre på natten. En stor organisation kan driva in i ett zoo av lager antagna för en funktion vardera, och det marginella lagret lägger till kostnad för alltid medan det betjänar en arbetsbelastning ett lager ni redan kör kunde hantera. Lista varje motor, arbetsbelastningen som motiverar den och vem som har jour för den, och flagga sedan alla antagna för ett behov ett primärlager nu kunde möta. Ny databasadoption bör klara en hög ribba, eftersom att ta bort en senare betyder ännu en migrering. Att standardisera operativa verktyg över de lager ni behåller är hur ni håller kostnaden nere utan att tvinga en motor att göra varje jobb.
Var kan en användare läsa ett inaktuellt värde från en replik direkt efter sin egen skrivning, och bryter det ett löfte ni gav hen? Läsrepliker skalar läsningar men släpar efter primären, så en användare som uppdaterar en profil och omedelbart laddar om kan se det gamla värdet, vilket läses som en bugg eller, för ett saldo eller en samtyckesflagga, ett regelefterlevnadsfel. Besluta per flöde om läs-dina-skrivningar spelar roll, och led de läsningarna till primären eller använd en sessionskonsistensmekanism. Ta med listan över flöden som serveras från repliker och markera vilka en användare agerar på omedelbart efter skrivning. För saldon, behörigheter och samtycke, behandla inaktuella läsningar som korrekthetsfel, inte kosmetiska. Poängen är att köpa den konsistens varje arbetsbelastning faktiskt behöver, och att göra den inaktualitet ni accepterar uttrycklig snarare än oavsiktlig.
Kan ni ändra schemat för er största, mest trafikerade tabell i dag utan driftstopp, och vem har faktiskt repeterat expandera-dra ihop-stegen? Schemat utvecklas för alltid, och felet som gör mest ont är en storskalig alter som låser en enorm tabell, fryser tjänsten och inte kan rullas tillbaka rent. I ett stort team multipliceras risken eftersom flera tjänster läser samma form, så en brytande ändring behöver gammal och ny kod som körs sida vid sida över en stegvis driftsättning. Det motstridiga draget är hastighet: en enda alter är snabb att skriva, medan expandera-dra ihop (lägg till den nya formen, fyll på, dubbelskriv, migrera läsare, ta bort den gamla formen) är fler steg och mer tålamod. Ta med er största tabell, en ärlig uppskattning av hur länge en naiv alter skulle låsa den och en specifik migrering någon har kört från början till slut i en repetition snarare än i teorin. I företags- och myndighetssystem som körs kontinuerligt och bär lagstadgade tillgänglighetsmål är driftstopp för en migrering ett brott, så expandera-dra ihop-disciplinen är priset för att över huvud taget få ändra schemat.
Vilka cachade eller replikerade värden skulle, om de serverades inaktuella, orsaka ett regelefterlevnads- eller säkerhetsfel snarare än ett kosmetiskt, och är varje sådan invalideringsväg testad? Cachelagring är ett korrekthetsproblem klätt i en prestandakostym: faran är inte långsamhet utan att servera en behörighet, ett saldo, en samtyckesflagga eller ett åtkomstbeslut efter att det ändrats. För en stor organisation är faran diffus, eftersom cachar och kantlager ackumuleras över team och ingen enskild person kan lista vad som är cachat var eller när det rensas. Spänningen är verklig: aggressiv cachelagring och långa TTL:er köper latens och skyddar databasen, medan strikt färskhet kostar båda. Ta med en inventering av cachade och CDN-serverade data, markerad för vilka poster som bär en regelefterlevnads- eller säkerhetskonsekvens, plus belägg för att invalideringsvägen för var och en av dessa har övats i praktiken snarare än bara konfigurerats. I reglerade och offentliga miljöer är ett inaktuellt samtycke eller en inaktuell behörighet ett granskningsbart fel, så de posterna behöver en uttrycklig, testad invalideringsväg eller bör inte cachas alls.
Vilken är er strategi för bevarande, arkivering och dataplacering för varje auktoritativt lager, och kan ni bevisa den för en revisor? Data överlever kod och överlever ofta teamet som skrev den, så obegränsad tillväxt och vaga placeringsregler blir i det tysta problemet ingen äger tills en tabell är ohanterlig eller en post ligger i fel jurisdiktion. En stor organisation spänner över många lager och regioner, och de motstridiga hänsynen är kostnad (varm lagring är dyr, så arkivera och dela in i nivåer), prestanda (uppsvällda tabeller bromsar allt) och rättslig plikt (lagstadgade golv för bevarande och tak för placering som kan stå i konflikt). Ta med, per auktoritativ datamängd, bevarandeperioden, var datan fysiskt bor, arkiverings- och raderingsmekanismen och namnet på den som är ansvarig. För företags- och särskilt myndighetssystem är bevarande och placering vanligen rättsliga mandat med revisions- och suveränitetskrav, så att kunna bevisa var varje post bor, hur länge den bevaras och när den förstörs är en licens att verka, inte en trevlighet.

Sektorsperspektiv

Startup. Kör en databas och stå emot zoot. Ett enda hanterat relationslager ger dig transaktioner, en sak att säkerhetskopiera och ett ställe att resonera om konsistens, vilket är exakt vad ett team på tre personer har råd att hålla i huvudet. Lägg till en cache, en läsreplik eller ett sökindex först när en specifik långsam fråga eller verklig läsvolym tvingar fram det, så att komplexitet anländer med ett betalande skäl. Håll migreringar versionerade från dag ett, för att eftermontera migreringsdisciplin på en levande produkt är långt svårare än att börja med den.

Småföretag. Du har ingen databasspecialist och ingen tid att driva flera motorer, så föredra ett hanterat lager och låt din plattformsleverantör hantera säkerhetskopior, patchning och replikering. Behandla lagerval som ett köpbeslut: välj den tråkiga, välstödda motor dina verktyg redan integrerar med snarare än den snabbaste på ett riktmärke. Sätt en enkel policy för bevarande och säkerhetskopiering du faktiskt kan verifiera, och cachelagra aldrig något knutet till pengar eller behörigheter utan ett tydligt sätt att rensa det, för ett inaktuellt pris eller en behörighet kostar dig en kund.

Storföretag. Kärnutmaningen är polyglot persistens över många team: ett relationellt register-system plus sök, cache, lager och kanske graf- eller tidsseriemotorer, var och en ägd av en tjänst snarare än delad. Standardisera operativa verktyg, säkerhetskopiering och övervakning över de lager ni behåller, håll adoption av nya motorer till en hög ribba och gör expandera-dra ihop-migreringar och uttrycklig cacheinvalidering till standardvalet. Hantera egendomen som en portfölj med tydligt dataägarskap, så att ingen motor överlever bortom arbetsbelastningen som motiverade den och inget team kopplas genom en delad databas.

Offentlig sektor. Dataplacering, lagstadgat bevarande och påvisbar integritet formar varje val. Provisionera varje lager i suveräna regioner, konfigurera CDN:er att bara cachelagra icke-personuppgifter och behåll en oföränderlig granskningshistorik för poster som måste vara rekonstruerbara för tillsynsmyndigheter. Migreringar föreskrivna av ny lagstiftning måste tillämpas bakåtkompatibelt genom pipelinen så att tjänsten förblir tillgänglig genom lagstiftningsmässiga deadlines, och register-systemet måste vara identifierbart så att ni kan bevisa vilket värde som är den rättsliga källan och bygga upp varje härledd kopia från det.

Exempel

Startup. En startup på frönivå kör allt på en enda hanterad PostgreSQL-instans och stretar emot lusten att lägga till en separat sökmotor, cache och lager innan den behöver dem. En databas betyder en sak att säkerhetskopiera, ett ställe att resonera om konsistens och transaktioner som bara fungerar, vilket spelar roll när hela teamet är tre ingenjörer. De lägger till en Redis-cache och en läsreplik först när en specifik långsam fråga och verklig läsvolym motiverar det, så att komplexitet anländer med ett betalande skäl snarare än före ett.

Storföretag. En detaljhandelsbank håller sin auktoritativa huvudbok i en starkt konsistent relationsdatabas: varje bokföring är en riktig ACID-transaktion, shardad efter kontointervall för skrivskala. Runt den ligger en polyglot egendom: ett sökindex för kunduppslag, en Redis-cache (skriv-genom, kort TTL) för kontosammanfattningar i mobilappen, ett kolumnorienterat lager för regulatorisk och analytisk rapportering och en grafdatabas för bedrägeridetektering i transaktionsnätverk. Schemaändringar i huvudboken använder expandera-dra ihop med dubbelskrivningar så att dygnet-runt-systemet aldrig tar driftstopp för en migrering.

Offentlig sektor. Ett nationellt fordonsregister lagrar auktoritativa poster i ett relationellt register-system med lagstadgat bevarande och full granskningshistorik. Publika “kontrollera ett fordon”-uppslag serveras från en läsreplik och en kantcache med kort TTL, eftersom lite inaktuella publika data är acceptabla och läsvolymen överstiger skrivningar med råge. Dataplaceringslagen kräver att alla poster stannar i landet, så varje lager provisioneras i suveräna regioner och CDN:et konfigureras att bara cachelagra icke-personuppgifter. Migreringar för att lägga till nya fält föreskrivna av transportpolitiken tillämpas bakåtkompatibelt genom pipelinen så att tjänsten förblir tillgänglig under lagstiftningsmässiga deadlines.

Affärsnytta: motiv, ROI och TCO

Dataarkitekturbeslut hör till programvarans längsta och största kostnadssvansar, eftersom data och deras schema är det svåraste att ändra när system och integrationer väl beror på dem. Införandekostnaden för god praxis (medvetet lagerval, disciplinerade migreringar, designad cachelagring och lämplig sharding) är mest senior ingenjörstid och en del extra operativa verktyg. Kostnaden för att inte införa den syns som en enda överbelastad databas som kvävar hela verksamheten, nöd-omplattformning när fel lager upptäcks för sent, utdragna avbrott från en havererad migrering och, mest skadligt, dataförstörelse eller ett regelefterlevnadsintrång från en felinvaliderad cache eller en förlorad transaktion.

Driv ärendet inför ledningen i termer av skalbarhetsutrymme, incidentrisk och regulatorisk exponering. Rätt lagringsval är det som låter verksamheten växa läs- och skrivvolym utan en omskrivning. Disciplinerade migreringar är det som låter schemat hålla jämna steg med nya mandat utan driftstopp. Korrekt cachelagring är det som levererar snabba användarupplevelser utan tysta inaktualitetsbuggar. Kvantifiera TCO över systemets liv. En enda väl vald dataarkitektur undviker den återkommande kostnaden för att arbeta runt en dålig, och en förhindrad dataförstörande incident överstiger vanligen hela kostnaden för att göra det väl. I reglerade sektorer är förmågan att bevisa dataintegritet och placering inte en kostnadspost utan en licens att verka.

Antimönster och fallgropar

Delad databas över tjänster. Flera tjänster som läser och skriver ett schema, vilket kopplar team och gör varje ändring till en samordningskris.
En databas för allt. Att tvinga analys, köer, sökning och transaktioner på en enda relationsmotor tills den kollapsar.
Storskaliga migreringar. Enstaka brytande schemaändringar som kräver driftstopp och inte kan rullas tillbaka säkert.
Cachelagring utan invalideringsstrategi. Inaktuella data serverade på obestämd tid, eller korrekthetsbuggar eftersom ingen äger när cachen rensas.
Förhastad sharding. Att distribuera data innan belastningen kräver det och permanent förlora joins och transaktioner utan nytta.
Att ignorera replikeringsfördröjning. Att läsa sin egen skrivning från en eftersläpande replik och få inaktuella data, vilket bryter användarens förväntningar.
Obegränsad datatillväxt. Ingen arkiverings- eller bevarandestrategi, så tabeller växer tills prestanda och kostnad blir ohållbara.
Att lagra härledda data som sanning. Att behandla en cache, ett index eller en projektion som register-systemet och sedan upptäcka att det drivit.

Mognadsmodell

Nivå 1: Initiera. En databas används för varje syfte. Schemaändringar är manuella och ad hoc, utan migreringsdisciplin. Cachelagring är tillfällig och invalidering är en eftertanke. Prestandaproblem löses reaktivt genom att köpa en större maskin, och ingen kan pålitligt namnge register-systemet för en given datamängd.
Nivå 2: Utveckla. Vissa lagringsval är medvetna och en cache eller ett lager har dykt upp, men praxis varierar med team. Migreringar är versionerade men kräver ibland driftstopp, och expandera-dra ihop används av den som råkar kunna det. Flera tjänster delar fortfarande en databas, och cachelagringsstrategier skiljer sig från ett team till nästa.
Nivå 3: Standardisera. Polyglot persistens matchas mot arbetsbelastningar, varje lager ägt av en tjänst och aldrig delat. Automatiserade, bakåtkompatibla expandera-dra ihop-migreringar utan driftstopp är den dokumenterade, upprätthållna standarden i hela organisationen. Cachelagringsstrategier, TTL:er och invalideringsvägar är uttryckliga designartefakter, och det enda register-systemet för varje datamängd är dokumenterat, med härledda kopior som kan byggas upp igen från det.
Nivå 4: Hantera. Dataegendomen mäts och styrs mot utgångslägen. Du följer migreringsvaraktighet och återrullningsfrekvens, replikeringsfördröjning mot krav på läs-dina-skrivningar, cacheträffgrad och inaktualitetsincidenter, driftskostnad per lager och frågelatens vid målpercentiler, och du agerar på talen. Bevarande och placering revideras mot lagstadgade krav, korrekthet hos härledda data verifieras kontinuerligt och varje motor måste motivera sin kostnad mot den arbetsbelastning den betjänar.
Nivå 5: Orkestrera. Dataarkitekturen förbättras kontinuerligt och är integrerad med kapacitets-, kostnads- och riskplanering i hela organisationen. Sharding-, cachelagrings- och konsistensval omfördelas per arbetsbelastning när åtkomstmönster och kostnad förskjuts, och lager som inte längre förtjänar sin plats avvecklas genom planerade migreringar. Schemautveckling, arkivering och placering är fullt automatiserade och adaptiva, så att egendomen omformar sig efter nya mandat och belastning utan nöd-omplattformning.

Idéer för diskussion

Vilka av era nuvarande lager gör ett jobb de inte designades för, och vad skulle den rätta motorn vara?
Kan ni utföra en schemaändring på er största tabell i dag med noll driftstopp? Om inte, varför inte?
Var cachelagrar ert system data vars inaktualitet kunde orsaka ett regelefterlevnads- eller korrekthetsfel?
Vilka tjänster delar en databas, och vad skulle det krävas för att ge var och en sin egen?
Var är en enda skrivbar databas ert skalningstak, och är läsreplikering eller sharding rätt nästa steg?
Vilken är er strategi för bevarande och arkivering, och vem är ansvarig för den?

Viktigaste punkter

Data överlever kod. Lagrings- och modelleringsbeslut begränsar verksamheten under systemets hela liv.
Matcha varje arbetsbelastning mot det lagringsparadigm som passar dess åtkomstmönster. Förvänta polyglot persistens i skala.
Ge varje tjänst ägarskap över sina data. Koppla aldrig team genom en delad databas.
Behandla schemautveckling som kontinuerlig och använd bakåtkompatibla expandera-dra ihop-migreringar utan driftstopp.
Cachelagring är ett korrekthetsproblem: designa TTL:er, invalidering och stampedeskydd medvetet, och cachelagra aldrig regelefterlevnadskritiska data utan en testad invalideringsväg.
Köp bara den konsistens och de transaktionsgarantier varje arbetsbelastning behöver. Sharding och replikering byter transaktioner över partitioner mot skala.

Referenser och vidare läsning

Martin Kleppmann, Designing Data-Intensive Applications
Pramod Sadalage and Martin Fowler, NoSQL Distilled
Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design
C. J. Date, An Introduction to Database Systems
Joe Celko, SQL for Smarties
Vlad Mihalcea, High-Performance Java Persistence (transactions, isolation, concurrency)
Eric Evans, Domain-Driven Design (bounded contexts and data ownership)
Werner Vogels, “Eventually Consistent”