[PHP/(My)SQL] voor dummies #119

Index

» digital corner

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_147189834
quote:
14s.gif Op maandag 1 december 2014 17:24 schreef KomtTijd... het volgende:
als je gewoon een query maakt met LIMIT(0,100), dan heb je dat toch?
En een ORDER BY ID voor het geval dat niet de default is.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  Moderator / Redactie Sport maandag 1 december 2014 @ 17:27:26 #152
359864 crew  Nattekat
De roze zeekat
pi_147189904
quote:
0s.gif Op maandag 1 december 2014 17:24 schreef Monolith het volgende:

[..]

Je wilt dus gewoon 'de eerste 100' hebben?
quote:
14s.gif Op maandag 1 december 2014 17:24 schreef KomtTijd... het volgende:
als je gewoon een query maakt met LIMIT(0,100), dan heb je dat toch?
Het probleem daarmee is dat er dan onnodige gegevens behouden blijven, en dat is niet wat ik wil bereiken.
100.000 katjes
Fuck the EBU!
pi_147189937
quote:
0s.gif Op maandag 1 december 2014 17:27 schreef Nattekat het volgende:

[..]

[..]

Het probleem daarmee is dat er dan onnodige gegevens behouden blijven, en dat is niet wat ik wil bereiken.
Welke onnodige gegevens blijven er behouden?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_147189971
Ik ben altijd groot voorstander van het zoveel mogelijk bewaren van (onnodige) gegevens. Waarom weggooien als je er geen last van hebt.
zcflevo.nl
pi_147190693
quote:
14s.gif Op maandag 1 december 2014 17:28 schreef KomtTijd... het volgende:
Ik ben altijd groot voorstander van het zoveel mogelijk bewaren van (onnodige) gegevens. Waarom weggooien als je er geen last van hebt.
Inderdaad. :7

Vooral in een database waar alles toch netjes gestructureerd is.
pi_147191405
quote:
9s.gif Op maandag 1 december 2014 17:14 schreef KomtTijd... het volgende:
Goftedomme zeg. Moet ineens hals over kop wat klussen aan een oude applicatie (die er over een paar maanden hopelijk uit gaat), blijkt gewoon 3 kwart van de tabellen geen enkele index te hebben. Goh, dus daarom duren de queries een halve seconde :')
:D Ik ben altijd wel blij als het zo iets banaals is, klik klik klik, klaar.
  Moderator / Redactie Sport maandag 1 december 2014 @ 18:11:40 #157
359864 crew  Nattekat
De roze zeekat
pi_147191483
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.

Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
100.000 katjes
Fuck the EBU!
pi_147191502
quote:
0s.gif Op maandag 1 december 2014 18:11 schreef Nattekat het volgende:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.

Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Je data kun je super makkelijk selecteren met query's, dus de hoeveelheid maakt niet zoveel uit. :)
pi_147191504
quote:
0s.gif Op maandag 1 december 2014 18:11 schreef Nattekat het volgende:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.

Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Gewoon softdeleten, heeft bij mij vaak ook de voorkeur boven verwijderen.
pi_147191736
quote:
19s.gif Op maandag 1 december 2014 18:09 schreef TwenteFC het volgende:

[..]

