Flere kunder i samme database

[N_R]

Hei,

 

lurte på om dere har noen kommentarer til database-modellen vår. Når det gjelder databasemotor så kjører vi på SQL Express 2005 for øyeblikket, men skal opp på fullversjonen om ikke så lenge.

 

Vi har egentlig en helt vanlig database, som ser ut noe sånt som dette:

CompanyId, CompanyName..... osv osv. Spørringene blir altså "ditten datten where companyid=".

 

Dette har egentlig fungert helt greit - frem til nå. Vi begynner å bli litt offer for vår egen suksess, og ønsker å være litt forberedt på et større antall kunder litt FØR behovet oppstår. Vi ser for oss 3 hovedproblemer fremover:

 

1) Alle kundene "i en haug" betyr i praksis at alle må oppgraderes samtidig. (Vi har ikke kapasitet til schemas, versioning og hva det heter alt sammen) Ikke alle ønsker dette, noen av kundene ønsker å beholde versjon fremfor å "bli med" opp til neste versjon. Dessuten er det VELDIG praktisk å oppgradere kundene "en og en " i tilfelle det er en kjempebug et eller annet sted - tabber vi oss ut blir det en telefonstorm uten like. Dette er også vanskelig å få til med alle kundene i samme base.

 

2) Ytelsen blir ofte redusert, vi ser vi får en del store table-scans. Hvis alle kunder lager like mange entries i loggen vil jo en log for en kunde kun hente ut hver 1000 linje hvis det er 1000 kunder. Man kan klustre på kundeid, kaste på indexes osv, men da må man betale litt for det ved inserts. Uten å gå i detaljer så får vi uansett en del scans, og million-raders tabeller blir da litt drøyt. All informasjonen er kun interessant internt i Kunden, vi skal aldri joine med andre kunders data osv

 

3) Vi kan etterhvert ende opp i en situasjon hvor en databaseserver ikke takler alle kundene (tvilsomt, men det er lov å håpe! ). Db-clustering er litt utenfor vår kompetanse, så det blir nok at man fyrer opp server nr 2 og legger alle nye kunder på denne. Men da må admin-verktøyene våre plutselig joine info fra 2 eller flere database-servere....

 

 

 

Alternativet er å lage noe automatikk og lage et system som oppretter en ny database for hver kunde, men det er heller ingen lur løsning. Man vil få et fryktelig antall baser, man vil antageligvis få langt flere connection threads som tusler og går, og ikke minst backup blir jo et mareritt.

 

Med mitt noe begrensede kjennskap til dette så lurer jeg på om løsningen ligger et sted i mellom, med kunde 1-999 i en database, kunde 1000-1999 i en base osv? Noen som har erfaringer med noe lignende? Steder jeg bør lese om dette på nettet?

 

Takker for alle tips jeg måtte få! :-)

[roac]

1) Alle kundene "i en haug" betyr i praksis at alle må oppgraderes samtidig. (Vi har ikke kapasitet til schemas, versioning og hva det heter alt sammen) Ikke alle ønsker dette, noen av kundene ønsker å beholde versjon fremfor å "bli med" opp til neste versjon. Dessuten er det VELDIG praktisk å oppgradere kundene "en og en " i tilfelle det er en kjempebug et eller annet sted - tabber vi oss ut blir det en telefonstorm uten like. Dette er også vanskelig å få til med alle kundene i samme base.

Naturligvis blir det slik, det er en av konsekvensene av å ha alle i kundene i en database. En feil rammer alle, alle må oppgradere samtidig osv.

 

2) Ytelsen blir ofte redusert, vi ser vi får en del store table-scans. Hvis alle kunder lager like mange entries i loggen vil jo en log for en kunde kun hente ut hver 1000 linje hvis det er 1000 kunder. Man kan klustre på kundeid, kaste på indexes osv, men da må man betale litt for det ved inserts. Uten å gå i detaljer så får vi uansett en del scans, og million-raders tabeller blir da litt drøyt. All informasjonen er kun interessant internt i Kunden, vi skal aldri joine med andre kunders data osv

