Vet inte om detta är rätt forum, men jag provar ändå.

Har lite frågor vad man ska tänka på när man ska utveckla webbapplikationer med hög trafik och mycket data.

Förutsättningar som jag kommer utgå från asp och sql server.

Ska man använda vyer så mycket som möjligt istället för att skapa alla frågor i koden?
I varje tabell kommer finns en primärnyckel av typen int som automatiskt räknas upp för var post i en tabell. Vad gör man när man nått den övre gränsen för int? Ska man använda ngt annat än int?

Som ni ser så finns många frågetecken så jag skulle vilja ha lite råd och tips vad man ska tänka på vad gäller datatyper vyer m.m. Måste finnas hur mycket som helst.

Den övre gränsen för int är 2 147 483 647
Tror du att tabellen kommer att innehålla mer data än så,
Ta en bigint och du kan räkna upp till 9 223 372 036 854 775 807.

/Håkan

Menas det då att int kan ha 2 147 483 647 poster i en tabell, eller?

1
2
3
4
5
......
2 147 483 647

~Ja. Minus de poster som någonsin har raderats.
2,1 miljarder brukar räcka:
Säg att det tillkommer 100.000 nya poster varje dag året runt, då räcker det i 59 år. :)
Tror du inte att det räcker så är jag väldigt nyfiken på vad detta är för slags system.
För stora databaser med mycket belastning hjälper det att använda Stored Procedures samt att du ser till att indexera varje kolumn som man söker på. Det är också viktigt att ha en primärnyckel i alla tabeller. Annars kan du få problem med att hela tabellen låser sig vid uppdateringar, vilket då kan leda till katastrofal prestanda.

Om det är system för säg, mätningar i processer eller liknande, är 100000 om dagen hyfsat lätt att komma upp i, och det är knappast omöjligt att överstiga en miljon om dagen. Iom "webbapplikationer" är det kanske inte så sannolikt... =)

(Sen kan man ju ifrågasätta om en vanlig RDBM är rätt val i de lägena ändå...)

Niklas: Jaså, vad borde man ha i stället för RDBM?

Om det är processmätningar, några miljoner om dagen?
Det första man nog kan anta är att det aldrig är tal om några "sökningar", utan snarare om summeringar på stora mängder data, etc. Några binära sökträd etc. känns därför helt onödigt.

En spontan ide är ju då t.ex. minnesmappade sekventiella filer på datorer med stora ramminnen, där filerna mappas ner av ett antal processorer och skrivning görs av andra.

Om vi kollar på ACID i sammanhanget:
Atomicity och consistency är enkel att kolla, antingen är en hel post skriven eller ingen, så det behövs inte.

Isolation får man genom att arbeta på separata minnesareor.

Durability får man stötvis i och med minnesmappningen, och det lär ju inte vara någon större vits med ändå, med tanke på hur reguljär data det ändå måste vara, och att om något skiter sig så förlorar man ändå stora mängder data.

Det finns säkert andra smarta datastrukturer med minimal overhead

Du tänkte alltså implementera allt det där med separata minnesareor, minnesmappade sekv filer.. ? Jag tror det är både bättre och billigare att använda en databas.. :)

Har alldeles för mycket att göra, men måste snabbt svara på denna bara... =)

Nä, jag menar bara att
1. om vi arbetar under lite mer extrema situationer än "webbutik" kan vi lätt komma upp i över många miljoner uppdateringar om dagen.
2. det är först där vi börjar få problem med storleken på databaser.
3. å andra sidan är en vanlig relationsdatabas inte speciellt lämpad i de fallen ändå - låsningar, filaccess, transaktioner etc. kan leda till en hel del trassel, så att vi kan hamna i en situation där det ändå inte fungerar i praktiken. I så fall spelar problemet med databasstorleken förmodligen ingen roll i sammanhanget.
4. ett alternativ till en relationsdatabas är då (eftersom du frågade) att gå genom en speciallösning där vi släpper lite på ACID (eftersom det inte alls har samma nytta i en extrem situation), och gör en mer direkt inmatning av data - helt enkelt eftersom det är nödvändigt när en relationsdatabas inte klarar av det. Mitt spontana förslag grundade sig då på sekventiella filer, med en snabb ide om hur man kan åstadkomma en effektiv datainmatning i såna extrema situationer. Typ.

Niklas, även när det gäller en teknisk tillämpning som att lagra mätvärden tycker jag det är självklart att man måste tänka transaktioner och ACID. Man vill ju inte tappa några mätvärden.
Sen förstår jag inte hur du skulle klara att bygga något bättre sätt att lagra data på än t.ex. SQL Server inom en rimlig tidsram för ditt projekt. (Hundra!) miljontals poster är inget problem om man gör rätt.
Läs om denna case study med SQL Server 2005 VLDB, där man pratar storleksordningen:
13 TB, 350 milj poster/dag.
http://download.microsoft.com/download/b/8/f/b8f13247-b992-4f0e-846e-8f89fcaac0bd/VLDB_Management.ppt

