Databasekeuze-discussie

[Multispeed]

Ik ben met een vriend bezig met een project(je) wat als het goed gaat, flink uit de hand kan lopen(positief gezien). Echter is er een kleine discussie ontstaan betreft database keuze :-)


70,000 regels per user per jaar
elke regel is +/- 15Kb

verwacht word een max van 300,000 users in +/- 5 jaar, voor al deze users is er ook historische data beschikbaar. Dus stel user x is in jaar 1 al actief is dat na 5 jaar dus 70,000 * 5 = 350000 regels voor 1 user met 5 jaar aan historische data.

vanuit deze data worden grafieken gegenereerd die weer als rapport gestuurd worden naar de user.

Nu wil ik het genereren van deze data door PHP laten doen voor al deze users. Dit kan op een aparte server waardoor deze server zich alleen maar bezig hoeft te houden met het genereren van de rapporten. Nu heb ik alleen een discussie met diegene waarmee ik dit wil gaan realiseren.

Hij zegt dit kan je vergeten met MySQL en PHP dat gaat nooit goed en snel werken. Waarop mijn reactie was, er zal vast een combinatie zijn php met ?? waarbij dit normaal mogelijk is.

Wat is jullie gedachten hierover ? Het staat al wel vast dat het een taal of database moet zijn die op een (l)unix server moet kunnen draaien.

[RobIII]

Dus we weten alleen 70.000 records (rijen/tuples) x "15Kb" (wat, alles in 1 veld varchar? 60 tabellen met elk 400 velden?) x 300.000 users x 5 jaar? 105.000.000.000 records x 15Kb = ~1500Tb aan data. En daar moeten we iets zinnigs op zeggen zonder dat we weten hoe die tabel(len) er uit zien, welke indexen (if any), hoe ingewikkeld (of niet) de rapporten zijn, of er wel of niet aan aggregation e.d. gedaan wordt of dat er telkens over de hele periode aan 'rauwe data' heen gelopen moet worden etc.? En dan hebben we 't nog niet gehad over de hardware (of 't budget). Ook is de keuze waarom een *N*X platform per-se gebruikt moet worden niet echt onderbouwd in je topicstart (is er bij een dergelijk project geen ruimte/budget om eens naar andere platformen te kijken mocht dat nodig zijn)? Is er wel ruimte voor iets als PostGres of mogelijk misschien wel een "NoSQL" oplossing voor (delen van) het project?

Dan zou ik op je developer afgaan; die heeft meer kennis over 't project dan wij en kan er geheid zinniger(e) dingen over zeggen. De zaken die je hier vermeldt zijn amper schamel genoeg om te zeggen wat je aan schijven in je server moet douwen, let alone hoe iets zal gaan performen of wat de haalbaarheid is. All I can say is dat als je van plan bent over 5 jaar elke 24 uur (weer) over 1500Tb aan data te lopen om 300.000 users een grafiek te mailen je van verdomd goede huize moet komen om dat een beetje performant te houden op elk platform; er zal dus zéér waarschijnlijk het e.e.a. aan aggregatie/denormalisatie en optimalisatie van het geheel gedaan moeten worden maar wat dat kunnen we je niet vertellen omdat we zo goed als niets van het project weten. 1500Tb in een enkele tabel proppen gaat in MySQL sowieso een uitdaging worden.

[ Voor 19% gewijzigd door RobIII op 09-12-2015 10:07 ]

[Multispeed]

Je hebt gelijk, ik zal het proberen te verduidelijken.

Het is een deel van een project wat we overgenomen hebben van iemand(kwam toevallig op ons pad), ik kan helaas niet te veel in details treden over het project zelf.

Ik heb wel meer informatie over de database voor je. Deze is overgenomen als deel uit dat project en is zonder er veel werk in te steken niet even makkelijk aan te passen.

• 1 tabel met 150 kolommen
• Er zijn(helaas) geen indexen
• De rapporten zijn erg simpel en bestaan uit wat lineaire grafieken die gegenereerd worden aan de hand van de data uit de kolommen
• Er is(helaas) geen data aggregation

De keuze voor een (l)unix platform heeft meer te maken met de keuze voor de webservers en de programmeertalen waarin er geprogrammeerd kan worden. We hebben bijvoorbeeld niet de luxe om het in C#.Net te programmeren. En ik vind het persoonlijk onzinnig om een LAMP of XAMP op windows te gaan draaien om daarmee php te gaan aanbieden. Dan kan ik ook een Debian installatie gebruiken met een Apache(of andere webserver)

Ja er is ruimte voor PostGres en of noSQL oplossingen.

Maar als jij jou reactie lees(laatste deel) Kunnen we beter de database structuur toch aanpassen, iplv het proberen server technisch op te lossen.

RobIII schreef op woensdag 09 december 2015 @ 09:55:
Dus we weten alleen 70.000 records (rijen/tuples) x "15Kb" (wat, alles in 1 veld varchar? 60 tabellen met elk 400 velden?) x 300.000 users x 5 jaar? 105.000.000.000 records x 15Kb = ~1500Tb aan data. En daar moeten we iets zinnigs op zeggen zonder dat we weten hoe die tabel(len) er uit zien, welke indexen (if any), hoe ingewikkeld (of niet) de rapporten zijn, of er wel of niet aan aggregation e.d. gedaan wordt of dat er telkens over de hele periode aan 'rauwe data' heen gelopen moet worden etc.? En dan hebben we 't nog niet gehad over de hardware (of 't budget). Ook is de keuze waarom een *N*X platform per-se gebruikt moet worden niet echt onderbouwd in je topicstart (is er bij een dergelijk project geen ruimte/budget om eens naar andere platformen te kijken mocht dat nodig zijn)? Is er wel ruimte voor iets als PostGres of mogelijk misschien wel een "NoSQL" oplossing voor (delen van) het project?