:D Ik ben altijd wel blij als het zo iets banaals is, klik klik klik, klaar.
Dat wel ja. Gelukkig loop ik nog tegen genoeg andere problemen aan om dat weer te compenseren ;(

quote:
0s.gif Op maandag 1 december 2014 18:11 schreef Nattekat het volgende:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.

Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Het is ook niet de bedoeling dat je dagelijks via database-management tools in de database gaat kijken of je data er niet slordig uit ziet. Databases zijn er niet om er netjes uit te zien, daar heb je je queries voor.

Dit moet ik mijn baas ook nog wel eens uitleggen ;(
zcflevo.nl
pi_147193003
quote:
14s.gif Op maandag 1 december 2014 18:19 schreef KomtTijd... het volgende:

[..]

Dat wel ja. Gelukkig loop ik nog tegen genoeg andere problemen aan om dat weer te compenseren ;(

[..]

Het is ook niet de bedoeling dat je dagelijks via database-management tools in de database gaat kijken of je data er niet slordig uit ziet. Databases zijn er niet om er netjes uit te zien, daar heb je je queries voor.

Dit moet ik mijn baas ook nog wel eens uitleggen ;(
Nou ja, het kan natuurlijk wel degelijk voor traagheid zorgen wanneer overbodige data niet wordt opgeruimd.
Zeker bij grotere hoeveelheden data wordt archiveren of aggregeren op een gegeven moment gewoon noodzaak.


Het voordeel van niet verwijderen maar bijvoorbeeld met een deleted flag te werken is dan weer dat je de data gewoon weer zichtbaar kunt maken.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_147423157
Wat is nou een relaxte databasetool voor als je PHPMyAdmin zat begint te raken?

Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk).

[ Bericht 48% gewijzigd door KomtTijd... op 09-12-2014 15:41:18 ]
zcflevo.nl
pi_147423856
quote:
14s.gif Op dinsdag 9 december 2014 15:20 schreef KomtTijd... het volgende:
Wat is nou een relaxte databasetool voor als je PHPMyAdmin zat begint te raken?

Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk).
Gewoon MySQL workbench?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  dinsdag 9 december 2014 @ 15:51:59 #164
63192 ursel
"Het Is Hier Fantastisch!
pi_147424117
werk thuis met sqlYog
  dinsdag 9 december 2014 @ 15:57:41 #165
178193 Juicyhil
Bekende FOK!ker
pi_147424308
quote:
0s.gif Op dinsdag 9 december 2014 15:44 schreef Monolith het volgende:

[..]

Gewoon MySQL workbench?
Alleen jammer dat het zo'n vreselijk trage en buggy applicatie is. Vind Sequel Pro ook wel fijn werken ^O^
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
pi_147424798
Ik kom er net achter dat PhpStorm ook een ingebouwde DB manager heeft. Ga ik ook eens proberen.
zcflevo.nl
pi_147425314
quote:
0s.gif Op dinsdag 9 december 2014 15:44 schreef Monolith het volgende:

[..]

Gewoon MySQL workbench?
Hier heeft het de bijnaam MySQL CrashBench gekregen. :+

Kun je wel mooie ERD's in maken.
pi_147425465
quote:
1s.gif Op dinsdag 9 december 2014 16:31 schreef robin007bond het volgende:

[..]

Hier heeft het de bijnaam MySQL CrashBench gekregen. :+

Kun je wel mooie ERD's in maken.
Ik doe zelf eigenlijk erg weinig DBA werk de laatste jaren, zeker op SQL gebied. Hooguit wat met RoboMongo en dergelijke.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_147425976
HeidiSQL ^O^
------___------ 53
----.(___).---- 42
---(o\_!_/o)---
pi_147426108
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.

[ Bericht 5% gewijzigd door KomtTijd... op 09-12-2014 17:55:19 ]
zcflevo.nl
pi_147426161
Adminer misschien? http://www.adminer.org/

Hoewel ik dat zelf niet echt wat vind
------___------ 53
----.(___).---- 42
---(o\_!_/o)---
pi_147427748
quote:
14s.gif Op dinsdag 9 december 2014 16:58 schreef KomtTijd... het volgende:
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStorm prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
Waarom ben je phpmyadmin zat dan?
pi_147427764
sorry zie edit :P
zcflevo.nl
pi_147429147
quote:
14s.gif Op dinsdag 9 december 2014 16:58 schreef KomtTijd... het volgende:
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
Leuk dat je PHPStorm wegstreept, je kan in PHPStorm je database sources toevoegen en dan heb je daar ook een autocomplete op.

Verder gebruik zelf ook HeidiSQL zoals Rockfire zegt. :P
pi_147430375
HeidiSQL draait in Wine op Linux. :(
pi_148114889
ik wil graag uit verschillende folders 1 image halen
heb nu dit, maar dan krijg ik toch alle foto's te zien
met toevoegen van => $value kom ik er ook niet aan uit

Hie kan ik dit het beste oplossen?

1
2
3
4
5
6
7
8
9		<?php
$dirname = "fotoalbum/fotoalbum/*/";
$images = glob($dirname."*.JPG");
foreach($images as $image) {
if ($image == 0) {
echo '<img src="'.$image.'" />';
 }
}
?>
pi_148115363
quote:
0s.gif Op maandag 29 december 2014 21:58 schreef MrNiles het volgende:
ik wil graag uit verschillende folders 1 image halen
heb nu dit, maar dan krijg ik toch alle foto's te zien
met toevoegen van => $value kom ik er ook niet aan uit

Hie kan ik dit het beste oplossen?
[ code verwijderd ]

Je checkt niet op index.
pi_148115496
quote:
1s.gif Op maandag 29 december 2014 22:06 schreef Scorpie het volgende:

[..]

Je checkt niet op index.
1
2
3
4		<?php
$value = 0
foreach($images as $image => $value)
?>

iets in deze richting?
pi_148115543
quote:
0s.gif Op maandag 29 december 2014 22:09 schreef MrNiles het volgende:

[..]
[ code verwijderd ]

iets in deze richting?
Value is de index. Je wil altijd alleen de eerste index hebben, dus moet je value checken op 0.

[ Bericht 1% gewijzigd door #ANONIEM op 29-12-2014 22:10:35 ]
pi_148116158
quote:
1s.gif Op maandag 29 december 2014 22:10 schreef Scorpie het volgende:

[..]

Value is de index. Je wil altijd alleen de eerste index hebben, dus moet je value checken op 0.
1
2
3
4
5
6
7
8
9
10		<?php
dan zou ik verwachten zoiets
$dirname = "fotoalbum/fotoalbum/*/";
$images = glob($dirname."*.JPG");
foreach($images as $image => $value) {
if ($value == 0) {
echo '<img src="'.$image.'" />';
 }
}
?>

maar dan krijg ik alle indexen te zien volgens mij
nog even doorspelen
nog een duidelijk tip?

als ik dit aanpas
1
2
3
4		<?php
if ($image == 0) {
echo '<img src="'.$value.'" />';
?>

dan krijg ik wel de eerste foto, maar alleen van de folder
pi_148116268
value => image in plaats van andersom.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148116336
quote:
0s.gif Op maandag 29 december 2014 22:22 schreef Monolith het volgende:
value => image in plaats van andersom.
bijna een snelle edit gedaan...heb ik dus gedaan
maar dan krijg ik alleen de eerste foto van de eerste folder
  maandag 29 december 2014 @ 22:23:27 #183
91039 mstx
2x1/2 = 1/2 x 1/2
pi_148116355
Ja of je echo't gewoon $images[0] :')
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_148116424
quote:
1s.gif Op maandag 29 december 2014 22:23 schreef mstx het volgende:
Ja of je echo't gewoon $images[0] :')
Laat TS ff lekker kutten met arrays, anders snapt hij het nooit :P
  maandag 29 december 2014 @ 22:25:28 #185
91039 mstx
2x1/2 = 1/2 x 1/2
pi_148116453
quote:
0s.gif Op maandag 29 december 2014 22:23 schreef MrNiles het volgende:

[..]

bijna een snelle edit gedaan...heb ik dus gedaan
maar dan krijg ik alleen de eerste foto van de eerste folder
dan moet je eerst een readdir doen van de root map, door de mappen loopen en per map de afbeeldingen ophalen en de eerste tonen.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_148116496
Even uitzoeken hoe globs werken en dan toepassen op je directory structuur. In een glob matcht ** alles inclusief directory separators en * alles behalve directory separators.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148116577
quote:
1s.gif Op maandag 29 december 2014 22:23 schreef mstx het volgende:
Ja of je echo't gewoon $images[0] :')
Die had ik al eens geprobeerd, maar dan krijg ik een loop van foto1 uit folder1, geen andere folders

quote:
Laat TS ff lekker kutten met arrays, anders snapt hij het nooit :P
Zeker waar
pi_148599940
Voor als iemand testgegevens nodig heeft:
http://www.generatedata.com/
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
pi_148622805
quote:
7s.gif Op maandag 12 januari 2015 11:44 schreef Aether het volgende:
Voor als iemand testgegevens nodig heeft:
http://www.generatedata.com/
https://github.com/fzaninotto/Faker
pi_148702387
Korte vraag mbt zoeken op grote tabellen.

Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur

Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken)

Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang
Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20		CREATE TABLE IF NOT EXISTS `videos` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `site_id` int(10) unsigned NOT NULL,
  `video_id` varchar(64) NOT NULL,
  `tags` varchar(255) NOT NULL,
  `uploaddate` datetime NOT NULL,
  `title` varchar(255) NOT NULL,
  `description` text NOT NULL,
  `thumbnail` varchar(255) NOT NULL,
  `url` varchar(255) NOT NULL,
  `embed` varchar(255) NOT NULL,
  `seconds` int(10) unsigned NOT NULL,
  `lastview` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `ratingcount` int(10) unsigned NOT NULL,
  `ratingtotal` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `site_id` (`site_id`),
  FULLTEXT KEY `tags` (`tags`),
  FULLTEXT KEY `title` (`title`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=7217117 ;

Nu duurt de volgende query:
1
2		SELECT COUNT( 1 ) 
FROM (SELECT * FROM  `videos` WHERE  `tags` LIKE  '%home%') t
erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs

Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  donderdag 15 januari 2015 @ 10:17:15 #191
363995 Reemi
Zeg maar Remi.
pi_148702438
Ik zou sowieso de tags los opslaan in een andere tabel, in plaats van als één string in een kolom. Dus tag-video_id paren. Dat zal inderdaad al een stuk sneller worden.
Smile like you mean it
www.wefut.com
  donderdag 15 januari 2015 @ 10:17:58 #192
91039 mstx
2x1/2 = 1/2 x 1/2
pi_148702452
Een LIKE beginnend met % is altijd traag. Tags in een aparte tabel en een koppeltabel tussen tags en videos is de beste oplossing. Dat scheelt je ook nog een boel dubbele data.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  FOK!mycroftheld donderdag 15 januari 2015 @ 10:54:05 #193
128465 verified  bondage
Ingewikkeld
pi_148703416
quote:
0s.gif Op donderdag 15 januari 2015 10:14 schreef Chandler het volgende:
Korte vraag mbt zoeken op grote tabellen.

Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur

Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken)

Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang
Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB
[ code verwijderd ]

Nu duurt de volgende query:
[ code verwijderd ]

erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs

Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
Ik heb zelf slechte ervaringen met zoeken in grote tabellen, zowel MyISAM als InnoDB.

Is dit misschien een optie? http://astellar.com/2011/(...)-search-with-sphinx/
FOK!stats | Mycroft | DTS!stats
pi_148704887
Ik ga eens een import draaien die tags in een apart tabel zetten + een tabel voor video/tag links. Eens kijken hoe lang dit gaat duren... :D
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148707977
LIKE negeert sowieso de fulltext index. Wil je daar gebruik van maken, dan kun je bijvoorbeeld MATCH gebruiken, zie ook de documentatie.

Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148722045
quote:
0s.gif Op donderdag 15 januari 2015 13:17 schreef Monolith het volgende:

Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
:Y Een tijd terug voor het eerst met ElasticSearch gewerkt :o gaat inderdaad écht bloedsnel. Automatisch aanvullen en suggesties geven snel.
pi_148722300
Het duurde ff maar dan heb je ook wat.

304k aan tags
kleine 69miljoen tag links :@

Nu nog een leuke query browsen...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148735784
quote:
0s.gif Op donderdag 15 januari 2015 10:14 schreef Chandler het volgende:

Nu duurt de volgende query:
[ code verwijderd ]

erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs

Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
Je kunt het iets beter krijgen door geen subquery te gebruiken:
1SELECT COUNT( * ) FROM `videos` WHERE  `tags` LIKE  '%home%'
Maar de winst die je zo kunt behalen is beperkt. Je kunt niet efficient zoeken als je niet weet waar in de string je moet kijken. Het is immers ook niet handig om in een woordenboek alle woorden waar een Q in staat te markeren.

quote:
0s.gif Op donderdag 15 januari 2015 13:17 schreef Monolith het volgende:

Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Da's zeker een optie die het overwegen waard is, helemaal omdat het over redelijk grote datasets gaat.
fokstok.nl
pi_148738520
Klopt Light! :)

Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148749556
quote:
0s.gif Op vrijdag 16 januari 2015 08:05 schreef Chandler het volgende:
Klopt Light! :)

Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat...
Die tags in een aparte tabel opslaan is alvast een stap, mits je de indexes goed zet en gebruikt.

