Central eller decentrale databaser

Hvor meget belastning regner du med at have på det da? De fleste RDB'er er designet til at kunne håndtere rigtig meget I/O, så for langt de fleste mennesker, og til langt det meste brug, er der slet ikke noget spørgsmål om performance af selve databasen. Design dine tabeller rigtigt, lav de rigtige indexes osv, men performance af den underliggende databasemotor er ikke relevant.

Hvis du endelig har tænkt dig at lave de nye facebook eller sådan noget, og forventer at få millioner af brugere, så er der stadig ikke noget problem i at centralisere indgangspunktet - der vil man i stedet typisk sharde databasen, hvilket f.eks. kan gøres med MySQL Cluster.

Hvis du synes det giver mening at dele databasen på én server, er der intet umiddelbart i vejen med det. Du skal naturligvis bare huske at det også giver et SPOF, eller single point of failure - altså, at hvis serveren med databasen går ned, vil ingen af siderne virke. Det kan være en skidt ting, an på formålet.

Der er vel 3 mulige loesninger:

A)

1 server instans
1 database
alle tabeller har et domaene felt

B)

1 server
en database per domaene med hver sit saet af tabeller

C)

en server instans per domaene

#A betyder at du kun skal opdatere database struktur en gang, mens #B og #C betyder at opdateringer skal udfoeres flere gange.

#A betyder ogsaa at all SQL saetninger skal have en ekstra WHERE betingelse, mens #B og #C undgaar dette.

Forskellen paa #B og #C er at med #B kan du kun skalere vertikalt mens du med #C ogsaa kan skalere horisontalt.

Jeg vil ikke vaelge #A. Af 2 aarsager:
* den ekstra WHERE betingelse er en PITA
* det kan være en fordel at kunne opdatere domainerne paa forskellige tidspunkter
* database struktur opdateringer skal naturligvis findes som SQL script (i source control!) og det er ikke noget stort problem at koere det script flere gange

Og jeg tror ikke paa at du har et skalerings behov der kraever #C.

Saa derfor er mit bud: #B.

Tak for svarene

Arne_v: Kan jeg godt følge. Det er ikke et kæmpe projekt, men det kan ende med at blive fordelt på f.eks. 50 domæner, så tænker at det alligevel er en del at skulle køre det 50 gange, og samtidige er der jo risiko for at der sker noget så struktur ikke er ens på tværs.
Har kigget lidt om der findes en smart måde at opdaterer mange databaser men synes ikke rigtigt det ser ud til det.

Tænker også hvad firmaer der har mange kunder og sælger samme system (a la dandomain) gør når de skal opdaterer system og database - for hvis de f.eks. har 500 kunder kan de vel ikke køre koden 500 gange

Det er altsaa ikke svaert at lave et program som lister alle databaser paa en server og eksekverer det samme SQL for alle.