Dan zou ik op je developer afgaan; die heeft meer kennis over 't project dan wij en kan er geheid zinniger(e) dingen over zeggen. De zaken die je hier vermeldt zijn amper schamel genoeg om te zeggen wat je aan schijven in je server moet douwen, let alone hoe iets zal gaan performen of wat de haalbaarheid is. All I can say is dat als je van plan bent over 5 jaar elke 24 uur (weer) over 1500Tb aan data te lopen om 300.000 users een grafiek te mailen je van verdomd goede huize moet komen om dat een beetje performant te houden op elk platform; er zal dus zéér waarschijnlijk het e.e.a. aan aggregatie/denormalisatie en optimalisatie van het geheel gedaan moeten worden maar wat dat kunnen we je niet vertellen omdat we zo goed als niets van het project weten. 1500Tb in een enkele tabel proppen gaat in MySQL sowieso een uitdaging worden.

[CH4OS]

Vraag is echter, of je 5 jaar aan data bijvoorbeeld wel zou willen bewaren? Ik denk niet dat een gebruiker zover zal terug lezen of zoeken, het lijkt me dus sterk dat je data zo lang wil bewaren, als er al gebruikers zijn die zo lang actief zijn.

Als een project potentie biedt, zou die persoon ook wel gek zijn om dat van de hand te doen, want als er veel potentie is en het slaat aan, valt er dus ook veel mee te verdienen.

[RobIII]

Multispeed schreef op woensdag 09 december 2015 @ 10:41:

• 1 tabel met 150 kolommen
• Er zijn(helaas) geen indexen
• De rapporten zijn erg simpel en bestaan uit wat lineaire grafieken die gegenereerd worden aan de hand van de data uit de kolommen
• Er is(helaas) geen data aggregation

Als je zo 1500Tb aan data wil gaan opslaan en elke 24 uur gaan 'doorspitten' voor 300.000 rapporten dan hou maar meteen op. Dit gaat fa-lie-kant mislukken, end-of-story, no question about it, basta.

Multispeed schreef op woensdag 09 december 2015 @ 10:41:
en is zonder er veel werk in te steken niet even makkelijk aan te passen

Dan zou ik eens beginnen met een kosten/baten en haalbaarheids analyse, marktonderzoek etc. En misschien een realiteitscheck; is 300.000 gebruikers een reeël getal bijvoorbeeld?

Multispeed schreef op woensdag 09 december 2015 @ 10:41:
Maar als jij jou reactie lees(laatste deel) Kunnen we beter de database structuur toch aanpassen, iplv het proberen server technisch op te lossen.

Dat is wel 't minste wat je zult moeten doen. Of je er dan bent is een tweede (en ik zal je vast verklappen dat je dan nog steeds 'a long way from home' bent ).

Maar goed; ook op basis van deze (iets minder karige) informatie kunnen we niet heel veel meer doen dan oppervlakkige observaties maken en hooguit inschatten welke kant dit op gaat. En dat is, als je 't mij vraagt, richting de bodem van de oceaan achter de Titanic aan. Kan er (op basis van wat we nu weten) niet heel veel anders van maken; sorry.

[ Voor 17% gewijzigd door RobIII op 09-12-2015 11:04 ]

[Bloemkoolsaus]

Multispeed schreef op woensdag 09 december 2015 @ 10:41:

• 1 tabel met 150 kolommen
• Er zijn(helaas) geen indexen

Dat gaat op geen enkel platform haalbaar zijn.

Misschien kun je beter eerst je data normaliseren. Je zal zien dat de hoeveelheid data die je hebt naar beneden gaat. Daarna kan je een nieuwe projectie maken over wat je nodig denkt te hebben over 5 jaar.

[Freeaqingme]

Is het uberhaupt wenselijk om nu al zover vooruit te denken? Ik zou iets pakken waar je de eerste 3-6 maanden mee vooruit kan. Dan kan je de dingen doen op een schaal die voor nu relevant voor je is, en zorgt er in de regel voor dat de implementatietijd een stuk lager ligt. Wordt het dan het succes waar je op hoopt kan je altijd in de toekomst de boel omcoden en migreren.

Ja, dat kost op de lange termijn meer tijd, maar een lean en mean oplossing zorgt er wel voor dat je nu snel vooruit kan en in de praktijk kan zien waar de bottlenecks en uitdagingen liggen.

[RobIII]

Freeaqingme schreef op woensdag 09 december 2015 @ 13:40:
Is het uberhaupt wenselijk om nu al zover vooruit te denken? Ik zou iets pakken waar je de eerste 3-6 maanden mee vooruit kan.

