Någon som fattar "minnesdatabaser"?

[sodjan]

Jag fattar i alla fall inte riktigt... Vad är det som de har tagit
bort när man talar om "minnesdatabaser"? De måste väl i alla
fall skriva uppdateringar till ett permanent lagringsmedium !?
Att läsningar kan ske från minnet handlar ju enbart om cache,
och det fungerar ju utmärkt med normala databaser.

Om man läser http://en.wikipedia.org/wiki/In-memory_database så
verkar det som att, visst, går systemet ner så förlorar man uppdateringar!
*Om* man inte lägger till en transaktionsfil, men då är det ju samma sak
som vilken traditionell databas som helst...

Vore intressant att höra om någon har tittat närmare på dessa typer
av databaser, men för mig verkar det vara en rejäl hype kring detta...

[Micke_s]

Hastighet är väl varför man väljer detta sätt. men det gäller att inte strömmen försvinner eller datorn kraschar.


Har för mig att jag har sett pci-e kort med sdram+batteribackup också

[SeniorLemuren]

Har ingen erfarenhet av detta, men läser man :

Another variation involves large amounts of nonvolatile memory in the server, for example, flash memory chips as addressable memory rather than structured as disk arrays. A database in this form of memory combines very fast access speed with persistence over reboots and power losses.[9]

Så kan jag se fördelar med databasen i minnet.

Fast det är klart att yttrycket "minnesdatabaser" är missvisande. All data lagras ju i någon typ av minne. Hade man benämnt det som arbetsminnedatabaslagring hade det en annan sak.

[sodjan]

Jo, självklart förstår jag skillnaden i sig mellan olika minnestyper...

Men vad är skillnaden mellan de olika databas produkterna?
Vad är den praktiska skillnaden mellan en traditionell databas som
kör mot cache'at data i minnet och en "minnesdatabas"?

> Hastighet är väl varför man väljer detta sätt.

Hastigheten är anledningen till att man vill ha cache i *alla* databaser.
D.v.s. att det inte borde vara någon avgörande skillnad i detta fall.

Om man t.ex. tittar på en produkt med en väldigt hype just nu, SAP HANA,
så uppnår den ACID genom att ha traditionella transaktionsloggar och
uppdaterad data skrivs regelbundet till vanlig disk. Alltså ingen som helst
skillnad mot hur traditionella rellationsdatabaser har gjort i 20 år.

[sodjan]

För att ta ett exempel...
Vi har just nu i en produktionsdatabas 99.7% "hit rate" i cache
vid sökningar efter databas sidor. Är det då en "minnesdatabas"?

Dessa värden är för ca 330 dagars uptime:

Skärmklipp.JPG

"in AS": Hittades i den del av cache som processen har allokerad.
"in GB": Hittades i "Global Buffers", d.v.s cachen.
"not found": Databassidan fick läsas in från disk.

Av någon anledning så la "avg" värderna av när vi passerade
10.000.000.000 lästa pages...

[SeniorLemuren]

Kan det ha något att göra med att cache-proceduren tar märkbara resurser från operativet, så det får mer att göra, än om man har hela databasen liggande i minnet och inte behöver någon cache?

[sodjan]

Jo, det finns så klart sådana effekter. Men sälj pitchen (om man läser
IT tidningar och liknande) är att man "gör allt i minnet" jämfört med
"gör allt mot disk".

Om man läser lite kring SAP HANA, så har den ju en del andra fuktioner som
att t.ex konsolidera data från olika källor för analys och rapporter. D.v.s det
som för 15 år sedan var dagens stora hype och kallades "Data Warehouse"...

Jag kan inte se annat än att deta hela är lite överdrivet...

[netrunner]

När allt låg på disk för att det var för dyrt att skaffa 200gb ram så var det inte så viktigt att optimera databasen ... allt tog ju ganska lång tid i alla fall. Så databaserna blev stor och långsamma.

Nu är det inte så dyrt med 200gb ram så det är rimligt att optimera sin databas till att alltid vara i ram.

Sen är ju frågan om man inte kan ta ner databasen på disk när systemet har lång belastning.

[swesysmgr]

Jo, det finns så klart sådana effekter. Men sälj pitchen (om man läser
IT tidningar och liknande) är att man "gör allt i minnet" jämfört med
"gör allt mot disk".

Om man läser lite kring SAP HANA, så har den ju en del andra fuktioner som
att t.ex konsolidera data från olika källor för analys och rapporter. D.v.s det
som för 15 år sedan var dagens stora hype och kallades "Data Warehouse"...

Jag kan inte se annat än att deta hela är lite överdrivet...

I en vanlig relationsdatabas kan du optimera söktiden t.ex. genom att låta databasen placera datat på disk i ordning efter index på en av kolumnerna, det brukade ge en del i sökprestanda på stora tabeller. Med en minnesdatabas spelar det ingen roll längre, det går lika fort att hämta en post vart som helst i minnet.

Jag tror att det Hana och andra minnesdatabaser gör är att de utnyttjar detta för att göra alla sök/uppdatera/infoga med helt andra algoritmer än traditionella databasers binära träd och annat som är anpassat för att jobba mot sekventiella data på disk.

Med Hana kan SAP dumpa all intern kod som konsumerar CPU för att minimera de disk-relaterade operationerna och få hela rasket att gå mycket snabbare.

Om de "bara" (vilket är en bedrift i sig) fått det att fungera ihop med minneslagring men ändå garantera backuper och transaktioner eller om det finns något patent i Plattners namn som gör något nytt och magiskt det vet jag inte

