DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Ik heb de twee query's getest met het volgende resultaat (uiteraard SQL_NO_CACHE toegevoegd):
Jouw query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 0.8366 sec)
Mijn query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 4.1594 sec)
Die van jou is een stuk sneller. Ik ga even testen over langere periodes. Als dit goed werkt kan ik dit beter gebruiken dan de PHP oplossing.
[ Bericht 7% gewijzigd door bondage op 26-04-2014 18:18:21 ]
Jouw query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 0.8366 sec)
| 1 2 3 4 | id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE search_user_post ref topicid,tijdstip,auteur,year auteur 4 const 12009 Using where; Using temporary; Using filesort 1 SIMPLE friend_post ref topicid,auteur topicid 4 fokstats.search_user_post.topicid 100 Using where 1 SIMPLE u eq_ref PRIMARY PRIMARY 4 fokstats.friend_post.auteur 1 |
Mijn query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 4.1594 sec)
| 1 2 3 4 5 6 | id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY <derived2> ALL NULL NULL NULL NULL 2919 Using temporary; Using filesort 2 DERIVED <derived3> ALL NULL NULL NULL NULL 110 Using temporary; Using filesort 2 DERIVED fok_post ref topicid,auteur topicid 4 t.topicid 100 Using where 2 DERIVED fok_user eq_ref PRIMARY PRIMARY 4 fokstats.fok_post.auteur 1 3 DERIVED fok_post ref tijdstip,auteur,year auteur 4 12008 Using where; Using temporary |
Die van jou is een stuk sneller. Ik ga even testen over langere periodes. Als dit goed werkt kan ik dit beter gebruiken dan de PHP oplossing.
[ Bericht 7% gewijzigd door bondage op 26-04-2014 18:18:21 ]
Is het niet sowieso handiger om zoveel mogelijk het ophalen van de juiste data door een database engine te laten doen ipv dat ik PHP na te gaan bootsen? De database engine zal hierin bijna altijd sneller zijn, tenzij je 10 subqueries ofzo gebruikt.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
De rest van de stats worden gegenereerd door Sphinx, echter heeft Sphinx niet de mogelijkheid om op meerdere velden te groeperen. Als ik dit volledig in Sphinx zou kunnen doen zou het een stuk sneller gaan.quote:Op maandag 28 april 2014 09:40 schreef Sitethief het volgende:
Is het niet sowieso handiger om zoveel mogelijk het ophalen van de juiste data door een database engine te laten doen ipv dat ik PHP na te gaan bootsen? De database engine zal hierin bijna altijd sneller zijn, tenzij je 10 subqueries ofzo gebruikt.
Maar ik realiseer me nu dat ik dit beter op kan lossen dmv een query ipv de data door php te laten verwerken.
Een andere optie is een betere server aanschaffen, daar heb ik echter op dit moment geen geld voor
Voer je die query uit op een 'eigen' server? Als in een database-server die je zelf beheert en waar je indexen kunt aanpassen? Dan moet er nog wel wat snelheidswinst te behalen zijn.quote:Op maandag 28 april 2014 10:27 schreef bondage het volgende:
[..]
De rest van de stats worden gegenereerd door Sphinx, echter heeft Sphinx niet de mogelijkheid om op meerdere velden te groeperen. Als ik dit volledig in Sphinx zou kunnen doen zou het een stuk sneller gaan.
Maar ik realiseer me nu dat ik dit beter op kan lossen dmv een query ipv de data door php te laten verwerken.
Een andere optie is een betere server aanschaffen, daar heb ik echter op dit moment geen geld voor
Jup, is mijn eigen server. Dit zijn de velden en indexen die ik momenteel heb:quote:
[..]
Voer je die query uit op een 'eigen' server? Als in een database-server die je zelf beheert en waar je indexen kunt aanpassen? Dan moet er nog wel wat snelheidswinst te behalen zijn.
Hmm... year heeft een kardinaliteit van 1. Heb je alleen posts uit 2014 in de database staan?quote:Op maandag 28 april 2014 22:54 schreef bondage het volgende:
[..]
Jup, is mijn eigen server. Dit zijn de velden en indexen die ik momenteel heb:
[ afbeelding ]
[ afbeelding ]
Dat viel mij ook al op idd. Er staat 6 jaar aan data in die tabel.quote:
[..]
Hmm... year heeft een kardinaliteit van 1. Heb je alleen posts uit 2014 in de database staan?
Is het overigens erg dat id een int(15) is? Ik heb deze database ooit van iemand overgenomen en hier niet bij stilgestaan, ik weet echter dat een gewone int niet tot 15 gaat.
Mooiquote:
[..]
Dat viel mij ook al op idd. Er staat 6 jaar aan data in die tabel.
Dan zou ik de index "auteur" wijzigen en er "year" als tweede kolom aan toevoegen. Een index mag namelijk meer dan 1 kolom bevatten (Je zou ook nog in plaats van "year" de kolom "tijdstip" kunnen toevoegen, maar ik vermoed dat het verschil vrij klein is terwijl de index veel groter kan worden.)
Nee, dat getal maakt alleen uit als je zerofill gebruikt. En dat wil je niet (want voorloopnullen toevoegen hoort de database niet te doen).quote:Is het overigens erg dat id een int(15) is? Ik heb deze database ooit van iemand overgenomen en hier niet bij stilgestaan, ik weet echter dat een gewone int niet tot 15 gaat.
Dank, ik ga die twee indices even combineren en de query dan nogmaals testen. Ik gebruik geen zerofill dus dat is dan geen probleem gelukkig.quote:
[..]
Mooi
(Je zou ook nog in plaats van "year" de kolom "tijdstip" kunnen toevoegen, maar ik vermoed dat het verschil vrij klein is terwijl de index veel groter kan worden.)
[..]
Nee, dat getal maakt alleen uit als je zerofill gebruikt. En dat wil je niet (want voorloopnullen toevoegen hoort de database niet te doen).
Wat is eigenlijk het voordeel van het combineren van die twee?
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Als ik year uit de query haal en vervolgens dit jaar uitdraai duurt de query een stuk langer dan met year erin. Blijkbaar heeft de index voor dat veld wel effect. Ik had het primair toegevoegd voor het indexeringsproces omdat er per jaar een losse Sphinx index wordt gemaakt, op deze manier hoeft niet steeds alle data opnieuw verwerkt te worden. Dmv het year veld en bijbehorende index is ook die query een stuk sneller.quote:
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Dan wil je wel heel zeker weten dat er een index op (auteur, tijdstip) wordt gebruikt. En ik weet niet hoe goed MySQL omgaat met een index die als range wordt gebruikt (BETWEEN) in combinatie met een andere index. Hoe beperkter het resultaat van een index is, hoe beter.quote:
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Je maakt het MySQL op die manier makkelijker om twee kolommen te gebruiken in een index, waardoor de resultaatset kleiner wordt. En dat helpt weer om de snelheid omhoog te krijgenquote:
[..]
Dank, ik ga die twee indices even combineren en de query dan nogmaals testen. Ik gebruik geen zerofill dus dat is dan geen probleem gelukkig.
Wat is eigenlijk het voordeel van het combineren van die twee?
MySQL wordt ook wel beter in het combineren van twee losse indexen, maar dat levert volgens mij nog niet hetzelfde resultaat op.Overigens is een index op (auteur, year) ook nog steeds te gebruiken als index op auteur maar het is niet te gebruiken als index op year. Als je die ook los nodig hebt, moet je daar dus een aparte index voor maken / houden.
Duidelijk.quote:
[..]
Je maakt het MySQL op die manier makkelijker om twee kolommen te gebruiken in een index, waardoor de resultaatset kleiner wordt. En dat helpt weer om de snelheid omhoog te krijgen
Overigens is een index op (auteur, year) ook nog steeds te gebruiken als index op auteur maar het is niet te gebruiken als index op year. Als je die ook los nodig hebt, moet je daar dus een aparte index voor maken / houden.
En de year index heb ik inderdaad nodig aangezien die ook in de query van de Sphinx indexer wordt gebruikt. Ik ga nu de bestaande index op auteur verwijderen en van year en auteur een gecombineerde index maken. De losse year index laat ik gewoon staan. Ik post straks de resultaten incl. de output van EXPLAIN. Het aanpassen van de index gaat wel ff duren aangezien het om een erg grote tabel gaat.
Edit: ik kan blijkbaar de bestaande auteur index gewoon wijzigen. Heb year toegevoegd, de server is nu ff bezig.
Omdat ik soms zo loop te miepen over tests:
In theory there is no difference between theory and practice. In practice there is.
quote:
Omdat ik soms zo loop te miepen over tests:
[ afbeelding ]
Wat moet dit voorstellen
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammenquote:
)[ Bericht 17% gewijzigd door slacker_nl op 30-04-2014 17:58:32 ]
In theory there is no difference between theory and practice. In practice there is.
Ziet er wel leuk uit, die statistiekenquote:
[..]
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammen
Maar wat is er zo bijzonder aan die test met als time 85.9? Die duurt wel erg lang.
Dat is 000-package.t, daarin worden de volgende zaken getest:quote:
[..]
Ziet er wel leuk uit, die statistieken
Maar wat is er zo bijzonder aan die test met als time 85.9? Die duurt wel erg lang.
1) MANIFEST file ok
2) Modules compilen ok
3) POD (documentatie) syntax ok
4) POD coverage ok (dus doc je ook al je functies)
5) Compilen je scripts ok
Die duren wat langer, echt niet zo spannend allemaal. Dat zijn eigenlijk release-only tests.
In theory there is no difference between theory and practice. In practice there is.
Dan snap ik wel dat die tests ook lang duren (in ieder geval in verhouding).quote:
[..]
Dat is 000-package.t, daarin worden de volgende zaken getest:
1) MANIFEST file ok
2) Modules compilen ok
3) POD (documentatie) syntax ok
4) POD coverage ok (dus doc je ook al je functies)
5) Compilen je scripts ok
Die duren wat langer, echt niet zo spannend allemaal. Dat zijn eigenlijk release-only tests.
Hmm, de query is met deze nieuwe index trager geworden. Hij duurde eerst 0,83 seconden, nu 3,46. Ik heb exact dezelfde parameters gebruikt als de vorige keer toen de indices nog niet gecombineerd waren.
Dit is de explain:
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
FORCE INDEX gebruiken misschien?
Dit is de explain:
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | SELECT count(DISTINCT friend_post.topicid) cnt, u.naam FROM fok_user u INNER JOIN fok_post search_user_post ON search_user_post.auteur = 128465 AND search_user_post.tijdstip BETWEEN UNIX_TIMESTAMP('2014-04-01 00:00:01') AND UNIX_TIMESTAMP('2014-04-26 23:59:59') AND search_user_post.year = 2014 INNER JOIN fok_post friend_post ON friend_post.auteur = u.id AND friend_post.auteur != 128465 AND friend_post.topicid = search_user_post.topicid GROUP BY u.naam ORDER BY cnt DESC LIMIT 100; |
FORCE INDEX gebruiken misschien?
Hmm... da's wel onverwacht... het (geschatte) aantal rijen voor de eerste query gaat van 12.000 naar 2.400 en toch is de query veel trager...quote:
Hmm, de query is met deze nieuwe index trager geworden. Hij duurde eerst 0,83 seconden, nu 3,46. Ik heb exact dezelfde parameters gebruikt als de vorige keer toen de indices nog niet gecombineerd waren.
Dit is de explain:
[ afbeelding ]
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
[ code verwijderd ]
FORCE INDEX gebruiken misschien?
Jup, ik snap er ook niets vanquote:
[..]
Hmm... da's wel onverwacht... het (geschatte) aantal rijen voor de eerste query gaat van 12.000 naar 2.400 en toch is de query veel trager...
Ik ga voor de zekerheid toch ff FORCE INDEX proberen.
Ik kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt.quote:
[..]
Jup, ik snap er ook niets van
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?quote:
[..]
Ik kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt.
Dat lijkt me niet nuttig, in ieder geval niet in die volgorde.quote:
[..]
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?
Heeft de table collation invloed op de gegevens die in de velden staat? Stel dat de table collation op latin1_swedish_ci staat maar de velden in de tabel op utf8_unicode_ci, heeft dit dan gevolgen?
De documentatie zegt hier het volgende over:
De documentatie zegt hier het volgende over:
Dit doet mij vermoeden dat het alleen om een standaardwaarde gaat en dit verder geen invloed heeft op de data in de tabel.quote:The table character set and collation are used as default values for column definitions if the column character set and collation are not specified in individual column definitions. The table character set and collation are MySQL extensions; there are no such things in standard SQL.
