In-memory i SQL Server 2014 er hurtigt - men har faldgruber

CAMPUS DAYS: Den næste udgave af Microsofts database får mulighed for at køre med alle data i hukommelsen, men der er nogle vigtige forskelle, som udviklere skal passe på.

KØBENHAVN. Hukommelsen i servere er efterhånden så stor i forhold til mængden af data i mange databaser, at det er blevet en reel mulighed helt at undlade at skulle læse og skrive data til disken og i stedet køre alt i hukommelsen. Derfor er flere af de store softwareleverandører i færd med at finpudse deres såkaldte in-memory-teknologier.

Det gælder også Microsoft, som i den kommende udgave af selskabets database, SQL Server 2014, vil tilbyde et in-memory OLTP-modul, som lige nu er frigivet i en tidlig testversion.

Fordelen ved in-memory-databaser er, at RAM kan være i omegnen af en faktor 1.000 hurtigere end en konventionel harddisk. Til gengæld kræver RAM-moduler en konstant elektrisk spænding for at kunne holde på data.

»Det optimerer OLTP-workloadet ved at tilgå databasen i hukommelsen i stedet for på disken, og det giver en betydelig forbedring i tidsforbruget,« fortalte chefkonsulent David Peter Hansen fra Hitachi Consulting på Microsofts Campus Days-konference, som afholdes i København i denne uge.

I praksis får man ikke en tusind gange hurtigere database, men til mange opgaver vil man se en betragtelig reduktion i både den tid, det tager at udføre en transaktion eller handling på databasen, og i kompleksiteten.

SQL Server 2014 bliver den første udgave af Microsofts database, som tilbyder muligheden for in-memory, og det betyder også, at der er en række begrænsninger, som David Peter Hansen håber, Microsoft vil ændre i den kommende tid.

»Foreign keys er ikke understøttet, og det er noget, der virkelig bekymrer mig. Hvis du er databaseadministrator, så er du nødt til at kigge dine udviklere over skulderen for at sikre, at de holder konsistensen,« sagde David Peter Hansen.

En diskbaseret database i SQL Server 2014 har ingen problemer med de såkaldte foreign keys, og derfor skal man være påpasselig, hvis man vil flytte en applikation over på in memory, som ikke understøtter dem.

En anden begrænsning, man skal være opmærksom på som databaseadministrator, er, at man ikke kan bruge kommandoen 'alter table' for at ændre i en tabel, man har oprettet. Når man kører in-memory, er man nødt til at slette tabellen og oprette den igen med de nye parametre, så man skal altså flytte dataene over i en midlertidig tabel og importere dem i den nye manuelt.

»Som databaseadministrator er det ikke noget, jeg vil være sårlig glad for, så jeg håber virkelig, at det er noget, de vil ændre,« sagde David Peter Hansen.

Mens diskplads sjældent er en begrænsning for en typisk database, så er hukommelse noget mere begrænset på de fleste databaseservere. Derfor er der også begrænsninger på, hvor meget data man kan lagre i en in-memory-tabel.

Hver række kan således højst indeholde 8.060 bytes i alt, hvilket kan give problemer for eksisterende databaser, som skal konverteres.

»Du er nødt til at være lidt forsigtig, hvis du migrerer en applikation. Maksimumtørrelsen på 8.060 bytes er noget, du bør have for øje. En bedre løsning kan være at tage data og opdele og lægge noget af det i en diskbaseret tabel,« sagde David Peter Hansen.

SQL Server 2014 understøtter nemlig muligheden for at kombinere tabeller, som ligger i hukommelsen med tabeller, der ligger på diske. Det kan eksempelvis bruges, hvis man har data som fotos eller andet, som fylder meget, men ikke nødvendigvis skal hentes lige så hyppigt som andre data.

Man kommer heller ikke helt uden om diske. Da alle data forsvinder, hvis størmmen forsvinder eller serveren går ned, så er man nødt til at gemme sikkerhedskopier i form af check points på diskene. Her skal man ifølge David Peter Hansen være opmærksom på, hvordan man skruer sit storagesystem sammen.

»Ved en recovery, så skal samtlige data læses fra diskene. Det kan blive en flaskehals, som man bør være opmærksom på. Det vigtigste her vil være sekventielle I/O, så der er ikke brug for SSD-drev, for de er bedst til random I/O. Du bør overveje, hvor længe din SQL Server må være nede, når du sammensætter dit SAN,« sagde David Peter Hansen.

Selvom der er en masse faldgruber, man skal være opmærksom på, hvis man vil bruge in-memory i SQL Server 2014, så er der især ét punkt, som David Peter Hansen er særdeles tilfreds med:

»Du skal ikke lære et helt nyt sprog. Det er bare T-SQL, som mange af os i forvejen drømmer i. Det er jeg rigtig glad for. Du skal ikke lære en ny grænseflade,« sagde han.

Kommentarer (6)

Claus Pedersen

Vil en Sql server ikke forsøge at cache så meget data i ram alligevel? Så for langt de fleste queries vil det ikke betyde nogen forskel?
Eller ligger forskellen i skrivninger, så der ikke persisteres data med mindre der laves check-points?

Nils Bøjden

Oracle db har i en 12 - 13 års tid haft mulighed for at sikre at data forblev i hukommelsen.

Så er forskellen at man med Sql server kan smide hele basen i RAM med en enkelt parameter / option / kommando?

Pelle Söderling

Caching af data i RAM har været standard i mange år.

Det der er tale om her er noget anderledes - jeg formoder det her er næste skridt i deres xVelocity (tidl. VertiPaq) tiltag, som er en hel ny måde at processere og lagre dataene på optimeret til in-memory brug. Der er med andre ord mere til det end blot at cache indexes og rows i RAM.