For å være litt eplekjekk, det er fordi dere ikke kan sakene deres. Dere bør seriøst kikke på indeksering, og ikke minst finne ut når clustring er hensiktsmessig, og når det ikke er det. En god pekepinn vil være at clustered indexes kan være hensiktsmessige når dataene som settes inn har et felt som er tilnærmet strengt stigende eller synkende. Det finnes andre scnearier også, dette må læres. Og bare for å gjøre det klart hvor stort emnet indeksering er, Kimberly Tripp kjører glatt et femdagers kurs i indeksering.

 

Kort fortalt, med fornuftig indeksering i et slikt scenario som du beskriver så skal table scan kun unntaksvis forekomme, det kan være at du får index scan, men den vil også gå vesentlig raskere enn en table scan, og med korrekt konfigurering av hardware så ligger hele indeksen i minnet, og det er ikke noe problem å snakke om.

 

3) Vi kan etterhvert ende opp i en situasjon hvor en databaseserver ikke takler alle kundene (tvilsomt, men det er lov å håpe! ). Db-clustering er litt utenfor vår kompetanse, så det blir nok at man fyrer opp server nr 2 og legger alle nye kunder på denne. Men da må admin-verktøyene våre plutselig joine info fra 2 eller flere database-servere....

 

For det første, i et cluster ligger ikke databasene på en server, men på en delt ressurs, delt av en eller flere servere. For det andre beskriver du noe i retning av et aktiv/aktiv cluster, dvs at begge serveren har kontroll over ca halvparten av databasene samtidig. Dette er soleklart ikke anbefalt hvis du skal kjøre cluyster, men når det er sagt. Hvis du lager en løsning som du forventer at kan ta av, så må du også tenke på dette når du lager administrasjonsverktøyene dine, og du må ta høyde for at det blir flere databaseservere.

 

Alternativet er å lage noe automatikk og lage et system som oppretter en ny database for hver kunde, men det er heller ingen lur løsning. Man vil få et fryktelig antall baser, man vil antageligvis få langt flere connection threads som tusler og går, og ikke minst backup blir jo et mareritt.

Dette er ikke noe problem. SQL Server håndterer glatt tusenvis av databaser, det blir uansett mange connection treads, for det blir vel en pr aktive kunde uansett. Backup fungerer også helt fint, for du trenger ikke ta backup av alle databasene samtidig, men kan ha et script som tar backup av alle databasene dine, en etter en. Og en stor fordel med denne fremgangsmåten er at du holder dataene adskilt. Såvidt jeg som utenforstående vet så er det slik Visma gjør det, og de har vel flere titusener av databaser.

 

Med mitt noe begrensede kjennskap til dette så lurer jeg på om løsningen ligger et sted i mellom, med kunde 1-999 i en database, kunde 1000-1999 i en base osv? Noen som har erfaringer med noe lignende? Steder jeg bør lese om dette på nettet?

Det bør ikke være noe problem å gjøre det slik, men jeg hadde helt klart hatt en database for hver kunde.

9399749[/snapback]

[N_R]

For å være litt eplekjekk, det er fordi dere ikke kan sakene deres.

Hehe, det er derfor vi spør! :-) Vi er programerere hele gjengen, og ikke vant til databaser på denne størrelsen. Alt vi lager er såpass "enkelt" at ALT funker. Vi har Xeon-servere av nyere dato og 4GB minne, altså nærmest null vits å optimalisere når timeprisen pr hode er 600 spenn+++. Problemet er jo at hvis/når løsningen "tar av", så må løsningen være å kjøpe flere servere - å bruke 4 måneder på å skrive om databasen osv osv er ikke et alternativ.

 