Maar je zit tegen de grenzen van wat met MySQL mogelijk is en als je spannendere dingen wilt, moet je op zoek naar een hoster die wel een zoekplatform aanbiedt (of zelf de hosting doen).
fokstok.nl
pi_148798465
Ik ben bang dat hij dan naar een andere hoster opzoek moet, ben zelf nu aan het spelen de database zonder zoekplatform en heb in eerste instantie mijn tags maar eens beperkt.. En wat video's geskipped met onzin titels..

Eerst een kleine 8m aan videos, nu 7,2m.
Eerst 188k aan tags, nu 44k.
Eerst 70m aan tag links, nu 48m.

Scheelt toch wat... nu weer verder klooien met die queries...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148835523
ff een queries gespeeld, is niet gemakkelijk zeg :P (zonder specifieke zoekplatformen, maar moet toch echt wel sneller kunnen).

Query result:
quote:
MySQL gaf een lege resultatenset terug (0 rijen). (query duurde 157.0733 sec)
Query:
1
2
3
4
5
6
7		SELECT b . * 
FROM video_tag_link bt, videos b, tags t
WHERE bt.tag_id = t.tag_id
AND (t.name IN ('home',  'video'))
AND b.id = bt.video_id
GROUP BY b.id
HAVING COUNT( b.id ) =2

