Hvordan skal dette struktureres

Det mest indlysende er vel en tabel med 4 felter:

node
nummer
tid
værdi

(nummer er 1-4096)

arne v> Ja, den er jo så indlysende at jeg ikke engang har tænkt på den. Jeg er dog lidt bekymret for performance - i løbet af en uge vil der være ca. 68 millioner poster. Skulle det være noget problem?

Jeg kan ikke forestille mig nogen struktur som vil give bedre performance.

Det afgørende for performance er mere hvor længe du skal beholde data.

Husk lige, at hvis de 68 mil. rækker skal kunne tilgås struktureret, så skal du også have indexes der svarer til hvad du slår op på, eller får du massive låsninger pga. full-scan.
Det koster i HW at gøre dette performende, idet du skal have et disk system bag, der hver sekund kan indsætte 114 rækker - Prøv med 3 diske i RAID-5, og du vil se at det ikke kan klare opgaven.
Alt efter hvilke andre oplysninger du har brug for, for størrelsen af rækkerne vil jeg tro at du til denne opgave som minimum har brug for følgende specialister:
1. Infrastruktur specialist, til at optimere netværket
2. Disk specialist til at optimere dit SAN eller disksystem
3. Database specialist til at optimere dit layout på ovenstående, samt verificere databasen og dine queries.
4. Trouble-shooter når alt ovenstående går galt

Arne har selvfølgelig ret hvad angår performance, idet det bare vil forværre situationen at lave flere tabeller i det skitserede setup.

Jeg tror det skal være noget mere konkret, inden jeg vil give et eksakt bud på denne opgave, og hvis jeg skulle løse den, så ville jeg bruge meget lang tid på analysen

Hvis hver række kun er de ca. 60 bytes som oplæget går på, så kan man selvfølgelig "bare" lade DB serveren have nok processor kraft og memory, til at de ca. 4 GB der dannes pr. uge kan være i memory, men det kræver en 64bit maskine, idet SQL på 32 bit ikke kan anvende mere end 2GB på standard Windows server, men kan presses til 3GB på Advanced server - Men det er nok en dårlig ide.

Hov - du sagde op til en uge.

Med 100 bytes per record betyder det en tabel på knap 7 GB.

Og det burde ikke være noget problem.

larildsen>

Alle med high-performance database krav bruger vel RAID 0+1.

Hmm Arne 7 GB - Hvilke queries skal der så køres ?
Jeg tror at design af tabellen (og indexes) samt HW har meget at sige.
Nogle tror at en DB kører fint på 3 diske i raid-5 (datafiler og transactionlog på samme diske), og det kører fint for nogle, men det er IKKE hign performance.
Jeg tror stadig på, alt efter hvad dette skal anvendes til, at I/O layoutet er alpha & omega, idet et snit på 114 rækker per sekund, måske ville have peaks MEGET større, og tilsvarende i perioder have meget mindre inserts, men det ved jeg jo IKKE, da opgaven IKKE er konkret nok

Og 114 TPS lyder da slet ikke som noget problem i mine ører.

Jeg er ikke spor bekymret over INSERT hvis de kan fordeles jævnt.

Og applikationen bør kunne håndtere peaks.

Men du har ret, hvis der er nogen som vil sidder og lave mega
store queries samtidigt, så begynder det at blive slemt.

Jeg er IKKE så bekymret form 114TPS, som for hvordan dette ellers er organiseret, så længe vi har et IO system der virker.
Queries der ikke låser og IO systemer er det der rykker lige nu :-)
Design er altså efter min mening det vigtige