Har dog lest litt om database design, og der er det vill & heftig diskusjon hvorvidt man skal dynge på indekser eller ikke, og når man skal gjøre det. (Indekser på mann/kvinne er for eksempel liten vits siden du får tilbake omtrent halve radene uansett, osv osv osv)

 

Men, hvis (mer intelligent bruk av) indekser (enn vi har til nå) redder oss - ihvertfall for en "mellomstor" løsning, så er det antageligvis den beste løsningen. Ikke vits å skyte spurv med kanon heller.

 

Dette er ikke noe problem. SQL Server håndterer glatt tusenvis av databaser, det blir uansett mange connection treads, for det blir vel en pr aktive kunde uansett. Backup fungerer også helt fint, for du trenger ikke ta backup av alle databasene samtidig, men kan ha et script som tar backup av alle databasene dine, en etter en. Og en stor fordel med denne fremgangsmåten er at du holder dataene adskilt. Såvidt jeg som utenforstående vet så er det slik Visma gjør det, og de har vel flere titusener av databaser.

 

Det bør ikke være noe problem å gjøre det slik, men jeg hadde helt klart hatt en database for hver kunde.

 

Ja, jeg vurderer seriøst dette, det vil også gjøre det en del tryggere - selv om vi har sikret oss mot selvsagte ting som SQL-injection osv, så er det sikkert en del ting som kan gå oss forbi. Kanskje også kodefeil, noe a la "delete from company" hvor man har kommentert ut "where companyid =" osv osv. Separere data for hver kunde er absolutt ikke så dumt.

 

Det som er utfordringen er at jeg er usikker på hva jeg gjør med connections - fordi flere kunder vil ha flere bokser som vil generere ca et kall hvert 5 sekund ved hundre bokser. For 5 kunder i samme database kunne jeg da hatt 1 kall hvert sekund som en connection fint ville ha klart, men for 5 kunder med hver sin database vil jeg nok få et større antall connections enn 1 for disse 5 kundene totalt. (jeg "over-forenkler" nå, men du skjønner forhåpentligvis hvor jeg vil hen)

[kaffenils]

Det som er utfordringen er at jeg er usikker på hva jeg gjør med connections - fordi flere kunder vil ha flere bokser som vil generere ca et kall hvert 5 sekund ved hundre bokser. For 5 kunder i samme database kunne jeg da hatt 1 kall hvert sekund som en connection fint ville ha klart, men for 5 kunder med hver sin database vil jeg nok få et større antall connections enn 1 for disse 5 kundene totalt. (jeg "over-forenkler" nå, men du skjønner forhåpentligvis hvor jeg vil hen)

9416761[/snapback]

 

Du kan ha tusenvis av aktive connections. Det fungerer ikke slik at hver connection kjører i en egen thread. SQL Server har noe som kalles worker threads. En worker thread gjør arbeid på "oppdrag" fra en connection, dvs. når du kjører en SQL batch. Når denne jobben er ferdig så frigir SQL Server worker threaden og den kan nå utføre arbeid for andre connections. Maks antall worker threads kan du selv konfigurere. Les mer her: http://msdn2.microsoft.com/en-us/library/ms187024.aspx

 

Du skjønner sikkert også nå at det å bruke tid på riktig indexering også henger sammen med hvor mange SQL-kall en eller flere connections kan utføre. Jo raskere en worker thread blir ferdig jo raskere kan den utføre arbeid som ligger i kø fra andre connections. Anbefaler at du leser "SQL Server 2005, Inside the Storage Engine" av Kaleen Delaney. Her får du detaljert innsikt i hvordan SQL Server fungerer under panseret.

[roac]

Du skjønner sikkert også nå at det å bruke tid på riktig indexering også henger sammen med hvor mange SQL-kall en eller flere connections kan utføre. Jo raskere en worker thread blir ferdig jo raskere kan den utføre arbeid som ligger i kø fra andre connections. Anbefaler at du leser "SQL Server 2005, Inside the Storage Engine" av Kaleen Delaney. Her får du detaljert innsikt i hvordan SQL Server fungerer under panseret.

