Wat als er een tabel vol is?
Ik ben bezig met een app met een mysql database er achter en dit wil ik graag groots opzetten. Nou is het nu nog wat voorbarig maar toch vraag ik het volgende mij af:
- Wat nou als er een tabel vol zit?
Ik weet dat een tabel van bigint(10) iets van 4 bilion records kan bezitten en dit neemt ook onwijs veel ruimte met zich mee. Maar ik ben nu een afweging aan het maken of ik sommige dingen in dezelfde tabel zal stoppen of dat ik voor sommige dingen een aparte tabel maak en dit koppel met een id.
Wanneer ik overal een eigen tabel voor maak kan ik per onderdeel iets van 4 bilion records gebruiken maar als ik het combineer kan ik in totaal 4 bilion records gebruiken.
Is het logisch dat als een tabel vol zit dat je een nieuwe tabel maakt en deze aan elkaar joint? Hoe doet facebook dat bijvoorbeeld? Ik neem aan dat zij een tabel hebben met reacties en per reactie een id dat weer gekoppeld is aan het id van een bericht. Maar zij zullen echt de quota al wel bereikt hebben.
Ik hoor graag of iemand hier iets vanaf weet. Ben er nieuwsgierig naar en kan het niet echt vinden op het internet.
Bij bijvoorbeeld Facebook zal geen id gebruikt worden maar een UUID En tevens hebben ze bij facebook hele andere problemen met de database om te zorgen dat de data bijna realtime gelijk blijft op de verschillende servers.
Tenzij je nu al zeker weet dat je met absurd grote hoeveelheden te maken hebt is het beter om daar nu nog geen rekening mee houden. Om daar wel rekening mee te houden maakt het meteen complexer en als het wel zo groot is kun je die onderdelen refactoren. (Als je structuur in orde is betekent dit niet dat je veel moet herschrijven)
1.000.000.000 / 60 sec /60 min /24 uur /365 dagen = 31.7 jaar
dus als je elke seconde dag en nacht 24/7 een record insert, ben je over 31 jaar bijna vol.
Ik denk dat je probleem eerder gaat liggen in te weinig hd ruimte. En dan heeft een tweede tabel ook geen zin want die staat zonder extreme maatregelen op dezelfde harde schijf.
De premisse klopt dus al niet, laten we het daarop houden.
Gewijzigd op 04/07/2017 12:58:52 door Ben van Velzen
Voor een signed integer wel maar voor een unsigned integer niet.
Signed: -2147483648 t/m 2147483647
Unsigned: 0 t/m 4294967295
Veel staat of valt met het ontwerp van de database.
Het ontwerp hangt op zijn beurt weer af van het gedrag en de werking van de applicatie.
Quote:
Is het logisch dat als een tabel vol zit dat je een nieuwe tabel maakt en deze aan elkaar joint?
Dat denk ik niet. Dit klinkt eerder als het niet rekening houden met groei/schaalbaarheid. Een oplossing waarbij je er maar een tabel aan vastknoopt is op de (middel)lange termijn waarschijnlijk ook een tijdelijke oplossing want het oorspronkelijke probleem blijft, wat op zijn beurt een sterke indicatie kan zijn dat je dit niet hebt ondervangen in het ontwerp.
Maar even on topic:
Een database bestaat uit meerdere tabellen. een tabel kan weer bestaan uit meerdere bestanden. De oplossingen die te bedenken zijn voor dataopslag en een vlotte response-tijd zijn eindeloos en er zijn boeken vol over geschreven. Wat dat betreft is er geen standaard oplossing op een vraag als deze. Maar (ik haal even mijn schouders op) ga je nu dan ook direct investeren in een serverpark en een groep ict-ers die deze servers gaan beheren? Waarschijnlijk niet :-) dus waarom zou je nu al allerlei bokkensprongen maken terwijl je die nog lang niet nodig hebt, als je ze überhaupt al ooit nodig hebt. Logischer klinkt het om met je gebruikers/requests mee te groeien. Iets dat prima kan, zeker wanneer je in de basis goed begonnen bent, namelijk zoals TJVB oppert een goed genormaliseerde database (wat is een goed normaliseerde database?) en goede code waarin rekening is gehouden met "Separation of concerns".
>> Ik weet dat een tabel van bigint(10) iets van 4 bilion records kan bezitten
Ivo P op 04/07/2017 12:08:36:
1.000.000.000 / 60 sec /60 min /24 uur /365 dagen = 31.7 jaar
dus als je elke seconde dag en nacht 24/7 een record insert, ben je over 31 jaar bijna vol.
dus als je elke seconde dag en nacht 24/7 een record insert, ben je over 31 jaar bijna vol.
Een van de databases die ik beheer vergaart gemiddeld 67 records per seconde. Dan heb je dat miljard al met een maand of zes te pakken. ;-)
Zoals ik al zei ben ik er erg nieuwsgierig naar hoe snel je een limiet binnen mysql bereikt en hoe je hier dan weer mee om kan gaan. Ik begrijp dat ik het nu nog niet groots kan opzetten omdat ik daar het geld en de middelen niet voor heb en dit nu ook nog lang niet nodig is en misschien ook wel nooit.
Maar toch hou ik nu al graag rekening met het feit dat het groots kan worden zodat als het ooit zal gebeuren ik niet al direct met de handen in het haar zit. "Had ik het maar zo aangepakt".
Er komt ook een tijdlijn functie in met reacties en likes e.d. en dit kan zomaar snel lopen als je veel gebruikers hebt.
Maar goed om te horen dat mensen hier zeggen dat ik me er nog geen zorgen over hoef te maken.
Gewijzigd op 04/07/2017 22:06:13 door Danny von Gaal
Danny von Gaal op 04/07/2017 22:05:09:
Er komt ook een tijdlijn functie in met reacties en likes e.d. en dit kan zomaar snel lopen als je veel gebruikers hebt.
Maar goed om te horen dat mensen hier zeggen dat ik me er nog geen zorgen over hoef te maken.
Maar goed om te horen dat mensen hier zeggen dat ik me er nog geen zorgen over hoef te maken.
Ik heb voor de gein even zitten rekenen. Na 7,5 jaar staat de autoincrement-teller van mijn tabel op 15,5 miljard. Als het in dit tempo doorgaat, duurt het bijna 9 miljard jaar voor mijn teller is volgelopen. Dan is de zon al ongeveer 4 miljard jaar uitgedoofd. ;-)
Over het tellertje hoef je je in ieder geval geen zorgen te maken. Met dit soort aantallen records kan het dan weer wel een dingetje worden om de performance van je database een beetje acceptabel te houden. Maar gelukkig is (gemiddeld) 67 records per seconde best veel, zelfs als je een ontzettend drukke timeline zou hebben.