[PHP/MYSQL]Max. aantal bereikt. Kan geen insert meer doen*

[Verwijderd]

Mischien kan iemand mij helpen.

Ik heb een database in mysql.

gw_id int(11) auto_increment
sw_id int(11)
gw_rank varchar(255)
gw_name varchar(255)
gw_score varchar(255)
gw_min varchar(255)
gw_sec varchar(255)

En een php applicatie.

Wat het doet is als volgend. Ik query om de minuut een aantal gameservers. Deze data sla ik op in mijn database zodat ik later kan zien waar bepaalde gamers zich bevinden en welke servers zij intressant vinden.

Echter zal dit veel records in mijn database genereren.

Toen ik deze week naar mijn database keek had die in tussen +- 4.7 miljoen records. Wat mij wel opviel is dat de database niet verder gevuld werdt. Ik heb zelf niets aan mijn script veranderd en vond dat vreemd.

Nou heb ik nagedacht over die 4.7 miljoen records dit is precies de maximale van een 32 bit integer.

Ik heb gezocht over dit probleem. Maar kom niet echt verder. Een optie wat ik heb gezien is dat ik van een INT ook nog een BIGINT kan maken. Maar voordat ik mijn database omzeep help zou ik eerst willen weten of ik dit kan doen zonder dat ik data verliest of mijn machiene in de stres jaagt. Of dat ik eerst naar mijn php script moet kijken. Dat ik daar mijn variable anders moet declareren.

Mischien heeft iemand hier zelfde soort problemen gehad.

[pjvandesande]

Ik denk dat normalisatie voor jou de sluitel is.
[search=normalisatie]

[ Voor 20% gewijzigd door pjvandesande op 16-04-2004 11:13 ]

[curry684]

*!*!* Over topictitels in P&W - Updated 25 feb 04 *!*!*

Wil je aub even via topic report een titel voorstellen?

[whoami]

questa schreef op 16 april 2004 @ 11:12:
Ik denk dat normalisatie voor jou de sluitel is.
[search=normalisatie]

Dat zal er niet veel mee te maken hebben in dit geval.
Je kan ook in een genormaliseerd datamodel aan de limiet van een datatype komen.
De TS heeft gewoon veel records ( je kan je trouwens afvragen of het nodig is om iedere minuut te gaan 'pollen').

Je kan het datatype in je DB veranderen zonder data-verlies, maar je moet er dan ook wel voor zorgen dat je PHP script zo'n grote getallen aankan. Daar zal je dus ws ook nog een ander data-type moeten gebruiken.

[Verwijderd]

Ik heb zo net een ALTER gedaan om mijn database. Hij is er erug druk mee. De sysload is op max. Ik ga ook even op php.net zoeken naar een manier om meer dat een 32 bit integer te adresseren

[__fred__]

Het maximum aantal records bij een 32 bit unsigned integer als primary key is niet 4,7 miljoen maar 4.294.967.296 (4,3 miljard). Je loopt waarschijnlijk tegen andere beperkingen aan.
Logischer beperkingen zijn:
* De maximale executietijd van een PHP script
* Het maximale geheugen gebruik van een PHP script
* De maximale executietijd van een query op de MySQL server.

Ik denk dat je in die richting moet zoeken, 4,7 miljoen records is nog geen probleem voor MySQL met 32 bit INTs. upgraden naar 64 bit ints is trouwens geen probleem, alleen denk ik niet dat het iets gaat oplossen.

NOTE: PHP SUPPORT ALLEEN 32 bits SIGNED integers. Voor getallen groter dan 2^31 gebruikt PHP dus floats en kan niet meer GEGARANDEERD worden dat primary key waarden uniek zijn. ik zou dus sowieso afraden om getallen groter dan 32bits als key te gebruiken. (Brak taaltje he ;-))

[ Voor 20% gewijzigd door __fred__ op 16-04-2004 11:29 ]

[Ritch]

De ints unsigned maken kan ook geen kwaad natuurlijk, scheelt ook een factor 2....

[Verwijderd]

Mijn database is nu ge-ALTERT naar een BIT-INT. En dat heeft het probleem opgelost. Het script loopt nu weer lekker door.

Bedankt voor jullie reacties.

[Verwijderd]

De ID wordt in het script ook niet als betrouwbaar geacht. De meeste query's die ik doe is op servernaam en op datum/tijd.

__fred__ schreef op 16 april 2004 @ 11:22:

NOTE: PHP SUPPORT ALLEEN 32 bits SIGNED integers. Voor getallen groter dan 2^31 gebruikt PHP dus floats en kan niet meer GEGARANDEERD worden dat primary key waarden uniek zijn. ik zou dus sowieso afraden om getallen groter dan 32bits als key te gebruiken. (Brak taaltje he ;-))

