MySQL und Tabelle > 500.000 Einträge

[outofbound]

nur um's nochmal zu wiederholen:
bei like '%shu' und like 'shu%' kann MySQL durchaus Indices nutzen.

Wo hast du dass denn her?

http://dev.mysql.com/doc/mysql/en/MySQL_indexes.html behauptet etwas anderes:

"MySQL also uses indexes for LIKE comparisons if the argument to LIKE is a constant string that doesn't start with a wildcard character"

Wenn aber ein like '%shu%' kommt, muss es alle Datensaetze durchgehen.

Mysql kann einen Index dann benutzen, wenn der String nicht mit Wildcards beginnt.
Das macht überigens auch von der tatsächlichen Implementierung der Indices her
Sinn.

PS: Ab Mysql 3.23.23 gibt es die Volltextsuche, die ist recht fix, und macht quasi genau das gleiche wie die Artikelmatrix, nur schneller (weil a) c-code b) muss die Datenbank nicht hin und her schaufeln, um den Index zu erstellen).

Seufz, das wäre schön, wenn es denn wirklich so wäre.
Leider kann MySQL wesentlich weniger als Sybase, wenn es um Querryanalysen geht,
du wirst aber merken, dass deine Annahme nicht mehr korrekt ist wenn du entsprechende
Datenmengen verwendest und dir die internas der Querrys mal genau anschaust.

Davon abgesehen dass Fulltext was MySQL- Eigenes ist und entsprechend also nur da
nutzbar ist, dazu noch auf MyISAM only... dann wirft man praktisch die ganzen Vorteile
von z.B. InnoDB weg... muss nicht sein. ;)

http://dev.mysql.com/doc/mysql/en/Fulltext_Search.html

Gruss,

Out

[tyberius prime]

Like: oops. Das mitlike '%shu' hab ich echt falsch erinnert!

Fulltextsearch: Definitiv MySQL only, funktioniert aber fuer Dokumentsuchen leidlich gut, und ist haltschnell ohne groesseren (eigenen) Entwicklungsaufwand umgesetzt.
Klar, anlegen der Indices kann mal ein paar Stunden dauern - aber das macht ja der Rechner.
Wenn man dann spaeter wechselt, hat man natuerlich die Kosten, 'ne eigene Volltextsuche zu bauen am Bein - aber das ist spaeter, und meistens nicht abzusehen. Daher, was du morgen kannst bezahlen...

so long,
Tyberius Prime

ps: 'internas der queries': Damit meinst du bei MySQL EXPLAIN $query, oder gibt's da noch ne Stufe detailierter?

[outofbound]

Es wäre schön, wenn es genauer ginge, Sybase kann da z.B. so einiges:

http://manuals.sybase.com/onlinebooks/g ... View/33584

mal ganz abgesehen von sqsh, mächtig ist dem. ;)

Gruss,

Out

[grafzahl]

So, zurück aus dem Kurzurlaub.

@kase:
Ich habe Deine genannten Indexe gesetzt, sowie noch 2-3 andere, die ich öfter mal abfrage (Stop, etc.).

@OutofBound:
Ich lösche alle Artikeldaten, da fast ein Viertel der Daten sich täglich ändert. Ein Vollupdate geht wesentlich schneller als SELECT mit anschließendem UPDATE oder DELETE.

Ich habe nun auch noch ein paar andere Maßnahmen getroffen. Server auf 4.0.20 aktualisiert. Upgrade ging ohne Probleme. FULLTEXT auf Titel erstellt. Dauer der Indexerstellung: ca 1 Minute. Nun rennt die Datenbank. Abfrage mit MATCH (Titel) AGAINST ('$query') dauert auf rund 550.000 Artikel exakt 0.0067 sek. WAHNSINN.

Endlich ist Schluss mit der LIKE Geschichte.

[grafzahl]

Kurze Info der aktuellen Lage:

Ich habe das Projekt nun komplett auf mod_perl 1.29 mit Apache::PerlRun umgestellt. Das Apache::DBI Modul sorgt für einen permanenten Datenbankconnect per Child.

Datenstand bei aktuell 1.1 Mio. Einträge. Trotz Datanstandverdopplung keine Performanceeinbrüche und das beim guten alten Rootie L. CPU-Last bei 10 gleichzeitigen Abfragen beträgt 10-15%.

Im Ã?brigen habe ich herausgefunden, warum der Server abgeschmiert ist. Der Server verfügt nur über 256MB RAM, sowie 256MB Swap. Beim Import der Artikel habe ich ein Self-DoS herbeigerufen, da der Speicher nicht ausreichte (Perl-Prozess 380MB). Kleine temporäre Swapvergrößerung um 256MB mittels "swapon swapfile" vor dem Import und schon läuft es wie geschmiert. Natürlich auch "swapoff swapfile" nach dem Import, damit der nicht im Normalbetrieb in ein File swapt.

Nochmal Danke an alle die geholfen haben.

Gruß Axel

[outofbound]

Oehm, auf die Gefahr hin ein "Bitcher" zu sein:

Was ist so schlimm daran in ein File zu swappen?

Gruss,

Out

PS: Ich habe ausschliesslich ein Swapfile...

[grafzahl]

Ich habe gelesen, daß ein Swapfile um einiges langsamer ist als eine Swap-Partitition.
Soll wohl daher rühren, da die Swap-Partition ganz vorne im schnellen Bereich der Platte liegt. Das Swapfile liegt eher mittig auf der Platte (je. nachdem wie voll die Platte bei Swapfileerstellung war). Klingt für mich plausibel. Wie sich die genauen Performanceeinbußen kenntlich machen kann ich nicht sagen aber ich denke mal, daß man hier nach dem Motto gehen sollte "Kleinvieh macht auch Mist". Hier ein bißchen Performance, da ein bißchen Performance und Schwups... warum ist das System so lahm ?

Gruß Axel

[captaincrunch]

Die Sache hat herzlich wenig damit zu tun, wo ein Swapfile, respektive eine Swap-Partition auf der Platte liegt, sondern damit, dass der Kernel im Falle einer Partition direkt auf's physikalische Device zugreifen kann, beim File aber noch einen kleinen "Umweg" durch's Filesystem machen muss.

[pennybridge]

Im Ã?brigen habe ich herausgefunden, warum der Server abgeschmiert ist. Der Server verfügt nur über 256MB RAM, sowie 256MB Swap. Beim Import der Artikel habe ich ein Self-DoS herbeigerufen, da der Speicher nicht ausreichte (Perl-Prozess 380MB).

Mal so ganz dumm gefragt: Was machst du, das da so ein dicker Prozess
läuft? Alle Datensätz in in Hash/Array packen?

Ich hab mal das 1,9 GB große DMOZ - Dumpfile in eine DB gelesen und
zugeordnet, aber der _PHP_ Prozess war höchstens 25 MB groß ... ...
Manchmal sind Selects besser, als das ganze über Interpreter zu lösen.

[pedä]

um nochmal auf die abfragen und deren performance zurückzukommen..

hat jemand erfahrungen mit soundex() gemacht? wie siehts da mit performance der datenbanken aus? ist eine suche per soundex überhaupt sinnvoll. und ab wann nicht mehr?

lg
pedä