En del af xVelocity er blandt andet muligheden for columnar storage der kan have store performance-mæssige fordele i visse scenarier - specielt interessant er det for BI løsninger. Problemet med columnar storage er dog at Foreign Key relationer giver problemer - derfor peger indholdet i artiklen meget i denne retning.

Jeg kender ikke nok til de nye tiltag i 2014, men jeg er ret sikker på det er det her det handler om og ikke "dum" caching af data i RAM som ganske rigtigt er standard i alle RBMS'er inkl. SQL Server.

Der er tale om nye tiltag som især retter sig imod Datawarehousing/BI løsninger, men som også kan være interessante i andre sammenhænge.

Jeg må dog indrømme at der er visse af begrænsningerne jeg også meget gerne så vi kom af med, men det er meget spændende hvad Microsoft har gang i her med SQL Server for det afviger fra hvordan konkurrenterne vælger at håndtere columnar storage og inmemory processering og tillader i højere grad at blande den nye og den gamle verden.

Jesper Stein Sandal

Den væsentlige forskel ligger, så vidt jeg har forstået, i, at du fortæller SQL Server, at tabellerne ligger i RAM. Dermed skal den ikke bekymre sig om, hvorvidt der er en chance for, at de kan hentes fra en RAM-buffer i stedet for disk.

Det betyder for eksempel, at der ikke findes locks, når man vælger en in-memory-tabel (det kan også give nogle udfordringer).

Det giver også mulighed for at bruge native code i stedet for T SQL på de ting, der ligger i RAM.

Der er desværre ikke kommet links til præsentationerne endnu, og mit SQL-niveau er meget på 101, så jeg er blot mellemmand, som sorterer informationen her. :)

Claus Jacobsen

De har fået opdateret Wiki en smule http://en.wikipedia.org/wiki/In-memory_database.
I bund og grund er det en erstatning for at skulle lægge dem på alm Diske eller i et SSD-array eller i en server med accelleratorkort fra fusion-IO/LSI. Noget af det rigtigt smarte er at man ikke behøver have hele databasen liggende på EN server, men der kan laves et cluster med en memory-pool som passer til størrelsen af databasen. - udstyrer man HW med infiniband interconnects har man mulighed for at lave RDMA (remote direct memory access) så en server kan trække på data liggende i rammen på en anden server uden alt for stor forsinkelse. (der mangler stadig noget, men en af artiklerne fra i går nemlig den omkring intels silicon photonics har så rigtig stor betydning her.)

David Peter Hansen

@Claus Pedersen: SQL Server læser rigtig nok data ind i buffer pool'en, men Query Optimizeren kan ikke vide om data ligger i memory eller på disk, og beregner derfra ud fra physical reads og ikke kun logical reads. Med In-Memory OLTP, ved optimizeren at memory-optimized tabeller altid ligger memory - og det gør en stor forskel.

Ved brug af SCHEMA_AND_DATA duration, bliver nyt/opdateret/slettet data tilføjet til transaktionsloggen, ligesom ved disk-baseret tabeller. Herefter bliver data tilføjet til checkpoint filer (og ikke data filer, som ved disk-baseret tabeller). Ved brug af SCHEMA_ONLY duration, skrives der ikke til transaktionsloggen. Dog er fodtrykket på transaktionsloggen mindre, da indexes kun lever i memory.

@Nils Bøjden: Oracle har, så vidt jeg har forstået (jeg er ikke Oracle-mand, så ret mig endelig hvis jeg tager fejl), TimesTen. Dette er en ren in-memory database, og et seperat produkt fra deres RDBMS.

SQL Server In-Memory OLTP database komponent er en integreret del af RDBMS. Dvs. man kan have dele af databasen som memory-optimized tabeller og andre dele som disk-baseret tabeller. Og man kan via interop bruge T-SQL til at læse fra begge typer i samme query.

Egentligt er det jo også ligegyldigt om Oracle har haft det i flere år (uden at jeg vil gå ind i en vim vs emacs lignende diskussion her), da det er interessant for dem der kommer til at bruge SQL Server 2014.

@Pelle Söderling: In-Memory OLTP er en ny database komponent i SQL Server 2014. Det er forskelligt fra buffer pool'en (caching af data) og forskelligt fra xVelocity. xVelocity er tiltænkt Data Warehouse lignende queries, mens memory-optimized tables er tiltrængt OLTP workloads.

Kan anbefale Kalen Delaney's whitepaper, hvis du vil vide mere:

http://sqlblog.com/blogs/kalen_delaney/archive/2013/06/05/hekaton-whitep...

@Jesper Stein Sandal: Der kommer en video op af præsentationen snart™. Slides og demo kan findes her:

http://davidpeterhansen.com/first-look-at-the-in-memory-oltp-database-en...

@Claus Jacobsen: Jeg mener ikke det er en erstatning, men snarre et suplement. Man kan med SQL Server 2014 In-Memory OLTP vælge at lægge sine varme data i memory, mens de kolde kan ligge på disk (og evt. lunkne(?) data på SSD).

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Managing Benefits TM Foundation - Gevinstrealisering

Hvornår: 2015-09-14 Hvor: Storkøbenhavn Pris: kr. 13500.00

CNS-207 Implementing Citrix NetScaler 10.5 for App and Desktop Solutions

Hvornår: 2015-09-07 Hvor: Østjylland Pris: kr. 25000.00

Business Controlling

Hvornår: 2015-11-25 Hvor: Storkøbenhavn Pris: kr. 9990.00

Excel Diagrammer kursus - II

Hvornår: 2015-10-21 Hvor: Storkøbenhavn Pris: kr. 3500.00

Løber dine kollegaer med dig, for dig eller fra dig?

Hvornår: Hvor: Storkøbenhavn Pris: kr. Efter aftale