Afgaand op de cijfers van TS en dat lineair geïnterpoleerd naar 6 maanden:
30.000 users x 35.000 records x 15kb = ~15TB in 6 maanden. Zonder indexen en andere fatsoenlijke optimalisaties, normalisaties en (bijv.) aggregatie ga je in de eerste maand al op je bek, laat staan 6 maanden. Sterker; nog voor die tijd heb je waarschijnlijk al de nodige limieten van MySQL bereikt.

Freeaqingme schreef op woensdag 09 december 2015 @ 13:40:
Wordt het dan het succes waar je op hoopt kan je altijd in de toekomst de boel omcoden en migreren.

Hoewel de algemene strekking van je post zéker een punt is: met de gegevens die we nu hebben kan ik met vrij grote zekerheid stellen dat je nog voordat je "om-gecode" en/of "gemigreerd" hebt je tegen allerlei limieten en beperkingen bent aangelopen en dat je waarschijnlijk de hele looptijd van 't project alleen maar brandjes aan 't blussen bent om 't spul überhaupt draaiend te houden, laat staan manuren te investeren in R&D en verbetering van het project.

Zelfs non-lineair met een voorzichtige groei van 10% zit je met 6 maanden al op 1Tb en 12 maanden op 3Tb; dat geeft toch te denken

[ Voor 57% gewijzigd door RobIII op 09-12-2015 16:04 ]

[Freeaqingme]

Ik stel ook niet dat je er geen tijd in moet stoppen om het fatsoenlijk draaiend te krijgen. Maar wel dat ik denk dat 5 jaar waarschijnlijk veel te ver vooruitgedacht is. Je kan voor 15 TB perfect een enkele SSD-machine pakken bijvoorbeeld en hier mysql volledig op tunen. Voor 1500 TB ga je toch aan een oplossing denken die aanzienlijk meer tijd kost om op te zetten.

Hoe complexer het systeem, des meer tijd je nodig hebt om nieuwe features te implementeren. Bij een nieuw product - wat in de praktijk na livegang nog alle kanten op kan - wil je dan juist die wendbaarheid hebben om snel in te kunnen springen op de vraag van je eindgebruikers.

[emnich]

Wat wil je in hemelsnaam met een rapport over 350k records. Je gaat toch niet serieus een grafiek maken op basis van 350k datapunten? Waarschijnlijk wil je de data straks per dag, week, maand presenteren. Sla het dan ook zó op en belangrijker, bereken alleen de nieuwe gegevens.

Ga gewoon eerst eens goed kijken naar wat je echt nodig hebt

[TheUninvited]

Ik denk dat voordat je die 70k regels per jaar van 15kb elk per user wilt doorvoeren eerst eens moet nadenken over wat je doel is en hoe je aan deze waarden komt. Want dit is nogal wat data om op te slaan laat staan verwerken. Je moet verder optimaliseren en tenzij je wilt mededelen wat voor data je verwerkt en hoe je die denkt te verwerken kun je daarbij niet geholpen worden.

[The Eagle]

Vertel anders eerst even wat voor data je wilt laden. Je zegt users, maar users die 70k regels per jaar zelf inkloppen lijkt me wat veel van het goede
Neigt mij naar userlogging of security o.i.d., en daarmee automatisch gegenereerd. Kun je het type data specificeren? Praat je over gestructureerde, semi gestructureerde of ongestructureerde data? Voor gestructureerde data kun je in principe nog wel een relationeel DBMS gebruiken. Maar anders praat je over noSQL en andere big data achtige zaken. Opslaan is leuk maar als je toegangspad nar de data ruk is heb je er nog niks aan

Having said that: een beetje dbms kan 1,5TB op jaar basis best aan. Maar dan moet je wel met indexen etc gaan werken, of iig met partitioning.

[RobIII]

The Eagle schreef op woensdag 09 december 2015 @ 15:46:
Having said that: een beetje dbms kan 1,5TB op jaar basis best aan. Maar dan moet je wel met indexen etc gaan werken, of iig met partitioning.

@TS: lees dat a.u.b. niet te optimistisch; die 1.5TB per jaar kan inderdaad best, maar niet als je 't allemaal (zoals je nu beschreef) in 1 table mikkert. Ik heb inmiddels de link naar MySQL's limieten vaak genoeg aangehaald

Partitioning doe je sowieso pas nadat je überhaupt zinnige indexen hebt; daar win je altijd veel meer op. En 1,5Tb na 1 jaar? Volgens de voorzichtige schatting al minimaal 't dubbele

[Hydra]

Klinkt als een aardige usecase voor iets als Cassandra voor storage en dan een proces that de summaries bijwerkt en ergens opslaat (kan ook cassandra maar ook bijvoorbeeld MySQL).

[Wasp]

Bloemkoolsaus schreef op woensdag 09 december 2015 @ 12:50:
[...]


Dat gaat op geen enkel platform haalbaar zijn.

Misschien kun je beter eerst je data normaliseren. Je zal zien dat de hoeveelheid data die je hebt naar beneden gaat. Daarna kan je een nieuwe projectie maken over wat je nodig denkt te hebben over 5 jaar.

Ooh jawel hoor. Dit kan prima met een column-georiënteerde database zoals SAP IQ (voorheen Sybase IQ). Deze heeft in principe geen indexen nodig. Sterker nog, elke kolom is onder water een index op zich.

Dit is dan wel een enterprise oplossing. Maar ik heb klanten met miljarden records in tabellen, performt als een malle zonder enige vorm van index tuning.