Arne - Jeg kender IKKE din dagligdag, men jeg er til stidighed plaget af, at mine ideer om, at ALLE databaser i hele verden kører Raid 1+0 (helst med en del diske til data filer) ikke er virkelighed, når jeg møder mine kunder :-(

Arne - Jeg mener 1+0 istedet for 0+1 - Det ligner selvfølgelig ordkløveri, men istedet for at spejle 2 stripe set, så vil jeg hellere stripe x-antal raid 1 set.
Tænk på at en disk falder ud i et setup med 2 spejlede raid-0 sets, dette betyder at hele den ene side af spejlet faldet ud :-(

Arne - hele denne diskussion er måske uinteressant for de fleste, men historien om disk layout er IKKE. Kan du IKKE fortælle lidt om hign performance disk layout til folket ?

Jeg er ikke sikker på at jeg er den rette til det.

Jeg er ikke ekspert i den slags.

Men med RAID 0+1 af hot swapable diske og data og log på hvert sit
RAID system, så kan man ikke gå helt galt i byen hverken med performance
eller sikkerhed.

Men om spørgeren har budget til sådan en løsning ved jeg ikke.

Omkring datastrukturen, så kan du (hvis du ikke har mange felter), lave et covering index - dvs. et indeks, der indeholder alle de felter, der bruges i forespørgslen. Det betyder, at SQL Server ikke skal ned i data, men kan nøjes med at bruge index til forespørgslen.

Ja der var da ihvertfald noget at tænke over. Jeg har efterfølgende opdaget at der vil være en hel del af de 4096 værdier der vil være 0 og hvis jeg undlader at gemme disse vil datamængden falde ganske betragteligt. Jeg tror simpelthen at jeg prøver mig frem og ser hvordan det går.
Setuppet er en Compaq Proliant ML350 G3 med 4 stk. xeon 2,2GHz og 2 stk hot swapable 36GB HDD i RAID 1+0. Hvordan synes det ser ud?

Send lige et svar larildsen så jeg kan fordele points.

Og iøvrigt tak til benny.tordrup for tippet om covered index.

Hvad siger RAM?
Hvor mange processorer understøtter SQL Serveren (licenser)?

768MB RAM, alle 4 CPU'er i brug i SQL.

Hvis jeg var dig, tror jeg, at jeg ville fylde mere RAM i. Vores produktionsserver med SQL har 1 Gb i - og vi snakker meget mindre datamængder end dig.

Det ligner en rigtig god maskine.

RAM/CPU er dog ret lav, så jeg er enig med Benny - hvis den skal have
lidt ekstra så skal den have mere memory.

Har netop bestilt 4GB, så nu er det op til budgettet.
Forresten er der ikke behov for nogen log på disse data. Er det nok at sætte recovery model til simple eller bør jeg gøre noget andet.

Hvis loggen er ligegyldig, så sørg for at sætte recovery til simple. Det får ikke log-filen til at vokse uhæmmet.

Ups, der røg alle pointene. Jeg forsøgte ellers at give 20 til hver svar. Hvad nu larildsen?

Hmmm sblar, pyt med pointene.
Jeg ville jo nok sørge for lidt flere diske end 2 stk, da du også har din transaktionslog at tænke på, og denne bør ligge på et separat raid-1 sæt.
hvis du skal have 114 tps tror jeg dine diske får meget travlt.
Een disk kan normalt lave 150-200 io operationer per sekund, men qua at logfilen ligger sammt med resten vil jeg tro at du har et potentielt problem.

Da ikke, hvis han sætter recovery model til simple? Det reducerer log-filen til mindre end 2 Mb. Skrives der overhovedet til log-filen, hvis recovery er simple?

Jo, der skrives til loggen, så en sep. disk til log vil være en fordel.

Der skrives nøjagtigt lige så meget til logfilen i simple mode, den eneste forskel er at i simple mode fjerner den de commitede transaktioner ved checkpoint, og kan dermed genbruge pladsen - Nøjagtigt det samme som SQL7's truncate log on checkpoint.
Og lav ny ikke logfilen for lille, og lad den ikke udvide sig med mindre end 200-500 mb per udviddelse.

Nu vi så nævner udvidelse af filen, så bør du alvorligt beregne hvor meget plads, der typisk vil være behov for. Der nævnet 7 Gb et sted. Det vil være en fordel for dig at starte med at lave databasen på mindst 7 Gb. Derefter skal du udvide i blokke på et fast antan Mb (f.eks. 500 Mb eller 1 Gb). Procentvis ændring vil tage længere og længere tid, efterhånden som databasen vokser.

Ved at lave databasen med en startstørrelse på 7-8 Gb (eller hvad du regner dig frem til) undgår du, at databasen skal udvides kraftigt mange gange inden, du når op på den normale driftstørrelse. Udvidelserne tager tid for SQL Serveren - og desuden risikerer du, at den fysiske databasefil bliver fragmenteret i filsystemet. Det gør du ikke, hvis du laver startstørrelsen stor nok til, at udvidelser ikke bliver nødvendige.