En met bestaande velden home en alone is het resultaat:
quote:
Showing rows 0 - 29 (213 total, query duurde 51.7825 sec)
Dat kan sneller toch? :P

Deze pagina gaf me aardig wat info: http://tagging.pui.ch/pos(...)ms-performance-tests

-edit-

Koppel ik ze los dan heb ik dit
SELECT * FROM tags WHERE name in ('home','alone') == 0,000 secs (2 resultaten)
SELECT video_id FROM video_tag_link WHERE tag_id IN ( 2316, 290 ) LIMIT 0 , 300000 == 20 secs (15292 resultaten).
SELECT * FROM videos WHERE id IN (763,) == 1 secs (15292 resultaten).

Is een stukje sneller... :{

[ Bericht 13% gewijzigd door Chandler op 19-01-2015 12:23:37 ]
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148835835
quote:
5s.gif Op maandag 19 januari 2015 12:08 schreef Chandler het volgende:
ff een queries gespeeld, is niet gemakkelijk zeg :P (zonder specifieke zoekplatformen, maar moet toch echt wel sneller kunnen).

Showing rows 0 - 29 (213 total, query duurde 51.7825 sec)
Dat kan sneller toch? :P
Voer de query eens uit met EXPLAIN aan het begin.
Dan kun je zien waar het beste indices geplaatst kunnen worden.
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
pi_148835932
quote:
7s.gif Op maandag 19 januari 2015 12:21 schreef Aether het volgende:

[..]

Voer de query eens uit met EXPLAIN aan het begin.
Dan kun je zien waar het beste indices geplaatst kunnen worden.
1
2
3		1 SIMPLE t range PRIMARY,name,id name 34 NULL 2 Using index condition; Using temporary; using filesort
1 SIMPLE b ALL PRIMARY NULL NULL NULL 7158720 Using join buffer (Block Nested Loop)
1 SIMPLE bt eq_ref video_id video_id 8 a.b.id,a.t.tag_id 1 Using index

:)
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148837350
Het ziet er in ieder geval uit als een hele kromme query. Gebruik je nou IN en HAVING om enerzijds te selecteren op twee tag names en anderzijds te checken of ze allebei gevonden worden? In dat geval zou ik eens kijken of je middels WHERE EXISTS niet sneller resultaat krijgt.

