Fördela innehåll över flera tabeller

[Admini]

Hej

När det blir för mycket datamängd i en tabell så blir det förmodligen trögt att anropa och läsa/skriva till tabellen.

Hur gör man för att fördela mängden information över flera tabeller med likadan struktur, automatiskt?

 

Man vill väl inte ha flera Mb, ja kanske t.o.m Gb i en enda tabell.

Som t.ex. här på eforum

 

mvh

[Mr Andersson]

Det borde inte vara ett problem, oavsett datamängd. Har man bra index så löser det mycket, men kan ev försämra skrivningar.

 

Det som dock tar tid i en relationsdatabas, är ironiskt nog, just relationer, alltså JOIN, men har man vettiga index så går det ändå hyfsat snabbt.

 

Men att dela upp datan i flera tabeller låter inte som en bra lösning. Istället för en fragmenterad tabell, har du 10.

 

Du kan dock låta databasservern dela upp tabellen på flera filer, så att du inte springer i taket pga av begränsningar i filstorlek.

[Admini]

Det borde inte vara ett problem, oavsett datamängd. Har man bra index så löser det mycket, men kan ev försämra skrivningar.

 

Det som dock tar tid i en relationsdatabas, är ironiskt nog, just relationer, alltså JOIN, men har man vettiga index så går det ändå hyfsat snabbt.

 

Men att dela upp datan i flera tabeller låter inte som en bra lösning. Istället för en fragmenterad tabell, har du 10.

 

Du kan dock låta databasservern dela upp tabellen på flera filer, så att du inte springer i taket pga av begränsningar i filstorlek.

 

Vad menas med en bra index ?

 

låta databasservern dela upp tabellen på flera filer

Det här låter mycket bättre. Hur gör man det?

Tack

[Mr Andersson]

Bra index:

Om du tex har ett kundregister, då kan du ha index på kundnr, namn mm. Det som du har index för, skapas det en indextabell för, som databasen använder internt.

 

Sökningar går snabbt, men om du skriver mycket data till en tabell, måste indexen uppdateras ofta, vilket kan ta tid.

 

Att dela upp på flera filer är aktuellt när man närmar sig operativsystemets gräns på filstorlek. Under 4 GB ser jag ingen anledning till det.

[Admini]

Bra index:

Om du tex har ett kundregister, då kan du ha index på kundnr, namn mm. Det som du har index för, skapas det en indextabell för, som databasen använder internt.

 

Sökningar går snabbt, men om du skriver mycket data till en tabell, måste indexen uppdateras ofta, vilket kan ta tid.

 

Att dela upp på flera filer är aktuellt när man närmar sig operativsystemets gräns på filstorlek. Under 4 GB ser jag ingen anledning till det.

 

 

Så du menar, det här att dela upp tabellen i flera filer görs automatiskt och jag behöver inte tänka på det?

[Mr Andersson]

Kan inte svara på om det görs automatiskt, men av alla de databaser jag haft med att göra har det aldrig varit ett problem. Mitt bästa tips, är att låta databasservern göra sitt jobb och strunta i hur den gör det

[Jari Karivainio]

Hej!

Mr Andersson har rätt. Allt sätts upp/konfigureras i samband med initialisering av en databas. Där definieras var och hur ett så kallat "tablespace" allokeras samt hur det skall "växa" via så kallade "extents". Samma gäller för tabeller som allokeras inom ett "tablespace". Tabeller definieras med en initial storlek samt hur de skall "växa" genom "extents" som anger hur mycket tabellen skall utökas när behov uppstår. Dessutom har jag för mig att det finns en parameter som säger hur många gånger ett "tablespace" eller en "tabell"

kan utökas. Detta sker per automatik, det enda en dba behöver hålla koll på är fysiskt utrymme på diskar. Det går i regel snabbare att "droppa" och skapa om ett index än att köra en "rebuild" av det. Det finns verktyg inbyggda i de flesta databaser en dba kan använda för att kunna optimera och trimma en databas. Vissa åtgärder an kräva att databasen eller delar av den tas "offline" vilket kan schemaläggas, även åtgärder kan scriptas och schemaläggas. Termer jag använt är hämtade ur oraclevärlden från min tid som system och databas administratör.

/// Jari

[Admini]

Hej!

Mr Andersson har rätt. Allt sätts upp/konfigureras i samband med initialisering av en databas. Där definieras var och hur ett så kallat "tablespace" allokeras samt hur det skall "växa" via så kallade "extents". Samma gäller för tabeller som allokeras inom ett "tablespace". Tabeller definieras med en initial storlek samt hur de skall "växa" genom "extents" som anger hur mycket tabellen skall utökas när behov uppstår. Dessutom har jag för mig att det finns en parameter som säger hur många gånger ett "tablespace" eller en "tabell"