9419458[/snapback]

Kunne ikke vært mer enig, det er en genail bok. Men, om de ikke er oppegående på SQL Server fra før er jeg redd at den kan bli litt i tyngste laget, og da kan det godt anbefales å lese hele serien som boken er en del av, nemlig Inside SQL Server 2005. Vi snakker da om adskillige sider med kvalitetslitteratur. Men, det er en grunn til at jeg har flere kopier av boken du anbefalte

[roac]

Hehe, det er derfor vi spør! :-) Vi er programerere hele gjengen, og ikke vant til databaser på denne størrelsen. Alt vi lager er såpass "enkelt" at ALT funker. Vi har Xeon-servere av nyere dato og 4GB minne, altså nærmest null vits å optimalisere når timeprisen pr hode er 600 spenn+++. Problemet er jo at hvis/når løsningen "tar av", så må løsningen være å kjøpe flere servere - å bruke 4 måneder på å skrive om databasen osv osv er ikke et alternativ.

 

Har dog lest litt om database design, og der er det vill & heftig diskusjon hvorvidt man skal dynge på indekser eller ikke, og når man skal gjøre det. (Indekser på mann/kvinne er for eksempel liten vits siden du får tilbake omtrent halve radene uansett, osv osv osv)

 

Men, hvis (mer intelligent bruk av) indekser (enn vi har til nå) redder oss - ihvertfall for en "mellomstor" løsning, så er det antageligvis den beste løsningen. Ikke vits å skyte spurv med kanon heller.

9416761[/snapback]

Hvis det er en quick and "dirty" løsning du vil ha: Database Engine Tuning Advisor.

 

Folk må gjerne kritisere meg for utsagnet, men jeg føler sterkt at dette er et av mange tilfeller hvor prosjektledelsen bør få skarp kritikk for ikke å ha trukket inn nødvendig personale (databaseutviklere) på et tidlig stadium. Det kunne utvilsomt hindret uheldige situasjoner.

[N_R]

Folk må gjerne kritisere meg for utsagnet, men jeg føler sterkt at dette er et av mange tilfeller hvor prosjektledelsen bør få skarp kritikk for ikke å ha trukket inn nødvendig personale (databaseutviklere) på et tidlig stadium. Det kunne utvilsomt hindret uheldige situasjoner.

9420422[/snapback]

 

Så sant, så sant :-) Litt bedre planlegging hadde ikke skadet, men samtidig har denne situasjonen kommet litt bardust på oss. For å gjøre en lang historie kort, så møter vi økende konkurranse fra mange hold. Og siden vi har bestemt oss for å gå drastisk til verks så ønsker vi også å få med oss "the long tail", kunder som vanligvis er for små til å håndteres - kanskje til og med også bruke løsningen gratis og hvor en del forhåpentligvis oppgraderer til en Pro-versjon.

 

I den forbindelse skal vi sette opp en løsning hvor kunder kan registrere seg selv, og derfor dette dilemmaet. Vi kan derfor få et rimelig varierende kundeoppsett, få og store med mye trafikk, eller mange og små med lite trafikk - eller noe midt i mellom.

 

Applikasjonen skal altså sannsynligvis fungere sånn ca med et kunde- og belastningsnivå som vi er vant til fra før, men denne gangen må vi altså tenke på skalerbarhet og "worst case scenario" på en helt annen måte enn vi har gjort før.

 

Selve SQL'en er på et nivå vi håndterer med eksisterende kunnskap, det er kun skaleringsproblematikken vi trenger hjelp til. Tvilsomt at vi rekker å lese oss til dette, hvor får man enklest tak i eksperthjelp på dette området? Er det konsulentselskap som spesialiserer seg på dette?

[blackbrrd]

Konklusjonen her er vel å ha en database pr kunde?

 

Personlig tror jeg det er lite morsomt å vedlikeholde flere versjoner av ett program, men det er nå meg da...

 