[pjvandesande]

whoami schreef op 16 april 2004 @ 11:15:
Dat zal er niet veel mee te maken hebben in dit geval.

Ik las dit even verkeerd:

Verwijderd schreef op 16 april 2004 @ 11:08:
Toen ik deze week naar mijn database keek had die in tussen +- 4.7 miljoen records.

Ik dacht te lezen dat hij na een week als zoveel data had

[Verwijderd]

Hij verzameld ongeveer 150.000 records perdag. Ik heb een appart scriptje om de database op te schonen. Ik ga me nu bezig houden met indexen.

[Macros]

Volgens mij kan je beter loggen wanneer iemand een server joined en wanneer hij hem verlaat. Dan kan je elke 30 sec pollen om veranderingen te vinden en alleen die veranderingen opslaan.
Maar ja... ik ben maar een informatica student die van niets weet.

[flexje]

Ik neem aan dat de gameservers van jou zijn?
Volgens mij maken dedicated gameservers namelijk standaard al log files aan, misschien dat je daar gebruik van kan maken ipv een database?

[Verwijderd]

Ik het met je eens als je de server zelf beheerd kan je de logging aan zetten en deze vervolgens parcen. Maar ik zelf heb maar 1 server. En de andere 20 servers beheer ik niet waardoor ik ook geen invloed heb op de logging. Vandaar dat ik het zo heb opgelost.

[Verwijderd]

Dat ben ik met je eens. Als je het precies wilt weten moet je eigenlijk realtime monitoren. Ik ben zelf van mening mensen die minder dan een minuut hebben geconnect zullen niet echt gespeeld hebben. En voor mij dus ook niet intresant.

Macros schreef op 16 april 2004 @ 14:17:
Volgens mij kan je beter loggen wanneer iemand een server joined en wanneer hij hem verlaat. Dan kan je elke 30 sec pollen om veranderingen te vinden en alleen die veranderingen opslaan.
Maar ja... ik ben maar een informatica student die van niets weet.

[flexje]

Heb je Qstat al eens geprobeerd? Kan het zelfs in XML's gooien

[Verwijderd]

Ik gebruik qstat onderwater om de data te collecten. Dit is bijvoorbeeld een ander script dat ik gemaakt heb die dat ook doet http://www.fragzone.nl/index.php3?page=online_info

[LinuX-TUX]

Ik wil weten van die getallen, die ID's, wat is de laatste? Toevallig in de richting van 127/128 of 255/256 ?

Als dat het geval is, gewoon even een big_int van maken om te proberen, gaat ie echt niet van om zeep. (mits je hem wel 11 lang houd natuurlijk)

edit:
Woei, even dat van 4.7 miljoen over het hoofd gezien

Dan nog steeds zijn we wel geinteresseerd in wat het hoogste getal is

[ Voor 24% gewijzigd door LinuX-TUX op 16-04-2004 15:14 ]

[jurri@n]

Waarom gebruik je een integer als ID? Waarom maak je geen samengesteld id van de servernaam + datum/tijd?

[Verwijderd]

Dit is mijn laatste autoincrement ID 4798391

En het worden er snel steeds meer.

LinuX-TUX schreef op 16 april 2004 @ 15:13:
Ik wil weten van die getallen, die ID's, wat is de laatste? Toevallig in de richting van 127/128 of 255/256 ?

Als dat het geval is, gewoon even een big_int van maken om te proberen, gaat ie echt niet van om zeep. (mits je hem wel 11 lang houd natuurlijk)

edit:
Woei, even dat van 4.7 miljoen over het hoofd gezien

Dan nog steeds zijn we wel geinteresseerd in wat het hoogste getal is

[Verwijderd]

Ik zal eerlijk zeggen dat ik dit niet uit deze hoek heb bekeken. Ik heb een database model gemaakt waarbij ik bepaalde gegevens dat deze in een tabel gezet en een ID (autoincrement) er bij gezet op de records uniq te maken.

Ik ben het met je eens dat een servernaam/datum/tijd in de meeste wel zou werken. Het enige probleem is dat de servernaam weleens wijzigd. En dat er situatie kan ontstaan waarbij er 2 server met de zelfde naam in de database verscheinen. Endaardoor niet uniq kunnen zijn. De server quering gaat multi threding.

Ik hoop dat ik het duidelijk uitleg.

jurri@n schreef op 16 april 2004 @ 15:14:
Waarom gebruik je een integer als ID? Waarom maak je geen samengesteld id van de servernaam + datum/tijd?