Databas skalbarhet

Se även: Skalbarhet

Databasskalbarhet är förmågan hos en databas att hantera ändrade krav genom att lägga till/ta bort resurser. Databaser använder en mängd tekniker för att hantera det.

Historia

Den initiala historien om databasskalbarhet var att tillhandahålla service på allt mindre datorer. De första databashanteringssystemen som IMS kördes på stordatorer . Den andra generationen, inklusive Ingres , Informix , Sybase , RDB och Oracle , växte fram på minidatorer . Den tredje generationen, inklusive dBase och Oracle (igen), kördes på persondatorer.

Under samma period vändes uppmärksamheten mot att hantera mer data och mer krävande arbetsbelastningar. En viktig mjukvaruinnovation i slutet av 1980-talet var att minska granulariteten för uppdateringslåsning från tabeller och diskblock till enskilda rader. Detta eliminerade en kritisk skalbarhetsflaskhals, eftersom grövre låsningar kunde fördröja åtkomsten till rader även om de inte var direkt involverade i en transaktion. Tidigare system var helt okänsliga för ökade resurser.

När mjukvarubegränsningarna väl hade åtgärdats vändes uppmärksamheten mot hårdvaran. Innovation förekom på många områden. Den första var att stödja multiprocessordatorer . Detta innebar att flera processorer kunde hantera databasförfrågningar samtidigt, utan att blockera varandra. Detta utvecklades till stöd för flerkärniga processorer .

En mycket mer betydande förändring innebar att tillåta distribuerade transaktioner att påverka data som lagras på separata datorer, genom att använda tvåfasprotokollet för bekräftelse, vilket etablerar arkitekturen delad ingenting .

Ännu senare introducerade Oracle arkitekturen för delat allt , som gav full funktionalitet på kluster med flera servrar.

En annan innovation var att lagra kopior av tabeller på flera datorer ( databasreplikering ), vilket både förbättrade tillgängligheten (bearbetningen kunde fortsätta på en kopia även om huvudsystemet inte var tillgängligt) och skalbarhet, särskilt för fråga/analys, genom att förfrågningar kunde dirigeras till kopiera om den primära nådde sin kapacitet.

I början av det tjugoförsta århundradet vann NoSQL- system fördel framför relationsdatabaser för vissa arbetsbelastningar. Motiven var ännu större skalbarhet och stöd för dokument och andra "icke-relationella" datatyper. Ofta offrades de strikta ACID-konsistensprotokollen som garanterade perfekt konsistens hela tiden till förmån för eventuell konsistens som säkerställde att alla noder så småningom skulle returnera de senaste uppgifterna. Vissa tillät till och med att transaktioner ibland gick förlorade, så länge som systemet kunde hantera tillräckligt många förfrågningar. Det mest framträdande tidiga systemet var Googles BigTable / MapReduce , utvecklat 2004. Det uppnådde nästan linjär skalbarhet över flera serverfarmar , till priset av funktioner som transaktioner med flera rader och sammanfogningar.

2007 utvecklades det första NewSQL- systemet, H-Store . NewSQL-system försöker kombinera NoSQL-skalbarhet med ACID-transaktioner och SQL-gränssnitt.

Mått

Databasskalbarhet har tre grundläggande dimensioner: mängd data, volym förfrågningar och storlek på förfrågningar . Förfrågningar finns i många storlekar: transaktioner påverkar i allmänhet små mängder data, men kan närma sig tusentals per sekund; analytiska frågor är i allmänhet färre, men kan komma åt mer data. Ett relaterat koncept är elasticitet , förmågan hos ett system att på ett transparent sätt lägga till och subtrahera kapacitet för att möta förändrade arbetsbelastningar.

Vertikal

Vertikal databasskalning innebär att databassystemet fullt ut kan utnyttja maximalt konfigurerade system, inklusive typiskt multiprocessorer med stora minnen och stor lagringskapacitet. Sådana system är relativt enkla att administrera, men kan erbjuda minskad tillgänglighet. Men varje enskild dator har en maximal konfiguration. Om arbetsbelastningen expanderar över den gränsen, är valen antingen att migrera till ett annat, ännu större system, eller att bygga om systemet för att uppnå horisontell skalbarhet.

Horisontell

Horisontell databasskalning innebär att man lägger till fler servrar för att arbeta på en enda arbetsbelastning. De flesta horisontellt skalbara system kommer med funktionalitetskompromisser. Om en applikation kräver mer funktionalitet kan migrering till ett vertikalt skalat system vara att föredra.

Tekniker

Hårdvara

Databaser körs på individuell hårdvara som sträcker sig i kapacitet från smartklockor till superdatorer till flera transparent omkonfigurerbara serverfarmar. Databaser skalas också vertikalt för att köras på 64-bitars mikroprocessorer , flerkärniga processorer och stora SMP-multiprocessorer , med flertrådiga implementeringar.

Påstående

Att fullt ut utnyttja en hårdvarukonfiguration kräver en mängd olika låstekniker, allt från att låsa en hel databas till hela tabeller till diskblock till enskilda tabellrader. Lämplig låsgranularitet beror på arbetsbelastningen. Ju mindre objekt som är låst, desto mindre är chansen att databasförfrågningar blockerar varandra, medan hårdvaran är inaktiv. Vanligtvis är radlås nödvändiga för att stödja tillämpningar för transaktionsbearbetning av stora volymer till kostnaden av bearbetningskostnader för att hantera det större antalet lås.

Vidare säkerställer vissa system att en fråga ser en tidskonsekvent vy av databasen genom att låsa data som en fråga undersöker för att förhindra att en uppdatering ändrar den, vilket stoppar arbetet. Alternativt använder vissa databaser läskonsistens i flera versioner för att undvika (blockera) läslås samtidigt som de ger konsekventa frågeresultat.

En annan potentiell flaskhals kan uppstå i vissa system när många förfrågningar försöker få åtkomst till samma data samtidigt. Till exempel, i OLTP-system kan många transaktioner försöka infoga data i samma tabell samtidigt. I ett delat ingenting-system, vid varje givet ögonblick, bearbetas alla sådana inlägg av den enda servern som hanterar den partitionen ( shard ) av tabellen, vilket möjligen överväldigar den, medan resten av systemet har lite att göra. Många sådana tabeller använder ett sekvensnummer som primärnyckel som ökar för varje ny infogat rad. Indexet för den nyckeln kan också uppleva konflikter (överhettning) när det bearbetar dessa insatser. En lösning på detta är att vända om siffrorna i primärnyckeln . Detta sprider inläggen i både tabellen och nyckeln över flera delar av databasen.

Partitionering

En grundläggande teknik är att dela upp stora tabeller i flera partitioner baserat på värdeintervall i ett nyckelfält. Till exempel kan uppgifterna för varje år lagras på en separat diskenhet eller på en separat dator. Partitionering tar bort gränser för storleken på ett enskilt bord.

Replikering

Replikerade databaser upprätthåller kopior av tabeller eller databaser på flera datorer. Denna skalningsteknik är särskilt bekväm för sällan eller aldrig uppdaterade data, såsom transaktionshistorik eller skattetabeller.

Klustrade datorer

En mängd olika metoder används för att skala bortom gränserna för en enda dator. HP Enterprises NonStop SQL använder den delade ingenting- arkitekturen där varken data eller minne delas över servergränser. En koordinator dirigerar databasförfrågningar till rätt server. Denna arkitektur ger nästan linjär skalbarhet.

Den brett stödda X/Open XA- standarden använder en global transaktionsövervakare för att koordinera distribuerade transaktioner mellan semi-autonoma XA-kompatibla transaktionsresurser.

Oracle RAC använder en annan modell för att uppnå skalbarhet, baserad på en "delad-allt"-arkitektur. Detta tillvägagångssätt inkluderar med delad disk som tillåter flera datorer att komma åt valfri disk i klustret. Nätverksansluten lagring (NAS) och Storage Area Networks (SAN) i kombination med lokala nätverk och Fibre Channel- teknik möjliggör sådana konfigurationer. Tillvägagångssättet inkluderar en "delad" logisk cache i vilken data som har cachelagrats i minnet på servern görs tillgänglig för andra servrar utan att de behöver läsa data från disken igen. Varje sida flyttas från server till server för att tillfredsställa förfrågningar. Uppdateringar sker i allmänhet mycket snabbt så att en "populär" sida kan uppdateras genom flera transaktioner med liten fördröjning. Detta tillvägagångssätt påstås stödja kluster som innehåller upp till 100 servrar.

Vissa forskare ifrågasätter de inneboende begränsningarna hos relationsdatabashanteringssystem . GigaSpaces , till exempel, hävdar att rymdbaserad arkitektur krävs för att uppnå prestanda och skalbarhet. Base One hävdar extrem skalbarhet inom traditionell relationsdatabasteknologi.

Se även

  1. ^   Bondi, André B. (2000). Egenskaper för skalbarhet och deras inverkan på prestanda . Proceedings från den andra internationella workshopen om programvara och prestanda – WOSP '00. sid. 195. doi : 10.1145/350391.350432 . ISBN 158113195X .
  2. ^ a b   Chopra, Rajiv (2010). Databashanteringssystem (DBMS) Ett praktiskt tillvägagångssätt . S. Chand Publishing. sid. 33. ISBN 9788121932455 .
  3. ^ a b "Radlås vs bordlås i Oracle" . www.dba-oracle.com . Hämtad 2019-04-11 .
  4. ^ "Fördelarna med en delad ingenting-arkitektur för verkligt icke-störande uppgraderingar" . solidfire.com. 2014-09-17. Arkiverad från originalet 2015-04-24 . Hämtad 2015-04-21 .
  5. ^ "Real Application Clusters Administration and Deployment Guide" . docs.oracle.com . Hämtad 2019-04-11 .
  6. ^ a b "En primer på databasreplikering" . www.brianstorti.com . Hämtad 2019-04-11 .
  7. ^ Martin Zapletal (2015-06-11). "Storvolymdataanalys på Typesafe Reactive Platform" . {{ citera journal }} : Citera journal kräver |journal= ( hjälp )
  8. ^ "Översikt över Cloud Bigtable | Cloud Bigtable-dokumentation" . Google Cloud . Hämtad 2019-04-11 .
  9. ^ Aslett, Matthew (2011). "Hur kommer de etablerade databaserna att svara på NoSQL och NewSQL?" (PDF) . 451 Group (publicerad 2011-04-04) . Hämtad 2012-07-06 .
  10. ^ a b c Branson, Tony (2016-12-06). "Två huvudsakliga tillvägagångssätt för databasskalbarhet" . Infosecurity Magazine . Hämtad 2019-04-11 .
  11. ^ "Clojure - Refs och transaktioner" . clojure.org . Hämtad 2019-04-12 .
  12. ^ "Introduktion till omvänd nyckelindex: Del I" . Richard Footes Oracle-blogg . 2008-01-14 . Hämtad 2019-04-13 .
  13. ^ "klustring" (PDF) . Oracle.com . Hämtad 2012-11-07 .
  14. ^ Base One (2007). "Databasskalbarhet - skingra myter om gränserna för databascentrerad arkitektur" . Hämtad 23 maj 2007 .

externa länkar


Hämtad från " https://en.wikipedia.org/w/index.php?title=Database_scalability&oldid=1101908816 "