Prestandafråga

Hej

Vi sitter och diskuterar vad som är den ultimata lösningen på ett problem.
Vi räknar på worst case scenario 100 000 användare.

Det vi ska bygga är ett närvarosystem. Vi har alltså användare och tillfällen.
De lösningar vi kommit på är att ha en närvarotabell där vi har userID, occasionID

1 De som har närvaro på tillfället får helt enkelt en rad i tillfällen-tabellen.

Detta skulle betyda att på 100 000 användare som har 2 tillfällen per dag så skulle detta leda till ca 150 miljoner rader på två år.

2 Den andra idéen är att skippa närvaro tabellen och köra ett fält i lektionen där man lagrar användarID komma separerat som en sträng.
Dock tror vi att det blir krävande sökningar när man ska ta ut näravro för en användare under ett år. Även andra sökningar blir jobbiga.

Eftersom det rör sig om statiska data, dvs. händelsen har inträffat och kommer inte att ändras, så kör man med Id,Ts,Status på de närmsta månaderna Sedan aggregerar man uppgifterna som en Månadspost med Id,Månad,summa närvaro eventuellt som en sträng för just det idét.
Det är viktigt att skilja på levande data och historiska. Innan du är uppe i hundrak registrarade Id kommer du på en lösning för att hantera historiska data. Kör på 1

Om man ponerar att varje aktivitet sträcker sig under 5 månader
med ca 3 aktivitetstillfällen per vecka så blir det lite skumt att
månadssummera närvaron. medan aktiviteten fortfarande fortlöper skulle man
vilja kunna hämta och eventuellt redigera data'n. Helst skulle man ju vilja ha det
så att när aktiviteten utgår så summerar man historisk närvaro och tar ur från
tabellen.

Men, 100k användare, ca 20 veckor med 3 tillfällen per vecka, 10 simultana aktiviteter och en närvaroprocent på ca 80% så blir det 48 miljoner poster.
Fortfarande en ganska stor mängd data att bläddra i kontinuerligt för databasen.

Inget annat uppenbart enkelt och snyggt sätt man skulle kunna lösa detta
lyxproblem på?

Jo nu kom det lite mer information. Men fortfarande gäller det jag skrev om levande kärna dvs så länge aktiviteten är öppen.
Sedan för man ihop närvaron som statistikunderlag.
Man kan ju göra en dagsdatabas som sedan för över till en aktivitets / Närvaro databas under natten. Denna har UserId som index
Då kan man fråga på en viss aktivitet och user och få svar direkt.

Klargör syftet! Börja då från andra änden. Vad och när vill ni ha ut data? I vilken form och hur är då frågeställningen?
Id eller aktivitet eller datum eller mängd?
Sedan är det lättare att periodiskt (dygns,vecko,månadsvis) skyffla över till snabba tabeller.

Kom Ni fram till någon lösning?
Vore kul att se hur ni diskuterar ;-)

Lagra inte alla tillfällen man har närvaro. Lagra tillfällena man inte är närvarande istället.

Phorpher skrev:

Lagra inte alla tillfällen man har närvaro. Lagra tillfällena man inte är närvarande istället.

Problemet blir ju när detta data ska sparas i tabellen. Första gången läraren går in på sidan för närvaro eller?

Kom Ni fram till någon lösning?
Vore kul att se hur ni diskuterar ;-)

Nope vi har inte hittat någon bra lösning ännu men vi är inne på att köra på den första lösningen och arkivera. Sen kom Phorpher på en sak som måste testat om det kan funka. Måste bara kolla så att det funkar bra när man ska köra ut statistik osv.

Vad ska sökningarna ta reda på?

Mängden rader bör i sig inte innebära något prestandaproblem.

sökningen skall egentligen ta reda på vilka som var närvarande elelr inte under en specifik aktivitets tillfälle.

En lösning som diskuteras är en blandning. Vid varje närvaro registrering så läggs det in i närvaro tabellen med användarID och tillfälleID, samtidigt finns det en tabell med sammanställning där följande fält finns. aktivitetsID, användarID samt antal närvarotillfällen för användaren under aktiviteten. Eftersom tillfälles specifika queries kommer vara relativt få i helheten så kan stroleken på denna tabell växa sig ganska stor utan att prestandan blir kritisk. Medan de mer frekventa sökningarna som handlar om sammanställning tas ifrån de mindre sammanställda tabellerna.

På detta sätt kan man få ut de mest frekventa sökningarna ur relativt små tabeller där datan redan är sammanställd men förlorar inte ändringsmöjligheterna. vidare kommer närvaro tabellen tömmas från en aktivitet när denna aktivitet är avslutad och sammanställas i en separat tabell som endast kommer användas för rapportsammanställning. Visst kommer databasen bli större då information kommer finnas på två olika ställen men detta är knappast ett problem i dagens servervärld så länge vi inte pratar internationell dominans.