Mao kanskje heller gå for samme versjon på alle klientene, med en auto-update funksjon og features som er "skrudd av" for de som ikke vil oppgradere.

[N_R]

....det er ikke snakk om å vedlikeholde flere versjoner av et program, men å unngå å fokke opp ALLE kundene samtidig ved en oppgradering... Har nemlig prøvd det, med litt varierende resultat. Kan man oppgradere/tilpasse en og en kunde så er det en fordel - om enn noe mer jobb totalt sett

 

Har ikke tatt noen endelig avgjørelse om å separere eller samle alle kundene, skal få en database-guru til å se på modellen - så får vi se åssen det går!

[blackbrrd]

oppgradere en og en kunde hvis du har 1000 kunder på 20 forskjellige versjoner ser for meg ut som ett mareritt.

 

La oss si at du finner en bug i versjon 3 av programmet ditt og du nå må fikse samme feilen i versjon 3-20, utenom i versjon 12-15 hvor buggen er blitt endret litt?

 

Ser for meg kjapt eskalerende vedlikeholdstid med flere forskjellige datamodeller og programversjoner.

Endret 9. september 2007 av blackbrrd

[N_R]

Hehe, meningen er ikke å ha 20 forskjellige versjoner... Saken er at vi nylig oppgraderte hele web-appen vår fra 1.3 til 1.5, og det gikk faktisk stort sett utmerket. Vi fikk en liten feil et par steder, men det ble raskt fikset.

 

Poenget mitt er at hvis dette hadde skjedd hos ALLE kundene, så kunne vi bare pakket sammen.... ergo, det er greit å kunne oppgradere et par testkunder først, for å se at alt går bra. Så flytter man over kundene ettersom man får verifisert at oppgraderingen fungerer. Er det noe feil, så har kan kanskje 20 pc'er som ikke funker istedet for 2000

[blackbrrd]

Skjønner jo også at det ikke er meningen å ha 20 forskjellige versjoner, men det hørtes ikke ut som om man MÅ oppgradere... og da blir det fort mange versjoner - ihvertfall hvis dere releaser ofte (som vanligvis er en god ting).

 

Poenget er at dere burde ha en måte å automatisk få oppgradert kunder etter relativt kort tid. Du trenger som sagt ikke gi dem tilgang til ny funksjonalitet, men du burde ha samme kode-base for hele programmet.

[N_R]

Ja, vi oppgraderer alle vha scripts, og selvsagt er alle 1.3 over på 1.5 før noen 1.5 oppgraderes til 1.6 eller hva det nå måtte være.

 

Men du har også rett i at enkelte kunder som har noen små-tilpasninger faktisk er fornøyd med akkurat det de har - om det blir et krav eller bare et ønske vet jeg ikke, men det må i tilfelle bli en låst versjon, som ikke rettes på. Dette kan jeg ikke svare på siden det ikke er meg som tar akkurat den avgjørelsen...

[Wattengård]

....det er ikke snakk om å vedlikeholde flere versjoner av et program, men å unngå å fokke opp ALLE kundene samtidig ved en oppgradering...   Har nemlig prøvd det, ...

9461040[/snapback]

 

Hmm... Sier du her at du har prøvd å fucke opp alle kundene samtidig?

Lyktes du?

 

-C-

[N_R]

....det er ikke snakk om å vedlikeholde flere versjoner av et program, men å unngå å fokke opp ALLE kundene samtidig ved en oppgradering...   Har nemlig prøvd det, ...

9461040[/snapback]

 

Hmm... Sier du her at du har prøvd å fucke opp alle kundene samtidig?

Lyktes du?

 

-C-

9491566[/snapback]

 

 

:!: :!: :!: Nei, prøvde jo å unngå det da, men poenget med å ha alle eggene i en kurv er at det går dårlig med alle hvis noe først skulle gå galt. Oppgraderingen gikk ganske så bra den