[sodjan]

> Sen är ju frågan om man inte kan ta ner databasen på disk när systemet har lång belastning.

Men poängen är ju att det mesta normalt redan finns på disk.
Så man behöver inte "ta ner [hela] databasen" till disk. Det
är OK att skriva ner uppdateringar löpande som man gör idag.

> I en vanlig relationsdatabas kan du optimera söktiden t.ex. genom att låta databasen placera
> datat på disk i ordning efter index på en av kolumnerna, det brukade ge en del i sökprestanda
> på stora tabeller.

Alltså fortfarande med index och data lagrade separat? Ja, det kan ge en del vinst vid
"range retrieval", men vid unika sökningar spelar det mindre roll.

Det som ger vinst är "klustrade" index där datat ligger tillsammans med index noderna.
Det kan helt spara in I/O för att hämta datat.

Sen kan man ha "hashed" index. Där alltså datat lagras över ett allokerat utrymme
efter en hash på en kollumn. Det ger i bästa fall en enda I/O för att läsa en post.
Medför dock en del administration om tabellen växer.

> Med en minnesdatabas spelar det ingen roll längre, det går lika fort att hämta en post vart som helst i minnet.

Ja, accessen till själva data recorden är densamma, men det är det i stort sätt på en vanlig disk också.
D.v.s att det går ungefär lika snabbt (eller långsamt) att hämta en post var som helst på disken.

Nu så är det ju inte rellevant om datat i alla fall ligger i cachen.

Men även om datat ligger i minnet så behöver du fortfarande ta reda på *var*
i minnet det ligger. D.v.s en vanlig index uppslagning. Även i minnet så tar det tid
att göra en table scan över miljoner poster.

> Jag tror att det Hana...

När jag kollade lite info kring Hana så såg det ut att mest vara olika lager ovanpå
själva lagringen för analys och rapport körningar. Alltså utöver själva lagringen.

> ...sekventiella data på disk.

Disk har väl alltid betraktats som "Random Access"? Till skillnad från tape där det
verkligen är sekvensiellt.

> Med Hana kan SAP dumpa all intern kod som konsumerar CPU för att minimera de
> disk-relaterade operationerna och få hela rasket att gå mycket snabbare.

Precis som vilken databas som helst som får en "hit" i cachen. Då blir det inga
disk I/O alls, så klart.

> Om de "bara" (vilket är en bedrift i sig) fått det att fungera ihop med minneslagring men
> ändå garantera backuper och transaktioner...

Någon sida jag läste sa att Hana uppnår ACID precis som vilken annan databas som helst.
Alltså genom transaktionsloggar och "redo" loggar till disk (eller något annat permanent storage).
D.v.s att så snart man även uppdaterar data så är det inte 100% "memory database" längre.

[Findecanor]

De projekt jag varit inblandade i där vi använt minnesdatabaser har varit fall då, antingen:
* Datan har haft kort livslängd och inte varit kritisk. T.ex. inloggningssessioner.
* Datan i minnesdatabasen är en kopia av data från en disk-databas men är anpassad till snabba sökningar som skulle vara långsamma om man gjorde dem i disk-databasen. Detta av data som förändras sällan och där förändringar inte behöver få genomslag oftare än man läser in hela databasen igen från disk.

Sen så är det inte den direkta läs-tiden som är mest signifikant, utan tiden det tar att söka och hitta den data som man ska läsa. Det kan ibland ta lång tid även att göra operationer i minnet. Även en liten skillnad i medel-söktid kan spela roll om det sker hundratals eller tusentals sökningar per sekund.

[sodjan]

Ja, inte vanliga OLTP applikationer.

Och visst, det går säkert att införa en del optimeringar där man
t.ex kan spara lite på cache uppslagningen o.s.v.

Och om man inte har krav på sig att även uppdatera på ett
säkert sätt, så blir det ju ett helt annan läge.

Det jag dock fortfarande vänder mig mot är just begreppet "diskdatabaser".
Även "minnesdatabasen" läser ju in sitt data någonstans ifrån, vanligtsvis
från just disk. Och med en "diskdatabas" som kör helt från cache, så är
det ju inga disk accesser alls, så länge man inte uppdaterar...

Dessutom, om man inte tänker uppdatera så kan man "gödsla" med
index utan att det drabbar prestandan negativt.

[thebolt]

En skillnad, som i en del tillämpningar kan göra mycket för prestanda, är att "traditionell" databas-cache så är det enbart en läscache, men alla skrivningar måste verifierat skrivits till disk (minst transaktonsloggen). I en minnesdatabas har du oftast inte det kravet utan så fort ram är uppdaterad är man klar.
Nackdelen är ju att man antingen får acceptera viss dataförlust om en nod går ner, eller ha replikering mellan flera noder.

-M

[sodjan]

Precis. Men då uppfyller man inte ACID kraven.
Helt OK så klart, om man accepterar det.

Sen så är skrivningen av transaktionsloggen normalt en väldigt
snabb operation, den är ju inte "random" utan sker mer eller
mindre "streamat" direkt efter senaste skrivningen.

Aja, intressant diskussion. Har jobbet med databaser 25 år så
man undrar ju vad som är grejen nu.

[thebolt]

Beror väll lite på hur hårt man tolkar framför allt D
. Med replikering kan du ha durability över att en instans går ner. Å andra sidan finns det ju fel som gör att man tappar D även i en on-disc databas.

-M