Har inte tid, men jag kan ju fan inte låta bli... =)

<b>>även när det gäller en teknisk tillämpning som att lagra mätvärden tycker jag det är självklart att man måste tänka transaktioner och ACID.</b>
Jag kanske var otydlig med mina argument mot transaktioner/ACID i det fallet. Min poäng är att om du har alldeles för hög dataöverföring så är du ändå rökt. I många såna fall är det antingen så att:
1. Enstaka missade poster är kris, och då kan du lika gärna riva upp en hel dags information. Transaktioner och ACIDity hjälper inte ett smack.
2. Enstaka missade poster är skit samma, och då är det helt onödigt att slösa massa tid på transaktioner.

Jag tycker nog att både A och C går att strunta i, medan I och D löser sig med min modell. Men det var som sagt en snabb ide.

<b>>Sen förstår jag inte hur du skulle klara att bygga något bättre sätt att lagra data på än t.ex. SQL Server inom en rimlig tidsram för ditt projekt.</b>
Tja.. sekventiella filer är mycket mer effektiva än binära träd om du vet att data verkligen är rent sekventiell, och aldrig ska sökas ur, och det är ju mycket lätt att implementera. Det finns helt enkelt många egenskaper hos t.ex. mätningar som gör att man kan åstadkomma mer effektiva (dock begränsade) lösningar än databaser kan tillåtas. Minnesmappade filer finns native i BSD.

Niklas, du glömmer att forumet är SQL Server och frågan gäller just webbapplikationer :)

Men eftersom vi ändå håller på :)

Visst kan man tänka sig extrema tillämpningar med en tät ström av mätvärden som skall lagras, men att det är ok att några enstaka mätvärden inte lagras. Samma princip som för onlinespel/UDP-trafik. Men hur ofta bygger den genomsnittlige ASP.NET-utvecklaren en sådan lösning? Inte ofta! Och de som konstruerar sådana system använder ofta färdiga plattformar/produkter som stödjer detta.
Man kommer ändå i de flesta fall (om mätningarna ska vara till någon nytta) vilja ha alla värden i en databas för att kunna göra snabba sökningar, beräkningar, grupperingar, osv.
Då skulle jag i stället föreslå att man använder sig av en köhanterare. Då kan mätprocessen snabbt och asynkront lämna ifrån sig alla mätvärden utan att vara beroende av hur snabb datalagringen är. På andra sidan kön har man ett program som lugnt och kontrollerat betar av kön och lagrar alla värden i en (eller flera) databaser. Detta finns förresten inbyggt i SQL Server 2005 genom Service Brokern, för att återkoppla till forumets rubrik.. :)
Det finns aldrig _ett_ rätt svar hur sådana lösningar ska byggas utan man måste ju trimma in det för det aktuella scenariot, om prestandakraven är extrema. Men jag tror inte att det var detta som trådskaparen ville få svar på..

<b>>Niklas, du glömmer att forumet är SQL Server och frågan gäller just webbapplikationer :)</b>
Nej, då, jag glömmer inte det. Notera mitt tidigare inlägg:
<b>>
Om det är system för säg, mätningar i processer eller liknande, är 100000 om dagen hyfsat lätt att komma upp i, och det är knappast omöjligt att överstiga en miljon om dagen. Iom "webbapplikationer" är det kanske inte så sannolikt... =)

(Sen kan man ju ifrågasätta om en vanlig RDBM är rätt val i de lägena ändå...)</b>

Jag säger inte att den genomsnittlige ASP.NET-utvecklaren ska implementera mitt förslag, och inte att det var det trådskaparen ville ha svar på. Min poäng var bara att det finns applikationer där stora mängder data hanteras, men att databaser oftast ändå inte är användbara då. Mitt förslag är bara en tänkbar implementation i ett extremfall - det var du som frågade vad jag tyckte man skulle ha i extremfallen.

<b>>Man kommer ändå i de flesta fall (om mätningarna ska vara till någon nytta) vilja ha alla värden i en databas för att kunna göra snabba sökningar, beräkningar, grupperingar, osv. </b>
När det kommer till så stora mängder av data är det i stort sett bara grupperingar a'la mapreduce som sker, och där vinner databaser nästan ingenting ändå. Att sätta upp köer som köhanterare "i lugn och ro" får beta av kön funkar inte riktigt om genomsnittshastigheten hos hanteraren är lägre än dataoutputen.

<b>Min poäng var bara att det finns applikationer där stora mängder data hanteras, men att databaser oftast ändå inte är användbara då.</b>

Databaser är oftast inte användbara i applikationer med mycket data? Tjenare! Har du tänkt efter ordentligt nu? :)

<b>>Databaser är oftast inte användbara i applikationer med mycket data? Tjenare! Har du tänkt efter ordentligt nu? :)</b>
<b>>2,1 miljarder brukar räcka:</b>
Ja, alltså: Om man behöver räknare som klarar mer än 2,1 miljarder, dvs. (enligt din fina beräkning) har ett mycket högt dataflöde, behöver man något annat än int som räknare, som är vad hela tråden handlar om. Men i och med det höga dataflödet som i så fall krävs, bör man nog i så fall å andra sidan fundera igenom om en databas är det man ska använda.