Verder valt er vrij weinig te zeggen over je query zonder de onderliggende db structuur te kennen.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148846213
quote:
0s.gif Op maandag 19 januari 2015 13:13 schreef Monolith het volgende:
Het ziet er in ieder geval uit als een hele kromme query. Gebruik je nou IN en HAVING om enerzijds te selecteren op twee tag names en anderzijds te checken of ze allebei gevonden worden? In dat geval zou ik eens kijken of je middels WHERE EXISTS niet sneller resultaat krijgt.
Ik zal het eens bekijken en uitproberen ;)

quote:
Verder valt er vrij weinig te zeggen over je query zonder de onderliggende db structuur te kennen.
Bij deze ;)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22		CREATE TABLE IF NOT EXISTS `tags` (
  `tag_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(32) NOT NULL,
  PRIMARY KEY (`tag_id`),
  UNIQUE KEY `name` (`name`),
  KEY `id` (`tag_id`,`name`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=200938 ;

CREATE TABLE IF NOT EXISTS `videos` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `tags` varchar(255) NOT NULL, -- tijdelijk voor andere tests (zelfde inhoud als beide andere tabellen)
  `title` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  FULLTEXT KEY `tags` (`tags`),
  FULLTEXT KEY `title` (`title`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=7158721 ;

CREATE TABLE IF NOT EXISTS `video_tag_link` (
  `video_id` int(10) unsigned NOT NULL,
  `tag_id` int(10) unsigned NOT NULL,
  UNIQUE KEY `video_id` (`video_id`,`tag_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1; -- 48miljoen records
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148851299
quote:
14s.gif Op maandag 19 januari 2015 17:09 schreef Chandler het volgende:

[..]

Ik zal het eens bekijken en uitproberen ;)

[..]

Bij deze ;)
[ code verwijderd ]

Je mist een index in je koppeltabel
1ALTER TABLE `video_tag_links` ADD INDEX `tag_id` (`tag_id`);

Voor video_id heb je geen aparte index nodig, dat wordt afgehandeld door de unique key. Je zou ook de unique key kunnen aanpassen naar (`tag_id`, `video_id`) en dan een aparte index op `video_id` zetten. In beide gevallen wordt je tabel groter (want meer index-ruimte nodig) en worden queries een stuk sneller.
fokstok.nl
pi_148851533
Volgens mij doet hij altijd een query op beide velden in de index, dus zou dat op zich goed moeten gaan. Hoewel het lang geleden is dat ik me in detail met indices in MySQL heb beziggehouden.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148851875
quote:
0s.gif Op maandag 19 januari 2015 19:41 schreef Monolith het volgende:
Volgens mij doet hij altijd een query op beide velden in de index, dus zou dat op zich goed moeten gaan. Hoewel het lang geleden is dat ik me in detail met indices in MySQL heb beziggehouden.
Er wordt een full table scan gedaan bij een query waar je dat niet verwacht, dus de indices staan niet goed. Dat die full table scan op de video's-tabel wordt gedaan en niet op de koppeltabel, komt omdat die laatste tabel veel groter is (7mln vs 48 mln rijen).
fokstok.nl
pi_148852059
quote:
0s.gif Op maandag 19 januari 2015 19:49 schreef Light het volgende:

[..]

Er wordt een full table scan gedaan bij een query waar je dat niet verwacht, dus de indices staan niet goed. Dat die full table scan op de video's-tabel wordt gedaan en niet op de koppeltabel, komt omdat die laatste tabel veel groter is (7mln vs 48 mln rijen).
Ah, ik had de explain even gemist. ;)
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_148853136
Helaas,

Ook geen profijt... :{ maar thanks voor't meedenken...

Ik speel gewoon verder ;)

-- gelijk een vraagje ;)

Kan iemand mij deze regel uitleggen? :P

CONSTRAINT `image_fk` FOREIGN KEY (`image_id`) REFERENCES `image` (`image_id`),

[ Bericht 32% gewijzigd door Chandler op 19-01-2015 22:08:23 ]
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148862022
quote:
0s.gif Op maandag 19 januari 2015 20:18 schreef Chandler het volgende:

-- gelijk een vraagje ;)

Kan iemand mij deze regel uitleggen? :P

CONSTRAINT `image_fk` FOREIGN KEY (`image_id`) REFERENCES `image` (`image_id`),
De tabel waar die regel in staat heeft een foreign key constraint met de unieke naam image_fk. De waarde in de kolom image_id verwijst naar een waarde in de kolom image_id in de tabel image. Je kunt dus geen waarde opslaan die niet ook in image.image_id staat.

Bijkomend effect is dat er een index op de kolom image_id is in de tabel waar die regel staat.

En als je je afvraagt waarom (`image_id`) tussen haakjes staat; het is ook mogelijk om een foreign key constraint te maken over meerdere kolommen. Die moeten dan wel verwijzen naar evenveel kolommen die allemaal in dezelfde tabel staan. Of dat nuttig is, weet ik niet. Het verklaart de haakjes, en het is nuttig om te weten dat een foreign key ook over meerdere kolommen kan gaan.
fokstok.nl
pi_148970529
Thanks Light! Snap er nog weinig van maar al iets meer dan ervoor..

Qua indexes loopt het nog steeds voor geen meter, heb nu eerst mijn mysql configuratie aangepast. (van 64MB naar 6GB :D) en dat scheelt al aardig wat tijd... maar nog steeds gebruikt hij een temporary filesort...

1
2
3		1 SIMPLE t range  PRIMARY,name,id name 34 NULL 2 Using index condition; Using temporary; using filesort
1 SIMPLE bt ref PRIMARY,video_id video_id 4  asexfilmzoeker1.t.id 488020 Using index 
1 SIMPLE b eq_ref PRIMARY PRIMARY 4 asexfilmzoeker1.bt.video_id 1 NULL

Index voor video_tag_link
1
2
3
4
5		Actie    Sleutelnaam    Type    Unieke waarde    Gecomprimeerd    Kolom    Kardinaliteit    Collatie    Leeg    Opmerking
Wijzigen Wijzigen    Verwijderen Verwijderen    PRIMARY    BTREE    Ja    Nee    video_id        A    Nee    
tag_id    48802076    A    Nee
Wijzigen Wijzigen    Verwijderen Verwijderen    video_id    BTREE    Nee    Nee    tag_id        A    Nee    
video_id        A    Nee

Index voor tags
1
2
3
4
5		Actie    Sleutelnaam    Type    Unieke waarde    Gecomprimeerd    Kolom    Kardinaliteit    Collatie    Leeg    Opmerking
Wijzigen Wijzigen    Verwijderen Verwijderen    PRIMARY    BTREE    Ja    Nee    id    44810    A    Nee    
Wijzigen Wijzigen    Verwijderen Verwijderen    name    BTREE    Ja    Nee    name    44810    A    Nee    
Wijzigen Wijzigen    Verwijderen Verwijderen    id    BTREE    Nee    Nee    id    44810    A    Nee    
name    44810    A    Nee

En index voor videos
1
2
3
4
5		Actie    Sleutelnaam    Type    Unieke waarde    Gecomprimeerd    Kolom    Kardinaliteit    Collatie    Leeg    Opmerking
Wijzigen Wijzigen    Verwijderen Verwijderen    PRIMARY    BTREE    Ja    Nee    id    7158720    A    Nee    
Wijzigen Wijzigen    Verwijderen Verwijderen    seconds    BTREE    Nee    Nee    seconds    73801    A    Nee    
Wijzigen Wijzigen    Verwijderen Verwijderen    tags    FULLTEXT    Nee    Nee    tags    1        Nee    
Wijzigen Wijzigen    Verwijderen Verwijderen    title    FULLTEXT    Nee    Nee    title    1        Nee    