kan utökas. Detta sker per automatik, det enda en dba behöver hålla koll på är fysiskt utrymme på diskar. Det går i regel snabbare att "droppa" och skapa om ett index än att köra en "rebuild" av det. Det finns verktyg inbyggda i de flesta databaser en dba kan använda för att kunna optimera och trimma en databas. Vissa åtgärder an kräva att databasen eller delar av den tas "offline" vilket kan schemaläggas, även åtgärder kan scriptas och schemaläggas. Termer jag använt är hämtade ur oraclevärlden från min tid som system och databas administratör.

/// Jari

 

Tack för den utförliga beskrivningen.

Men det var inte utrymmet en tabell upptar på servern som var problemet, utan att storleken på tabellen gör sidan långsam.

Säg t.ex. att en tabell som flera hundra användare läser och skriver till kommer att i framtiden ha 100 000 tals rader, kanske ännu mer.

Och när en användare vill hämta en tråd som bara består av 10 inlägg, dvs 10 rader, så måste SQL-satsen leta igenom alla 100 000 raderna ändå.

Och när man tänker sig att flera hundra användare samtidigt läser och skriver till tabellen, så kan man inse att det kommer att bli långsamt.

 

Tänker jag rätt eller... ?

 

Tack

[Mr Andersson]

Som jag redan har svarat ; med rätt index blir det inte långsamt, inte ens med miljontals rader.

 

Gör index för de sökkriterier du använder.

[Admini]

Som jag redan har svarat ; med rätt index blir det inte långsamt, inte ens med miljontals rader.

 

Gör index för de sökkriterier du använder.

 

 

Hej

Vad menar du med Gör index exakt?

Tack

[jarlh]

Kolla upp CREATE INDEX i manualen för din databashanterare. (Det är lite olika från produkt till produkt.)

 

Säg att du har följande tabell

 

CREATE TABLE t (c1 integer primary key, c2 character(10));

 

Gör du sökningar på tabellen t där du ställer villkor på c1 kommer det gå fort, för värdena är sorterade. (select * from t where c1 = 12345)

 

Gör du sökningar på tabellen t där du ställer villkor på c2 kommer det gå långsamt, för värdena ligger huller om buller. (select * from t where c2 = 'qwerty')

Skapar du då ett index, typ CREATE INDEX indx_t_c2 ON t (c2), så kommer även sökningarna med villkor på c2 gå fort!

 

Notera att index kräver administration vid INSERT/UPDATE/DELETE, så skapa inte en massa onödiga index!

[Admini]

Kolla upp CREATE INDEX i manualen för din databashanterare. (Det är lite olika från produkt till produkt.)

 

Säg att du har följande tabell

 

CREATE TABLE t (c1 integer primary key, c2 character(10));

 

Gör du sökningar på tabellen t där du ställer villkor på c1 kommer det gå fort, för värdena är sorterade. (select * from t where c1 = 12345)

 

Gör du sökningar på tabellen t där du ställer villkor på c2 kommer det gå långsamt, för värdena ligger huller om buller. (select * from t where c2 = 'qwerty')

Skapar du då ett index, typ CREATE INDEX indx_t_c2 ON t (c2), så kommer även sökningarna med villkor på c2 gå fort!

 

Notera att index kräver administration vid INSERT/UPDATE/DELETE, så skapa inte en massa onödiga index!

 

Jag gör mina tabeller så här:

CREATE TABLE IF NOT EXISTS `tabell_1` (`id` INT NOT NULL AUTO_INCREMENT, ... , `datum` DATETIME NOT NULL, PRIMARY KEY ( `id` ) )

 

Ok, om jag förstått rätt så skapar man en "extra" tabell för index. Frågan är: NÄR skapar jag denna index?

Är det i samband med att jag skapar tabell_1, eller är det innan jag ska söka igenom tabellen

 

Tack på förhand

[jarlh]

Kolla upp CREATE INDEX i manualen!!!

 

Med största möjliga trolighet skapas "index-tabellen" helt automatiskt då du gör CREATE INDEX. (Men jag kan inte din produkt, så läs på!)

 

 

När man ska skapa index? När man gör sökningar med villkor på kolumner som inte är indexerade (typ primary key, unique, index), och man tycker det går för långsamt.

 

Du kan alltså skapa index när du vill, och ta bort dem med. Notera att ju fler rader du har i tabellen desto längre tid tar det att skapa indexet.