Ad-hoc aggregaties (SUM, COUNT, etc) zijn ook nog eens bloedjesnel, binnen IQ is het bv. dus niet nodig om e.e.a. voorgeaggregeerd op te slaan.

Laatste voordeel is dat het out-of-the-box ook nog eens goed comprimeert. Versus SQL Server halen we op grote tabellen ongeveer 80 tot 90 % compressie. Hoe meer data hoe beter de compressie.

Connectiviteit met PHP zou moeten kunnen middels de SQL Anywhere library.

Overigens heb je absoluut gelijk wat betreft normalisatie.

[DukeBox]

Multispeed schreef op woensdag 09 december 2015 @ 10:41:
• 1 tabel met 150 kolommen
• Er zijn(helaas) geen indexen

Bloemkoolsaus schreef op woensdag 09 december 2015 @ 12:50:
Dat gaat op geen enkel platform haalbaar zijn.

Klink toch echt als een schoolvoorbeeld van een reden voor een NoSQL oplossing.

Hoe dan ook.. 150 kolommen in 1 tabel.. opzich geen probleem voor MySQL maar het hangt er echt vanaf wat je er mee doet.


In eerste instantie zag ik veel overeenkomsten met de stats voor /5 die ik al jaren maak.. geen 150 kolommen (de db is tegenwoordig wel wat logischer opgezet) maar per uur worden daar zo'n 3,4 miljoen records geupdate en dezelfde hoeveelheid komt er dagelijks bij.

code:

op dit moment:
rijen: 61,461,250,315   
data: 134,5 GiB
index: 278,9 GiB

[RemcoDelft]

70,000 regels per user per jaar
elke regel is +/- 15Kb

verwacht word een max van 300,000 users in +/- 5 jaar,

Als je dergelijke exponentiele groei hebt, lijkt het me een goed begin om eens te kijken hoe nuttig de data is. Ik kom uit op elke 8 minuten 15kB per user, ik kan me haast niet voorstellen dat dat nuttige data is, en niet een factor orde-grootte 100 tot 100.000 kleiner kan.

[Tjolk]

Multispeed schreef op woensdag 09 december 2015 @ 10:41:
Deze is overgenomen als deel uit dat project en is zonder er veel werk in te steken niet even makkelijk aan te passen.

Blijkbaar is er al sprake van een huidige situatie. Wat voor DBMS zit dat in? Hoeveel data heb je inmiddels?

Multispeed schreef op woensdag 09 december 2015 @ 10:41:

• 1 tabel met 150 kolommen
• Er zijn(helaas) geen indexen
• De rapporten zijn erg simpel en bestaan uit wat lineaire grafieken die gegenereerd worden aan de hand van de data uit de kolommen
• Er is(helaas) geen data aggregation

150 kolommen in 1 tabel? Geen indexen? Wat voor vage data praat je dan over? Is er enige relatie tussen de verschillende kolommen? Kun je niet wat gaan normaliseren?

Je praat ook over 70000 regels per user per jaar, dat is pak hem beet een gemiddelde van 8 per uur. En dat dan * 300.000 users, dan kom je op >600 inserts per seconde.

[Bigs]

Hydra schreef op woensdag 09 december 2015 @ 16:35:
Klinkt als een aardige usecase voor iets als Cassandra voor storage en dan een proces that de summaries bijwerkt en ergens opslaat (kan ook cassandra maar ook bijvoorbeeld MySQL).

Dit is ook het eerste wat ik dacht. Maar als het project nu op het niveau 'buurjongen die wat PHP en MySQL kan' zit zou ik daar niet zomaar aan beginnen en eerst eens op zoek gaan naar ervaren ontwikkelaars (plus het bijbehorende budget).

[Multispeed]

Ger schreef op donderdag 10 december 2015 @ 09:40:
[...]

Blijkbaar is er al sprake van een huidige situatie. Wat voor DBMS zit dat in? Hoeveel data heb je inmiddels?


[...]

150 kolommen in 1 tabel? Geen indexen? Wat voor vage data praat je dan over? Is er enige relatie tussen de verschillende kolommen? Kun je niet wat gaan normaliseren?

Je praat ook over 70000 regels per user per jaar, dat is pak hem beet een gemiddelde van 8 per uur. En dat dan * 300.000 users, dan kom je op >600 inserts per seconde.

Op dit moment zijn er 10.000.000 regels aanwezig.

De enige relatie die er is, is dat een user bepaalde data heeft.

De data die opgeslagen worden zijn simpele int's. Deze data word gevuld door meters.. Deze meters gooien hun data rechtstreeks in de database.

Hierna worden aan de hand van deze getallen grafieken gegenereerd worden.

VOORBEELD:Deze data kan overigens van alles zijn. Als jij een meter maakt die kan versturen hoeveel ml koffie jij drinkt per 15 minuten, dan kan je in jou grafiek kiezen dat het hier om ml koffie gaat over een bepaalde tijd. y = ml koffie, x = tijd periode

[acemoo]

Zou je dan niet per meter een tabel kunnen maken met een koppeling naar user id?

[DeBolle]

Energieleverancier dus?

[Tjolk]