Int brukar ju räcka, det är fakta, håller du inte med om det? :)

Annars finns ju bigint.

-2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807).

Det kan eventuellt räcka till en stor webbapplikation med ganska många kundorders eller? :)

Alltså forumet är SQL Server (inte "memorymappade flata UNIX-filer") och tråden handlar om stora webbapplikationer. Ditt uttalande nedan är hårresande för alla som jobbar med stora webbaplikationer, förstår du inte det?

<b>... "Min poäng var bara att det finns applikationer där stora mängder data hanteras, men att databaser oftast ändå inte är användbara då." </b>

Men herregud...

1. Trådskaparen tycker att han har stora mängder data, och frågar om int räcker.
2. Han får i första svaret reda på att, "ja, int räcker, så länge du har färre än 2,1 miljarder poster, annars finns bigint".
3. Du påpekar att 2,1 miljarder är ganska mycket; med 100000 per dag räcker det i 58 år.
4. Jag har inte argumenterat mot detta öht. Däremot, eftersom frågan var avklarad efter fem svar, sticker jag bara in en kommentar om att det finns tillämpningar där en miljon poster/dag inte är ovanligt, men att det knappast är aktuellt i en fråga om webbapplikationer.
5. Å andra sidan, påpekar jag, med ett så högt dataflöde är kanske en vanlig databas inte speciellt lämplig ändå. "Så högt dataflöde" betyder i det här fallet betydligt högre (orders of magnitude) än alla webbapplikationer.

Jag förstår inte riktigt vad det är du hänger upp dig på; jag har svarat på alla frågor om vad det skulle finnas för alternativ och när det skulle vara användbart. Det är du som har frågat mig, det enda jag har sagt är att det existerar situationer där databaser inte är bra alternativ.

Jag har inte påstått att detta är aktuellt i en webbapplikation, utan bara när det kommer till stora datamängder. Om du tycker att jag har använt för lite kraftuttryck kan jag kanske kalla det "jävligt enormt stora datamängder, typ det man får ut av stora mätprocesser med mycket hög datatrafik".

Kan vi konstatera att:
1. Jag har inte en enda gång påstått att trådskaparen bör använda något annat än en db?
2. Jag har inte en enda gång påstått att en utvecklare av webbapplikationer bör använda något annat än en db?
3. Jag har sagt att det <b>existerar</b> tillämpningar där 2,1 miljarder poster inte är ovanligt?
4. Jag har sagt att de tillämpningarna (i stort sett) aldrig uppstår vad gäller webbapplikationer?
5. Jag har sagt att i de tillämpningarna så är databaser inte bra?
6. Jag har sen svarat på dina frågor gällande alternativ?
I så fall förstår jag inte varför du återgår till webbapplikationer och huruvida "de flesta webbutvecklare implementerar ...", eller sql-server. Det är du som har gått in på det här spåret.

Niklas: <b>
Jag förstår inte riktigt vad det är du hänger upp dig på</b>

En gång till:

Niklas: <b>... "Min poäng var bara att det finns applikationer där stora mängder data hanteras, men att databaser oftast ändå inte är användbara då."</b>

Ok, du vill alltså att jag ska ha fler kraftuttryck?

<b>... "Min poäng var bara att det finns applikationer där jävligt hemskt stora mängder data (>1 milj. poster om dagen) hanteras, men att databaser oftast ändå inte är användbara då."</b>

Duger det?

Förstår fortfarande inte vad du vill bidra med här. Många databaser har miljontals poster i sig. En del (VLDB's) har miljarder poster och det lär vara en mycket bättre idé att använda dem än dina egenutvecklade memorymappade filer, samt att detta passar ju bättre som diskussionsunderlag i ett forum som handlar om just databaser. Och nej, det blir inte ett dugg bättre av att du svär. :-D

"Vill bidra med"?
Jag vill inte bidra med någonting, jag har bara gjort ett statement, i övrigt har jag bara svarat på frågor.

Mina påståenden är "Det finns applikationer med mycket stora dataflöden" och "för sådana applikationer är databaser inte nödvändigtvis det bästa alternativet".

Du har sen frågat vad det skulle finnas för alternativ, jag har svarat på det.
Du har sen i princip bara sagt att
1. ingen skulle implementera det i en webbapp, jag har hållit med; jag har aldrig påstått att de skulle göra det.
2. såna datamängder förekommer inte i webbappar, jag har hållit med. (Och till och med sagt det först.)

Kan vi som sagt konstatera de punkterna jag skrev ovan?
Vad håller du inte med om?


(Sen är inte VLDB aktuellt i de situationerna jag pratar om ändå, men det antar jag att du hajar.)

Det är ju redan konstaterat att du tillförde synpunkter som inte hade någonting med trådskaparens fråga eller forumet att göra :)