Het veranderen van een indexen etc (meerdere keren gedaan, kost me zo'n 5 uur per index...) :{
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148986741
Een ander type database gebruiken? :P

Zou je ook eens een explain van je query kunnen posten?
pi_148988456
quote:
19s.gif Op vrijdag 23 januari 2015 18:47 schreef TwenteFC het volgende:
Een ander type database gebruiken? :P

Zou je ook eens een explain van je query kunnen posten?
Die staat in mijn 1e quote.

Het rare is namelijk dat zoeken in tabel videos, veld tags (like %tag%) vele malen sneller is dan het uitlezen van tags tabellen (normaliseren). :{ op dit moment geen mogelijkheid om een andere server/scripts te gebruiken anders dan MySQL.......

Wil wel even een dump maken hoor :@ strip ik alle onnodige informatie, heb je een import sql bestand van 4GB :D
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_148991877
Denormaliseren? Gewoon om te kijken wat het doet.
pi_148991882
Ja :{ dan maar :P
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  vrijdag 23 januari 2015 @ 21:57:21 #218
63192 ursel
"Het Is Hier Fantastisch!
pi_148992856
Zit je stiekem sexfilms te zoeken? :P
pi_149002821
quote:
0s.gif Op vrijdag 23 januari 2015 21:57 schreef ursel het volgende:
Zit je stiekem sexfilms te zoeken? :P
7 miljoen? beetje te veel, maar je zit aardig in de buurt :+
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  FOK!mycroftheld zaterdag 24 januari 2015 @ 10:45:27 #220
128465 verified  bondage
Ingewikkeld
pi_149004280
quote:
0s.gif Op vrijdag 23 januari 2015 19:47 schreef Chandler het volgende:

[..]

Die staat in mijn 1e quote.

Het rare is namelijk dat zoeken in tabel videos, veld tags (like %tag%) vele malen sneller is dan het uitlezen van tags tabellen (normaliseren). :{ op dit moment geen mogelijkheid om een andere server/scripts te gebruiken anders dan MySQL.......

Wil wel even een dump maken hoor :@ strip ik alle onnodige informatie, heb je een import sql bestand van 4GB :D
Welke storage engine gebruik je? Heb je bijvoorbeeld al InnoDB geprobeerd?

En: https://blogs.oracle.com/(...)ncement_in_full_text

[ Bericht 6% gewijzigd door bondage op 24-01-2015 10:52:25 ]
FOK!stats | Mycroft | DTS!stats
pi_149005352
Sowieso MariaDB in plaats van MySQL
pi_149005580
quote:
1s.gif Op zaterdag 24 januari 2015 11:47 schreef robin007bond het volgende:
Sowieso MariaDB in plaats van MySQL
En waarom zou dat gaan helpen? Zoals al aangegeven is de beste optie om gewoon een fatsoenlijk zoekplatform te gebruiken, maar die mogelijkheid heeft hij niet.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_149005664
Nee :( al ligt het volgens mij en Light voornamelijk aan de foutieve indexen... :{ alleen die goed krijgen kost per test 8 uur :( LOL
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_149005681
quote:
1s.gif Op zaterdag 24 januari 2015 11:58 schreef Monolith het volgende:

[..]

En waarom zou dat gaan helpen? Zoals al aangegeven is de beste optie om gewoon een fatsoenlijk zoekplatform te gebruiken, maar die mogelijkheid heeft hij niet.
Het was meer een zijspoor. :P Niet echt relevant aan zijn probleem.
pi_149007705
Jeej,

Volgende query doet het best :)

1
2
3
4
5
6
7
8		explain
SELECT * 
    FROM videos o
    LEFT OUTER JOIN video_tag_link ot ON ot.video_id = o.id
    LEFT OUTER JOIN tags t ON t.tag_id = ot.tag_id
   WHERE t.name IN ('home','alone')
GROUP BY o.id
  HAVING COUNT(DISTINCT t.name) = 2

Doet ook aan filesort maar vind in totaal 5638 resultaten in ruim 1 seconde... :D
The people who lost my respect will never get a capital letter for their name again.
Like trump...
actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
[PHP/(My)SQL] voor dummies #119
Index

» digital corner

Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')