Maar als je het over 150 kolommen hebt, en 15"Kb" (kilobits??) per row, dan kom je op "simpele integers" van ruim 12 bytes per integer. MySQL heeft in ieder geval geen integer die zoveel opslag heeft. Grootste is de BIGINT met 8 bytes. Echter: je user_id kun je met max 300.000 users al uit met een MEDIUMINT van 3 bytes. En zo zullen er vast nog meer kolommen zijn die geen BIGINT nodig hebben, laat staat de vage INT type van 12 bytes groot.

Nu lijkt het misschien of dat ik zeur, maar als je hier praat over een besparing van minimaal eenderde van je opslag (8/12) en waarschijnlijk veel meer, dan praat je met jouw aantallen over HEUL VEUL GELD. En een hele andere performance ook.

En 150 meters per gebruiker? Klopt dat inderdaad? En klopt onze eerdere berekening van iedere meter die iedere 8 minuten een waarde wegschrijft?
Ook dat is relevant, want als het bijvoorbeeld iedere 15 minuten is, dan heb je het dus ook weer over de helft van waar we eerder over praatten. En tweederde van de helft van HEUL VEUL is misschien nog maar "gewoon veul", als je begrijpt wat ik bedoel.

[Multispeed]

br men schreef op donderdag 10 december 2015 @ 10:04:
Zou je dan niet per meter een tabel kunnen maken met een koppeling naar user id?

Dat zou in het geval van 300,000 users waar elke user minimaal 1 meter heeft weer >300,000 tabellen betekenen.

[Bigs]

Multispeed schreef op donderdag 10 december 2015 @ 10:14:
[...]


Dat zou in het geval van 300,000 users waar elke user minimaal 1 meter heeft weer >300,000 tabellen betekenen.

Als je dat echt meent dan zou ik snel professioneel advies gaan zoeken. Deze database moet gewoon genormaliseerd worden, dan kun je met PHP en MySQL een heel eind komen en heb je straks echt geen 1500TB data en ook geen 300,000 tabellen.

[ Voor 12% gewijzigd door Bigs op 10-12-2015 10:24 . Reden: Iets minder hard op de man, sorry ]

[Tjolk]

Multispeed schreef op donderdag 10 december 2015 @ 10:14:
[...]


Dat zou in het geval van 300,000 users waar elke user minimaal 1 meter heeft weer >300,000 tabellen betekenen.

En dat is erg want?

Je hoeft dan bij het genereren van een user-grafiek maar 1/300.000 e van je data in te lezen....

[RemcoDelft]

Multispeed schreef op donderdag 10 december 2015 @ 10:01:
VOORBEELD:Deze data kan overigens van alles zijn. Als jij een meter maakt die kan versturen hoeveel ml koffie jij drinkt per 15 minuten, dan kan je in jou grafiek kiezen dat het hier om ml koffie gaat over een bepaalde tijd. y = ml koffie, x = tijd periode

Dit voorbeeld sluit mooi aan bij mijn vorige post: ik kan me niet voorstellen dat het nuttige data is!
En zelfs als ik zou willen weten hoeveel koffie ik 5 jaar geleden op zondagochtend heb gedronken, dan ga ik dergelijke prive-data nooit uit handen geven.

[Bigs]

Inderdaad oude data som je op (verbruik voor een periode vastleggen en de meetpunten gooi je weg) of zet je om in een trend (zodat je minder meetpunten overhoudt). Individuele metingen bewaren is zelden interessant.

[Woy]

Ger schreef op donderdag 10 december 2015 @ 10:15:
[...]

En dat is erg want?

Je hoeft dan bij het genereren van een user-grafiek maar 1/300.000 e van je data in te lezen....

Maar waarom zou je daar 300.000 tabellen voor moeten maken? Je kunt ook gewoon een index/partitionering op MeterId leggen, en dan heb je hetzelfde bereikt zonder een onoverzichtelijke brei aan tabellen.

Overigens zou ik met dit soort meetgegevens toch gaan kijken naar een andere oplossing dan een SQL database, want je hebt geen complexe structuur, en bent vooral op zoek naar schaalbaarheid.

Als je bijvoorbeeld naar oplossingen zoals Azure Table Storage kijkt ( Of een van de vele vergelijkbare oplossingen ) dan kun je eenvoudig de data opslaan, en met de juiste partitionering schaalt het ook erg goed. Traditionele RDBMS'en schalen meestal niet zo goed in de breedte.

[ Voor 34% gewijzigd door Woy op 10-12-2015 11:11 ]

[acemoo]

Multispeed schreef op donderdag 10 december 2015 @ 10:14:
[...]


Dat zou in het geval van 300,000 users waar elke user minimaal 1 meter heeft weer >300,000 tabellen betekenen.

Ik zou denken 150 tabellen aangezien je 150 meters/sensoren hebt?

[Woy]

br men schreef op donderdag 10 december 2015 @ 11:10:
[...]


Ik zou denken 150 tabellen aangezien je 150 meters/sensoren hebt?

Als de structuur van de data hetzelfde is zie ik niet echt een reden om het op te splitsen in meerdere tabellen, dan maak je het IMHO alleen maar lastiger voor jezelf.

[acemoo]

Woy schreef op donderdag 10 december 2015 @ 11:12:
[...]

Als de structuur van de data hetzelfde is zie ik niet echt een reden om het op te splitsen in meerdere tabellen, dan maak je het IMHO alleen maar lastiger voor jezelf.

Dan zou je met 3 tabellen uit de weg kunnen eventueel?
tabel 1: user info
id + rest

