Avatar billede celcius Nybegynder
07. maj 2004 - 15:27 Der er 6 kommentarer

Arkivering af tabeller

Jeg har udviklet et efterhånden omfattende system med en del brugere. Systemet kører i princippet i en cyklus af en måned af gangen, således at alle data fra måneden før kun optræder i et "arkiv". Det har jeg gjort igennem koden og det fungerer sådan set udmærket. Nu er det sådan at nogle af tabellerne over en måneds tid får tilføjet en del poster - op til 20.000. Den skarpe matematiske hjerne vil hurtigt kunne regne sig frem til atdet er +200k poster om året. Nu er systemet nyt, så jeg har ikke bemærket nogen specielle drawbacks endnu, da de største tabeller endnu ikke indeholder mere end 30k poster.

Mit spørgsmål er så:
Bør jeg lave en arkiveringsfunktion der opretter nye tabeller hver måned og bruger de gamle som arkiv - således at jeg om 3-4 år har en uoverskuelig mængde små tabeller.

Ellers:

Er det ligemeget? Skal jeg bare lade tabellerne vokse?

Det vil aldrig være nødvendigt at se på mere end 5000 poster af gangen - søgningen i tabellerne vil altså altid være begrænsede og man vil aldrig stå i en situation hvor ALLE poster skal gennemses - og da slet ikke på tværs af måneder. Det jeg vil vide er om jeg risikerer at lave en unødvendig arkiveringsfunktion eller om jeg bliver nødt til at lave den før eller siden, da jeg ellers vil stå med et åndsvagt langsomt system om 3-4 år.
Avatar billede arne_v Ekspert
07. maj 2004 - 15:51 #1
+200K rows om året på en MS SQLServer lyder ikke som noget problem.
Avatar billede arne_v Ekspert
07. maj 2004 - 15:58 #2
Illustrerende eksempel:

Lad os sige at rækkerne i gennemsnit er 1000 bytes.

2004 - data 0 MB, system 1 GB RAM + 80 GB data disk
2007 - data 600 MB, system 4 GB RAM + 400 GB data disk
Avatar billede ldanielsen Nybegynder
09. maj 2004 - 23:30 #3
Jeg har tabeller med 3 til 4 millioner poster, og de kører stadig fint. Men det er VITALT at du laver nogle fornuftige indexer på tabellerne. Ellers kan der godt opstå ventetider.

Men hvis man koder fornuftigt kan det fint køre.
Avatar billede trer Nybegynder
10. maj 2004 - 09:02 #4
Ida har ganske ret mht indeks og at få millioner rækker ikke er noget problem. Største tabel i SQL Server jeg har haft havde 900 millioner rækker - og der begyndte det at være lidt sløvt; En select count(*) tog 3-5 minutter pga dårlige indeks.

Hvis du laver en arkiveringsfunktion er det nok at have en enkelt arkiv tabel i en separart database. Du laver så en pakke (via dts eller som et job) der fx hver måned overfører alle rækker fra månederne før til arkivtabellen.

Fordelen ved at have en lille tabel fremfor en stor er, at sql server opdaterer statistikker på indeks når 20% af rækkerne er ændret. Har man flere millioner rækker vil statistikkerne sjældent blive opdatereret - og det er knap så godt.  Men der er altså ingen grund til at lave en tabel per måned etc.

grunden til at du skal have en separart database er, at din arkiv database ikke har samme behov for logning som din oltp database. Du sætter simpelthen arkivdb'en til simple recovery model og sørger for, at der tages backup af den i forbindelse med jobbet.
Avatar billede arne_v Ekspert
25. maj 2004 - 00:06 #5
Lukke tid ?

(og et svar fra mig)
Avatar billede arne_v Ekspert
16. juni 2004 - 23:31 #6
??
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester