Database inrichting
Ik ben bezig met wat educatie voor mezelf:
Ik probeer een gigantische database aan te leggen, waarin miljoenen rijen komen te staan. Natuurlijk kon ik niets vinden waarmee ik men database eens goed kon vullen, dus heb ik maar voor md5 hashes gekozen.
Nu is het dat een script constant hashes en de betekenissen daarvan toevoegt aan een tabel die de naam heeft van de eerste 3 karakters van de hash, bijvoorbeeld:
H_a3b
H_Gd@
Hierdoor worden er precies 4096 tabellen aangemaakt.
De sql van de tabel is zo gemaakt:
CREATE TABLE IF NOT EXISTS `tabelnaam` (
`id` int(30) NOT NULL AUTO_INCREMENT,
`base` varchar(50) NOT NULL,
`hash` varchar(40) NOT NULL,
PRIMARY KEY (`id`),
FULLTEXT KEY `base` (`base`),
FULLTEXT KEY `hash` (`hash`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
Hierdoor worden de miljoenen hashes opgesplitst, en is het tot nu toe sneller met zoeken. Want als iemand een hash opvraagt, neemt het script gewoon de eerste 3 karakters van de hash, en weet daardoor gelijk de tabelnaam waarin gezocht moet worden.
Mijn vraag: Is dit een goede aanpak als het gaat om het snel opzoeken van de betekenis van hashes?
Andere vraag: Kan een database op deze manier nog snel werken, als er per 20 seconden 1000 rijen worden toegevoegd?
Gewijzigd op 22/11/2010 20:47:26 door Gerben pHp
is er dan niet iets mis? xo
Als je het uitrekend, is het mijn verwachte aantal tabellen:
een md5 hash is hexadecimaal (16 tekens, ipv 10)
16 ^3 = 16 x 16 x 16 = 4096
Gewijzigd op 22/11/2010 21:09:43 door Gerben pHp
Het kan zijn dat ik verkeerd ben... ga anders even normaliseren.
nouja, ik heb inmiddels miljoenen hashes in de database, en nog kan ik de hash binnen minder dan 1 seconde vinden :O
als de pagina 1 seconde langer moet laden wordt het toch wel lang hoor