tabel 2: sensor info
id + rest

tabel 3: sensor data
tijdstip, waarde, user_id, sensor_id

Scheelt aanzienlijk als je niet 149x een 0 waarde moet wegschrijven als int denk ik.
Maar goed, ik heb niet zo veel ervaring met databases dus ik zeg ook maar wat mij logisch lijkt.

[Woy]

br men schreef op donderdag 10 december 2015 @ 11:15:
[...]


Dan zou je met 3 tabellen uit de weg kunnen eventueel?
tabel 1: user info
id + rest

tabel 2: sensor info
id + rest

tabel 3: sensor data
tijdstip, waarde, user_id, sensor_id

Scheelt aanzienlijk als je niet 149x een 0 waarde moet wegschrijven als int denk ik.
Maar goed, ik heb niet zo veel ervaring met databases dus ik zeg ook maar wat mij logisch lijkt.

Dat lijkt mij inderdaad een prima structuur als ik de beknopte informatie van de TS goed interpreteer.
Het is inderdaad niet handig om voor elke meter een extra column aan te maken, als die niet voor alle records grotendeels gevuld zijn ( of als er regelmatig meters bij komen ).

Als je bij normaal gebruik de structuur van je tabellen vaak moet wijzigen is er meestal iets niet in orde met je ontwerp.

[CodeIT]

br men schreef op donderdag 10 december 2015 @ 11:15:
[...]


Dan zou je met 3 tabellen uit de weg kunnen eventueel?
tabel 1: user info
id + rest

tabel 2: sensor info
id + rest

tabel 3: sensor data
tijdstip, waarde, user_id, sensor_id

Scheelt aanzienlijk als je niet 149x een 0 waarde moet wegschrijven als int denk ik.
Maar goed, ik heb niet zo veel ervaring met databases dus ik zeg ook maar wat mij logisch lijkt.

Zo zou ik het ook doen (met de nodige indexes). Geen idee hoeveel data dit oplevert en hoe dit dan performed.

[RobIII]

CodeIT schreef op donderdag 10 december 2015 @ 11:18:
Geen idee hoeveel data dit oplevert

Afhankelijk van de tabelstructuur, (aantal) indexen etc. Ook hier is 't gewoon koffiedik kijken als we 't met zo weinig info moeten doen.

CodeIT schreef op donderdag 10 december 2015 @ 11:18:
en hoe dit dan performed.

Geheid beter dan 1500Tb in 1 tabel flikkeren zonder indexen of wat-dan-ook. Guaranteed.

Afhankelijk van of die data (bijv.) over landsgrenzen heen opgeslagen kan/mag worden etc. zou je eens kunnen kijken naar Keen IO o.i.d. en het hele "database" gebeuren uitbesteden.

[ Voor 17% gewijzigd door RobIII op 10-12-2015 11:26 ]

[CodeIT]

RobIII schreef op donderdag 10 december 2015 @ 11:21:
[...]

Afhankelijk van de tabelstructuur, (aantal) indexen etc. Ook hier is 't gewoon koffiedik kijken als we 't met zo weinig info moeten doen.


[...]

Geheid beter dan 1500Tb in 1 tabel flikkeren zonder indexen of wat-dan-ook. Guaranteed.

Die aannames kon ik inderdaad wel maken. Stiekem had ik dus wel een idee

[The Eagle]

Multispeed schreef op donderdag 10 december 2015 @ 10:01:
[...]


Op dit moment zijn er 10.000.000 regels aanwezig.

De enige relatie die er is, is dat een user bepaalde data heeft.

De data die opgeslagen worden zijn simpele int's. Deze data word gevuld door meters.. Deze meters gooien hun data rechtstreeks in de database.

Hierna worden aan de hand van deze getallen grafieken gegenereerd worden.

VOORBEELD:Deze data kan overigens van alles zijn. Als jij een meter maakt die kan versturen hoeveel ml koffie jij drinkt per 15 minuten, dan kan je in jou grafiek kiezen dat het hier om ml koffie gaat over een bepaalde tijd. y = ml koffie, x = tijd periode

Maar zit er structuur in of niet? Indien ja: dan kiezen tussen hbase en cassandra. Cassandra kies je meestal wanneer je read/write verhouding boven de 50% writes zit. Daaronder Hbase.
Inlezen van data: metertje laat je een JSON oid genereren, binnenlepelen met Flume en rechtstreeks in Hbase plempen
Je wilt hier echt _geen_ RDBMS voor gebruiken

[Multispeed]

Het is duidelijk, ik denk dat we het project gewoon in de steigers gaan zetten en de database toch maar flink onder handen gaan nemen.

[Tjolk]

Ik vind het eerlijk gezegd wel jammer dat je niet echt ingaat op de vragen die hier over de data gesteld worden. Niet dat we daar direct iets mee opschieten, maar er zijn hier een gebruiker of 10-15 aan het gissen om jou te helpen, een beetje info geven als daarom gevraagd wordt lijkt me dan wel zo sjiek. Het is niet dat het type integer nu heel veel weggeeft over je bedrijfsgeheim ofzo.

[Verwijderd]

Misschien is het handig om naar startups te kijken in Silicon Valley. Elke startup bouwt hun applicatie met als fundatie met lineaire schaalbaarheid. Waarom? Heel veel startups falen, maar die succesvol zijn willen zo snel mogelijk gigantisch kunnen schalen en snel.
Misschien kijken naar wat voor soort oplossingen ze daar allemaal gebruiken in de startup scène.

Ok je zult daar wat minder snel PHP aantreffen. Maar kijk vooral naar de database keuzes en wat verschillende startups voor soort data verwerken en of dat op jou soort usecase lijkt.

[Hydra]

Bigs schreef op donderdag 10 december 2015 @ 10:39:
Inderdaad oude data som je op (verbruik voor een periode vastleggen en de meetpunten gooi je weg) of zet je om in een trend (zodat je minder meetpunten overhoudt). Individuele metingen bewaren is zelden interessant.

Dat gaat lijnrecht tegen het big data denken in. Je weet over het algemeen nooit van te voren wat je precies nodig hebt. Als je dingen weg gaat gooien kun je naderhand geen extra statistieken berekenen / trends bepalen.

[Bigs]

Hydra schreef op donderdag 10 december 2015 @ 12:47:
[...]


Dat gaat lijnrecht tegen het big data denken in. Je weet over het algemeen nooit van te voren wat je precies nodig hebt. Als je dingen weg gaat gooien kun je naderhand geen extra statistieken berekenen / trends bepalen.

Klopt ja, het zogenoemde Business Data Lake. Als je het budget en de kennis hebt kun je daar zeker voor gaan, maar anders zou ik een pragmatischere aanpak adviseren om het geheel nog een beetje betaalbaar te houden. Je wilt tenslotte steeds meer meten bij steeds meer gebruikers en Krydr's Law lijkt steeds minder vast te houden voor de harde schijf fabrikanten.

[Freeaqingme]

Als het specifiek om meestanden gaat (maar zoals gezegd; het gok-gehalte ligt hoog ) kan je ook naar specifieke timeseries databses kijken.

Ik heb recentelijk mijn oog bijvoorbeeld op KairosDB laten vallen. Een fork/clone van het bekende OpenTSDB, maar dan op basis van Cassandra (ipv Hadoop). Een alternatief is dan ook bijvoorbeeld InfluxDb. Maar de clusterfunctionaliteit is nog bijzonder experimenteel.

Edit: Linkjes toegevoegd. En ik zie net dat OpenTSDB in een RC release ook experimentele Cassandra support toegevoegd heeft.

[ Voor 23% gewijzigd door Freeaqingme op 10-12-2015 13:21 ]

[The Eagle]

Hydra schreef op donderdag 10 december 2015 @ 12:47:
[...]


Dat gaat lijnrecht tegen het big data denken in. Je weet over het algemeen nooit van te voren wat je precies nodig hebt. Als je dingen weg gaat gooien kun je naderhand geen extra statistieken berekenen / trends bepalen.

Dan kun je natuurlijk ook denken aan een combi van Cassandra en Hadoop. Cassandra voor lezen, en Hadoop voor het bewaren van de post-processing data.
True, dat zou je ook gewoon jn Cassandra kunnen laten zitten, maar de vraag is of je dat obv je business case wil. Ligt aan de analyses die je wilt doen en de maniet waarop je dat doet.
Hou er tevens rekening mee dat als je predictive analytics wilt gaan doen met bijvoorbeeld R en Hadoop, je al je te analyseren data op 1 node wilt hebben. Dat is een van de downsides van Mapreduce: je brengt de code naar de data toe, en evt tussentotalen of -gemiddelden gaan over de dataset op de node. Das bij predictivity niet handig, dat wil je over al je data ineens doen

Having said that: voor een dergelijke startup zou ik voor proven technology kiezen. Je wilt gewoon weten dat je onderliggende basis goed is. Als een van de palen van je fundering rot blijkt kost je dat een hoop tijd en effort

[ Voor 9% gewijzigd door The Eagle op 10-12-2015 21:40 ]

[Kettrick]

Freeaqingme schreef op donderdag 10 december 2015 @ 13:19:
Als het specifiek om meestanden gaat (maar zoals gezegd; het gok-gehalte ligt hoog ) kan je ook naar specifieke timeseries databses kijken.

Ik heb recentelijk mijn oog bijvoorbeeld op KairosDB laten vallen. Een fork/clone van het bekende OpenTSDB, maar dan op basis van Cassandra (ipv Hadoop). Een alternatief is dan ook bijvoorbeeld InfluxDb. Maar de clusterfunctionaliteit is nog bijzonder experimenteel.

Edit: Linkjes toegevoegd. En ik zie net dat OpenTSDB in een RC release ook experimentele Cassandra support toegevoegd heeft.

Ik stond ook op het punt timeseries en ingluxdb te noemen, je eigen timeseries model op mysql of postgres uitrollen gaat je een boel tijd kosten.

[Freeaqingme]

Kettrick schreef op donderdag 10 december 2015 @ 22:26:
[...]


Ik stond ook op het punt timeseries en ingluxdb te noemen, je eigen timeseries model op mysql of postgres uitrollen gaat je een boel tijd kosten.

Speaking of which; ik werd vandaag gewezen op CitusDB, wat gebasseerd is op Postgresql. Geen ervaring mee though, maar het zou wel voor timeseriesdata bedoeld zijn.

En dan nu de vraag aan de TS; wat kan je zoal met alle reacties die je van iedereen krijgt?

[Gomez12]

Wat ik eigenlijk voornamelijk mis is een stukje planning.

Het begint met dat er over 5 jaar x data moet zijn en dat het exponentieel gegroeid kan zijn, maar het mag nu geen tijd kosten.
En het eindigt met : Project in de steigers zetten en de database onder handen nemen.
Alsof er 1 silver bullet is die al je problemen gaat oplossen (hint : die is er niet)

Wat ik nu net mis is het plan. Je kan nu niet 1 oplossing bedenken die over 5 jaar nog volstaat en in wezen is het ook niet nodig, want je problemen gaan telkens pas gaandeweg komen.
Oftewel je hebt 5 jaar de tijd om het totale probleem op te lossen door telkens deelproblemen te specificeren en die op te lossen. Alleen dat betekent 1 grote verandering in je denkwijze, want dat betekent dat er niet 1 quickfix is, maar dat je er nu tijd in moet steken en over 3 maanden weer en over 6 maanden weer en over 9 maanden weer etc. etc.

Ben je businesswise bereid om die tijd erin te steken (cq is het het waard) of ben je daartoe niet bereid, want het is heel leuk om een cassandra of hadoop of influxdb of weet ik veel wat allemaal aan te dragen, maar die kunnen over 5 jaar allemaal afgestorven en dood zijn.

Er is simpelweg geen silver bullet die je nu even kan implementeren en die je garandeert dat het over 5 jaar nog werkt, je zal het moeten bijhouden en onderhoud eraan moeten blijven plegen.

[The Eagle]

Je hebt een punt, maar je vergeet even dat Hadoop, Cassandra, Hbase en andere big data technieken al een aantal jaren bij grote jongens als Google, Apple, Microsoft etc in clistes van 2500 nodes of meer draaien. Dat flikkeren ze binnen 5 jaar echt niet zomaar buiten. Hooguit borduren ze er op voort - en dan kun jij er van profiteren

PC's kunnen over 5 jaar ook afgestorven zijn. In de jaren 80 was volgens IBM 640kb geheugen meer dan genoeg voor iedereen. Je kunt niet in de toekomst kijken, je kunt hooguit de evt risico's daarvan onderkennen. En risk mitigation gaat ook niet want je weet niet waarmee je in de toekomst kunt mitigaten. Wel weet je dat technologie van nu over 5 jaar vermoedelijk te oud zal zijn voor risk mitigation

[sig69]

150 kolommen

Hier gingen m'n haren al recht overeind staan..

[The Eagle]

Waarom? Ik deed vroeger PeopleSoft, en de voucher accounting line table daarin was standaard een veld of 75 groot, met een optie om er nog 100 velden extra bij de configureren. Kan best. En dan praat je nog over een genormailseerde tabel ook.
Je moet niet schrikken van veel kolommen. Met de juiste datapaden ( indexen etc) is er niks aan de hand.
Ter info: ben zo ook wel eens een enkele tabel tegengekomen van 80GB, alleen maar operationele data. Gaat prima.

[Tjolk]

sig69 schreef op zondag 13 december 2015 @ 02:32:
[...]

Hier gingen m'n haren al recht overeind staan..

Zolang het allemaal 1:1 gerelateerd is, heeft het weinig zin om op te splitsen lijkt me

[sig69]

The Eagle schreef op zondag 13 december 2015 @ 13:23:
Waarom? Ik deed vroeger PeopleSoft, en de voucher accounting line table daarin was standaard een veld of 75 groot, met een optie om er nog 100 velden extra bij de configureren. Kan best. En dan praat je nog over een genormailseerde tabel ook.
Je moet niet schrikken van veel kolommen. Met de juiste datapaden ( indexen etc) is er niks aan de hand.
Ter info: ben zo ook wel eens een enkele tabel tegengekomen van 80GB, alleen maar operationele data. Gaat prima.

Omdat het in mijn ervaring vaak wijst op een slecht database ontwerp. Natuurlijk zijn er gevallen waarin het prima kan, die hebben we hier ook, maar dat zijn over het algemeen uitzonderingen of bewuste ontwerpkeuzes.

Ger schreef op zondag 13 december 2015 @ 14:12:
[...]

Zolang het allemaal 1:1 gerelateerd is, heeft het weinig zin om op te splitsen lijkt me

Tuurlijk dat klopt. Als ik de (weinige) informatie lees die hier gegeven wordt lijkt me dat echter niet het geval.

[Gomez12]

sig69 schreef op dinsdag 15 december 2015 @ 09:32:
[...]

Omdat het in mijn ervaring vaak wijst op een slecht database ontwerp. Natuurlijk zijn er gevallen waarin het prima kan, die hebben we hier ook, maar dat zijn over het algemeen uitzonderingen of bewuste ontwerpkeuzes.

Het is ook deels afhankelijk van wat het doet, wil je gegarandeerde verwerking en weet je dat je rustige periodes hebt (bijv 's nachts) dan voer ik vaak genoeg gewoon een queue-tabel toe die gewoon blind zonder indexen of wat dan ook alleen maar de aangevoerde info opslaat zodat die ACID opgeslagen is, een background-proces trekt dan uit die tabel de data en vormt deze om naar andere tabellen / opslagen / dbases alleen dit is dan een relatief duur proces wat best kan voorkomen dat het de aanvoer niet kan bijbenen (hence de queue-tabel met xxx kolommen)