stopword-list zum SELFForum

[Andreas Korthaus]

Hallo!

Inzwischen bin ich wieder ne Ecke weiter mit meiner MySQL-Suche, bin nur nicht sicher ob iach auch alle Postings geparst habe, naja.
Der nächste Schritt den ich jetzt geplant habe, ist eine Sortierung der Wörter im Suchstring, nach Vorkommen in der Datenbank. Wenn jemand nach "HTTP fsockopen" sucht, wird geprüft, wir oft "HTTP" vorkommt und wie oft "fsockopen", hier vermutlich mit dem Ergebnis das "fsockopen" erheblich seltener vorkommt, und so dieses Wort zuerst über den Fulltext-Index gesucht wird, also generiere ich eien Query wie SELECT... WHERE MATCH (blabla) AGAINST('fsockopen') AND MATCH (blabla) AGAINST('HTTP')...
Soweit so gut. Das doofe an der Sache, die Tabelle mit den Wort-Anzahlen ist zu groß(über 700.000 Datensätze).
Um an die Tabelle zu kommen habe ich das komplette 2002er Archiv "zerlegt" und das Vorkommen jedes einzelnen Wortes(getrennt durch " ") gezählt. Was meint Ihr was mit Abstand das am meisten vorkommende Wort ist? "ich", mit über 300.000 Vorkommen, ein ganz schön egoistisches Forum ;-)
Jedenfalls würde ich die Tabelle gerne ordentlich verkleinern. Hierzu habe ich mir eine kleine stopword-Liste zusammengestellt, aber die paar 100 Wörter sind nur ein Tropfen auf den heißen Stein. Wenn es jemanden interessiert wie die Liste genau aussieht, ich hab sie mal hochgeladen, sind über 4 MB: http://knet-systems.de/temp/words.txt.gz
jedenfalls suche ich jetzt nach Mitteln und Wegen, sinnlose Daten aus der Tabelle rauszuschmeißen. Ich kann garantiert 95% guten Gewissens wegschmeißen, aber manuell mit 700.000 Datensätzen - unmöglich. Da sind z.B. auch so Einträge wie !!!!!!!!!!!!!!!!!! in allen Längen und Kombinationen oder sehr komplexe Javascripte, die kein Leerzeichen dazwischen hatten oder sonst für sinnloser Quatsch, Rechtschreibfehler...
Ich überlege mir eine möglichst Lange stopword-Liste zu erstellen, dann alle Datensätze löschen, die = einem der stopwords sind, oder nicht case-sensitive, oder abzüglich aller Zeichen außer Buchstaben = einem der Wörter. Aber was bringt das? vielleicht ein paar 1000, dann kann ich noch alle Wörter unter 4 Zeichen löschen, wobei ich ungerne Wörter wie PHP oder ASP lösche... Nur wie werde ich den ganzen Quatsch mit sinnlosen Zeichen oder oder Wortformen los, das ist das schlimmste, die Wörter stehen da natütlich in jeder nur erdenklichen grammatikalischen Form drin, dazu noch falsch gesschreibene... hat jemand noch ein paar Ideen wie ich mal einen großen Teil der sinnlosen Wörter loswerde?

Dann noch was zum Prinzip. Ich will eigentlich nicht oft vorkommende Wörter wie Javascript, HTML oder PHP löschen. Denn wenn ich diese Wörter _hinter_ das "bessere" Suchwort setze ist es gar nicht mehr so schlimm, und kann die Qualität des Ergebnisses eigentlich nur positiv beeinflussen, oder? Alle Wörter die nicht in der Liste vorklommen, also auch die gelöschten, werden bei der Suche ignoriert.

Bin für jeden Tipp dankbar!

Viele Grüße
Andreas

[Cheatah]

Hi,

Inzwischen bin ich

kleines Intermezzo nach diesem Wort ;-)

Soweit so gut. Das doofe an der Sache, die Tabelle mit den Wort-Anzahlen ist zu groß(über 700.000 Datensätze).

Für eine Datenbank sollte das absolut kein Problem sein. Wichtig ist, dass das DB-Layout in sich stimmig ist - und dazu gehören Tabellenstruktur, Indizes etc. und auch die Statements.

Leider habe ich mit MySQL wenig Erfahrung und kann daher nicht abschätzen, wie und wie gut MATCH arbeitet bzw. wie es sich performanter gestalten lässt. Möglicherweise bringt ein Ersatz dieser Funktion Vorteile: Vorstellbar wäre z.B. eine Tabelle, die Wort auf Datensatz matcht (n:m), mit einem "simplen" Index. Wahrscheinlich ist ein Volltext-Index nichts anderes; aber vielleicht spart man sich damit den Overhead überflüssiger Funktionalität.

jedenfalls suche ich jetzt nach Mitteln und Wegen, sinnlose Daten aus der Tabelle rauszuschmeißen. Ich kann garantiert 95% guten Gewissens wegschmeißen, aber manuell mit 700.000 Datensätzen - unmöglich.

Warum? ORDER BY COUNT(*) DESC, und einfach von oben nach unten durchgehen. Dort werden die meisten relevanten Stopwords sein, und wenn's bei "kleineren" Mengen welche gibt, fallen die ohnehin weniger ins Gewicht. Alternativ kannst Du auch mal nach "stopwords list german" u.ä. googeln.

Da sind z.B. auch so Einträge wie !!!!!!!!!!!!!!!!!!

Tja, Leerzeichen sind eben nicht unbedingt die besten Trenner... :-) Eine mögliche RegExp zur Ermittlung von Wörtern wäre z.B. "\b([a-z-]+)\b", wenn auch nicht zwingend die ideale.

in allen Längen und Kombinationen oder sehr komplexe Javascripte, die kein Leerzeichen dazwischen hatten oder sonst für sinnloser Quatsch, Rechtschreibfehler...

HTML- und anderen Code zu erkennen ist sicher eine Lebensaufgabe, um die ich Dich nicht wirklich beneide... andererseits ist es u.U. gerade ein Code, nach dem man sucht; frei nach dem Motto "Wie war das noch mit getElementById?".

Ich überlege mir eine möglichst Lange stopword-Liste zu erstellen, dann alle Datensätze löschen, die = einem der stopwords sind, oder nicht case-sensitive, oder abzüglich aller Zeichen außer Buchstaben = einem der Wörter. Aber was bringt das? vielleicht ein paar 1000, dann kann ich noch alle Wörter unter 4 Zeichen löschen, wobei ich ungerne Wörter wie PHP oder ASP lösche... Nur wie werde ich den ganzen Quatsch mit sinnlosen Zeichen oder oder Wortformen los, das ist das schlimmste, die Wörter stehen da natütlich in jeder nur erdenklichen grammatikalischen Form drin, dazu noch falsch gesschreibene... hat jemand noch ein paar Ideen wie ich mal einen großen Teil der sinnlosen Wörter loswerde?

Du solltest Dir in erster Linie überliegen, wie Du "sinnlos" definieren möchtest, und was andere - besonders die Suchenden - wohl von dieser Definition halten werden. Wenn die Datenbankabfragen zu lange dauern, dann drängt sich zuallererst eine Schlussfolgerung auf: Das DB-Layout ist suboptimal.

Dann noch was zum Prinzip. Ich will eigentlich nicht oft vorkommende Wörter wie Javascript, HTML oder PHP löschen. Denn wenn ich diese Wörter _hinter_ das "bessere" Suchwort setze ist es gar nicht mehr so schlimm,

Ist die Reihenfolge wirklich so von Bedeutung? Krass. Aber gab es bei MATCH nicht auch die Möglichkeit, mehrere Wörter in einem einzigen String anzugeben? An irgendsoetwas meine ich mich jedenfalls zu erinnern...

Cheatah

[Andreas Korthaus]

Hallo!

Für eine Datenbank sollte das absolut kein Problem sein. Wichtig ist, dass das DB-Layout in sich stimmig ist - und dazu gehören Tabellenstruktur, Indizes etc. und auch die Statements.

Ja, nur ist das ja nicht die eigentliche Tabelle in der ich suche, die soll nur dazu dienen möglichst performante SQL-Statements zu generieren. Sicher ist das kein Problem, ich hatte zwischenzeitlich, mehr oder weniger aus Versehen mal eine Tabelle mit über 50 Mio Datensätzen und einigen GB Daten! Das ging auch noch erheblich besser als ich dachte!

Leider habe ich mit MySQL wenig Erfahrung und kann daher nicht abschätzen, wie und wie gut MATCH arbeitet bzw. wie es sich performanter gestalten lässt. Möglicherweise bringt ein Ersatz dieser Funktion Vorteile: Vorstellbar wäre z.B. eine Tabelle, die Wort auf Datensatz matcht (n:m), mit einem "simplen" Index. Wahrscheinlich ist ein Volltext-Index nichts anderes; aber vielleicht spart man sich damit den Overhead überflüssiger Funktionalität.

Ich denke nicht das ich das besser hinbekomme, da mysql das eigenlich schon recht performant macht. Vor allem wenn ein Suchbegriff mehrmals gesucht wird, ist das Statement im Cache und nach dem 3,. oder 4. mal dauert die Suche nur noch wenige 1/100 Sekunden. Das Problem bereiten mir seltenere Suchanfragen, die den größten Teil der Anfragen ausmachen. Und da ist es ganz entscheindend in welcher Reihenfolge gesucht wird, das kann durchaus um den Fakter 10 schneller werden wenn das seltene Wort vorne steht!

jedenfalls suche ich jetzt nach Mitteln und Wegen, sinnlose Daten aus der Tabelle rauszuschmeißen. Ich kann garantiert 95% guten Gewissens wegschmeißen, aber manuell mit 700.000 Datensätzen - unmöglich.

Warum? ORDER BY COUNT(*) DESC, und einfach von oben nach unten durchgehen. Dort werden die meisten relevanten Stopwords sein, und wenn's bei "kleineren" Mengen welche gibt, fallen die ohnehin weniger ins Gewicht. Alternativ kannst Du auch mal nach "stopwords list german" u.ä. googeln.

Order By über eine Tabelle mit 700.000 Datensätzen ist eine denkbar schlechte Idee! Erst muß man die Datensätze filtern und danach in einer temporären Tabelle sortieren.

Tja, Leerzeichen sind eben nicht unbedingt die besten Trenner... :-) Eine mögliche RegExp zur Ermittlung von Wörtern wäre z.B. "\b([a-z-]+)\b", wenn auch nicht zwingend die ideale.

Ja, das dachte ich auch, aber ich dachte dann auch, das kann ich ja auch hinterher auseinander-sortieren, vor allem da das Script schon so eine halbe Stunde gebraucht hat. So wie ich es gemacht habe geht es nicht mit regulären Ausdrücken, und dann würde es _erheblich_ langsamer. Ich will jetzt erstmal mit einigen RegExp ein paar Sachen löschen, halt alle Wörter mit 3 Zeichen und weniger, ale Wörter ohne Buchstaben, aber hiermit hätte ich dann nichtmal 5 % gelöscht. Es gibt einige Überschneidungen mit "", oder , oder groß-klein. Das und die Stopwords sollten nochmal was bringen, vielleicht 20%, aber das ist immer noch viel zu viel! Es ist einfach absolute Zeitverschwendung wenn die Tabelle größer ist als sie sein muß. Mir kommt es _ausschleißlich_ auf Performance an, daher mache ich das überhaupt, und nicht um mir noch eine Bremse oder ein Ranking einzubauen.

HTML- und anderen Code zu erkennen ist sicher eine Lebensaufgabe, um die ich Dich nicht wirklich beneide... andererseits ist es u.U. gerade ein Code, nach dem man sucht; frei nach dem Motto "Wie war das noch mit getElementById?".

Genau das ist es, wenn jemand sowas sucht ist die Suche enorm schnell. Und gerade darauf soll die Suche optimiert werden.

Du solltest Dir in erster Linie überliegen, wie Du "sinnlos" definieren möchtest, und was andere - besonders die Suchenden - wohl von dieser Definition halten werden.

Das habe ich, das Problem ist jetzt die sinnlosen Wörter zu entfernen, eine stopword-Liste ist wirklich nur ein Tropfen auf den heißen Stein.

Wenn die Datenbankabfragen zu lange dauern, dann drängt sich zuallererst eine Schlussfolgerung auf: Das DB-Layout ist suboptimal.

An dessen Optimierung arbeite ich ja gerade, also an der Tabellenstruktur kann ich nicht viel falsch machen, da es nur eine Tabelle ist, und einen vernünftigen Fulltext-Index habe ich ebenfalls. Und wie gesagt, mit gecachter Anfrage, alles prima, nur mit neuen Anfagen dauert es je nachdem bis zu 20 Sekunden. Dieselbe Anfrage nach dem 3. mal dauert z.B. 0,3 Sekunden. Mit einem gut sortierten String vielleicht 2-5 statt 20 Sekunden, je nach Suchbegriff.

Ist die Reihenfolge wirklich so von Bedeutung? Krass.

hätte ich auch nicht gedacht, das hat Michael Schröpl mir kürzlich erklärt, und es stimmt wirklich ;-)

Aber gab es bei MATCH nicht auch die Möglichkeit, mehrere Wörter in einem einzigen String anzugeben? An irgendsoetwas meine ich mich jedenfalls zu erinnern...

Das war meine erste Lösung, aber aus irgendeinem Grund ist das mit mehreren matches besser gewesen, aber das weiß ich gerade auch nicht mehr warum ;-)

Was ich bräuchte sind ein paar Reguläre Ausdrücke die mal so richtig in der Tabelle aufräumen, aber meine zaghaften Versuche bringen nie viel. Ich habe immer Angst wichtige Dinge zu löschen. Ich denke wenn ich hier einen performanten Zugriff auf diese Tabelle hinbekomme, dann muß ich nur noch gucken das ich mittels RAM Disk die kompletten Daten in den RAM bekomme, am besten die kompletten Tabellen und indices, dann noch den Anfragen-Cache schön hochsetzen dann sollte das schnell genug sein, hoffe ich ;-) Übrigens ist mein Fulltext-Index größer als die Daten selbst, mit 110:105 MB ;-)

Grüße
Andreas

PS: Habe de ganze Zeit schon Probleme mit dem Abschicken "serverseitieg Schwierigkeiten..."

[Andreas Korthaus]

Hallo!

Naja, das ganez ist ziemlich langsam. Ist eigentlich ein primary-index schneller als ein normaler index? Jedenfalls braucht die Abfrage der Tabelle ca. 0,3 Sekunden, was viel zu langsam ist. In der Tabelle stehen mnoch alle Wärter vielfach drin, halt ime nur mit vielen Zeichen drucm herum, halt "", (), '' $... ich habe keine Ahnung wie ich das sinnvol trennen kann, auch am von Grund auf weiß ich es nicht, da ich ja jeir auch nach bestimten funktionen gesucht wird, oder ich mache es so das ich mir eienn Standard überlege, wie ich alle Funkrionen dann auch beim Suchstring verändere, wenn ich das in meiner Tabelle und beim Suchen gleich mache dürfte es funktionieren, nur unterscheiden sich die Sprachen leider so stark. Bei Javacript oder PHP für sich wäre es kein Problem, aber die Kombination aus allen Sprachen ist tötlich! Was könnte ich den m,al alles für Sonderzeichen entfernen? Halt einfach alle Leerzeichen am Anfang und am Ende, , vielleicht noch " und ', aber das wars dann auch schon wieder. Ich muß mit der Suche hier definitiv _unter_ 1/10 Sekunde, sonst ist mir das zu teuer. Das doofe ist, wenn ich mich jetzt ein paar Wochen hinsetzen würde und alles sinnlose manuell rauschmeißen würde blieben noch ein paar 10.000 kurze Datensätze übrig, und das ganze wäre nicht viel langsamer als 1/100 Sekunde, aber wie komme ich denn automatisirt dahin?

Udn noch ein Problem, ich wollte einen primärschlüssel definieren, aber da saget er mir es gäbe duplikate vorhanden:

Error

SQL-query :

ALTER TABLE words2 DROP PRIMARY KEY, ADD PRIMARY KEY(word)

MySQL said:

Duplicate entry '"'Layer2','','hide','Layer3','','hide','Layer4',' for key 1

Aber das kann nicht sein, ein SELECT DISTINST word FROM table ergibt genau gleich viele Datensätze! Außerdem habe ich dei Tabelle über ein "CREATE TABLE... SELECT word, SUM(count) FROM tabelle GRPUP BY word" erstellt, wie sollen da noch Duplikate drin sein, gerade das habe ich doch verhindert, oder?

ich habe ja den Link zur Datendatei gepostet(im Mozilla wird die sogar im Browser "als Stream" geöffnet, kann man ja sofort abbrechen), dummerweise nach Anzahl sortiert, denn oben steht natürlich nicht so viel Mist, aber weiter unten wird es immer schlimmer, vor allem so Code-Fragmenteda weiß ich nicht ob ich die noch aufteilen soll oder was ich damit machen soll, keine Ahnung!

Viele Grüße
Andreas

[Mathias Bigge]

Hi Andreas,

ich habe mal vor längerer Zeit im Fach Germanistik ein Tool zur Textanalyse gebastelt, damals mit Clipper (inkrementeller Tokenizer war schon mitgeliefert). Da ging's unter anderem darum, die verschiedenen grammatischen Formen eines Wortes zusammenfassen. Da müsstest Du doch eine riesige Menge Müll habe. Vielleicht suchst Du mal, ob es im Bereich Computerlinguistik oder Systemlinguistik inzwischen was Interessantes gibt. Bei IBM gibt's ein System zu kaufen *g*

Ein paar Probleme der Lexikonbearbeitung kannst Du bei einem Projekt der Uni Erlangen nachschauen, die sich schon länger damit beschäftigen, es wird aber auch der Umfang der Arbeit deutlich, sozusagen automatisiert ein Lexikon/ einen Index zu erstellen.
http://www.linguistik.uni-erlangen.de/tree/pdf/magister/maddin.pdf
Einige Leute, die sich mit dem Thema beschäftigen findest Du unter
http://www.ifi.unizh.ch/CL/CLBuch/kontakt.html

Vielleicht wäre auch ein interessanter Ansatz für Dein Projekt, eine Positivliste zu erzeugen, etwa aus Stichwortverzeichnissen zu SelfHTML und dergleichen, und auf der Basis eine schnelle Suche zu entwickeln. Die Frage ist, wie oft man den Index erneuern und erweitern muss, um möglichst viel zu erfassen.

Die Code-Beispiele rauszufiltern finde ich auch interessant; ein Teil müsste durch die Größer-/Kleiner Zeichen zu erfassen sein. Da die Codeausschnitte an beliebiger Stelle geschnitten sein können, erwischt man sicher nicht alles aber doch einiges.

Aber das alles ist ein wenig aus dem hohlen Bauch geschrieben, sicher hast Du diese Probleme schon bedacht....

Viele Grüße
Mathias Bigge

[Cheatah]

Hi,

Ist eigentlich ein primary-index schneller als ein normaler index?

ein Primary-Index ist ein Index mit Unique-Constraint. Das mag die Datenstruktur optimieren, weil der Fall "gleicher Wert" in keinem Knoten des binären Baums vorkommen kann; es mag aber auch beim Befüllen langsamer sein, weil die Bedingung (unique) erst abgeprüft werden muss. Nun ja, das Aktualisieren eines Index sollte für _Such_anfragen nicht relevant sein.

In der Tabelle stehen mnoch alle Wärter vielfach drin, halt ime nur mit vielen Zeichen drucm herum, halt "", (), '' $... ich habe keine Ahnung wie ich das sinnvol trennen kann,

Das sagte ich bereits :-) Bei Befüllen der Daten ist das Leerzeichen als Trenner eine schlechte Wahl. Du musst _vorher_ die richtigen Werte ermitteln. Nachher ist es potentiell zu spät.

Udn noch ein Problem, ich wollte einen primärschlüssel definieren, aber da saget er mir es gäbe duplikate vorhanden:

Merkwürdig, aber dazu kenne ich mich mit MySQL leider nicht genug aus.

Außerdem habe ich dei Tabelle über ein "CREATE TABLE... SELECT word, SUM(count) FROM tabelle GRPUP BY word" erstellt,

Auch das kann ein Problem sein. Ist das für MySQL anschließend eine physikalische Tabelle, oder wird es vielleicht ähnlich eines Views gehandhabt?

Cheatah

[Andreas Korthaus]

Hi!

ein Primary-Index ist ein Index mit Unique-Constraint. Das mag die Datenstruktur optimieren, weil der Fall "gleicher Wert" in keinem Knoten des binären Baums vorkommen kann; es mag aber auch beim Befüllen langsamer sein, weil die Bedingung (unique) erst abgeprüft werden muss. Nun ja, das Aktualisieren eines Index sollte für _Such_anfragen nicht relevant sein.

Ok, keine Ahnung wieso es nicht ging, hab jetzt nochmal ordentlich gefoltert und die Datenmenge von über 50MB auf ca. 12 MB reduziert. 300.000 Datensätze mit Primary-Index, da dauert die Suche unter 0,01 Sekunden. Jetzt bleiben 2 Fragen:

1. Wie sollte ich die Tabelle optimalerweise abfragen? Ich muß z.B. zu 3 Suchbegriffen das Vorkommen ermitteln, mache ich da leiber 3 Abfragen wie
SELECT count FROM words WHERE word= 'a'
SELECT count FROM words WHERE word= 'b'
SELECT count FROM words WHERE word= 'c'

oder

SELECT count FROM words WHERE word= 'a'OR word= 'b' OR word= 'c' ORDER BY count

Welches ist hier besser?

2. Wie sieht hier die optimale-Index-Struktur aus? reicht der Primary? Bei obigen Anfragen, würde noch ein Index über die Spalte 'count' was bringen, oder besser über 'word,count'? und beim unteren beide?

In der Tabelle stehen mnoch alle Wärter vielfach drin, halt ime nur mit vielen Zeichen drucm herum, halt "", (), '' $... ich habe keine Ahnung wie ich das sinnvol trennen kann,

Das sagte ich bereits :-) Bei Befüllen der Daten ist das Leerzeichen als Trenner eine schlechte Wahl. Du musst _vorher_ die richtigen Werte ermitteln. Nachher ist es potentiell zu spät.

Ich habe jetzt ne ganze Menge gelöscht, und die meisten Sonderzeichen entfernt und hinterher wieder zusammengefaßt. Ist schon besser aber imemr noch viel Quatsch, aber den weiß ich jetzt auch nich mehr heraus zu bekommen. 3 Stellige Wörter habe ich vorerst drinnen gelassen, aber   das Problem ist, dass mysqls Fulltext-Index standardmäßig eh nur Wörter länger als 3 Zeichen sucht. Nur gehen da wichtige Inforationen wie php,asp,xml... verloren.

Außerdem habe ich dei Tabelle über ein "CREATE TABLE... SELECT word, SUM(count) FROM tabelle GRPUP BY word" erstellt,

Auch das kann ein Problem sein. Ist das für MySQL anschließend eine physikalische Tabelle, oder wird es vielleicht ähnlich eines Views gehandhabt?

Ja, eine ganz normale Tabelle wird erzeugt. Kein Problem. Das klappt jetzt alles.

Ach ja, ich mache die mehreren matches daher, weil ich die Wörter so mit AND verknüpfen kann, was sonst nur OR ist.

Problematischer gestaltet sich jetzt die weitere Optimierung. Wenn was gsucht wird, was selten ist, alles schön, aber sonst?

Folgende SQL-Querys werden an die DB geschickt:
// Ermittelung der Reihenfolge
SELECT word FROM words WHERE word = 'javascript' OR word = 'preloader' ORDER BY count

Erstelle temporäre Tabelle zum sortieren
CREATE TEMPORARY TABLE temp_tabelle TYPE=HEAP
SELECT id,category,title,author,time,thread,month,year
FROM archiv
WHERE
MATCH (category,title,author,body) AGAINST ('preloader') AND
MATCH (category,title,author,body) AGAINST ('javascript')
LIMIT 0, 1000

// temp. Tabelle abfragen
SELECT * FROM temp_tabelle ORDER BY time DESC LIMIT 0, 100

Und ich bin noch bei heap geblieben, da ich nicht weiß, wie ich eien _tenporäre_ MyISAM Tabelle auf einer RAMdisk speichern kann. Mit normalen kein Problem, bis auf die Kleinigkeit dass die Tabellen zu groß sind für meinen RAM... Und den Fulltext-Index könnte ich ggfs. doch auch einfach über sein sym. link auf meine RAMdisk im RAM halten, oder?

Naja aber so wie es ist ist es nicht befriedigend. Seltene Begriffe sind sehr schnell, und allgemeine sind zwar schneller geworden, dauern im Schnitt beim ersten mal aber immer noch gut 5 Sekunden, teilweise imer noch erheblich länger, aber das ist sehr selten. Dafür habe ich jetzt nicht mehr so stark den Caching-Effekt, liegt wohl daran dass ich den Cache nicht extra wieder vergrößert habe, aber ich weiß auch gar nicht so genau welche Variable das hier ist, obwohl ich alle Variablen kenne, laut doku, verstehe ich es noch nicht ganz.

OK, eine gute Idee war es, die Daten direkt beim schreiben zu optimieren. Aber damit komme ich auch nicht so weit, vermutlich ließe sich der Datenbestand um 20% reduzieren, aber der große Wurf wäre das auch nicht. Und mit einem eigenen Index, ich habe eine Tabelle mit einem Datensatz pro Wort(aggregiert) pro Posting. Das sind schonmal 12 Mio Datensätze. Da dei meisten Wörte nicht  nur in einem Postig vorkommen, habe ich keine unique Spalte, also auch keinen Primärschlüssel, d.h. ich müßte einen normalen Index drüber legen, was schonmal schlechter ist. Außerdem müßte ich noch die Posting_ID zu jedem Datensatz speichern, was bei 12 Mio Datensätzen das Volumen der Tabelle auf über 1 GB heben dürfte. Aber ich weiß es nicht, vielleicht ist das auch der bessere Weg, ich versuche es mal, auf alle Fälle hätte ich dann mehr Möglichkeiten, nur so ein Tabelle wird niemals in meinen RAM passen ;-)

Man darf auch die Belastung der Suche durch den Durschnittsanwender nicht vernachlässigen. So kann man sagden das meist nach 2 Wörtern gesucht  wird, von denen eines ein sehr oft vorkommendes wie "javascript" oder "html" ist. http://webalizer.teamone.de/selfforum/search_200209.htm
Aber wenn man derartige Wörter jetzt ignoriert, dann kann es sein das das Ergebnis absolut falsch ist, obwohl bei Berücksichtigung ein gutes Ergebnis möglich wäre. Es ist halt ein Komprimiss, zum einen dürfen die "DAU" anfragen nicht zu viel performance fressen, auf der anderen Seite soll die Suche gute Ergebnisse liefern, ein gewisser Zeilkonflikt.

Viele Grüße
Andreas

[Andreas Korthaus]

Hallo nochmal!

OK, eine gute Idee war es, die Daten direkt beim schreiben zu optimieren. Aber damit komme ich auch nicht so weit, vermutlich ließe sich der Datenbestand um 20% reduzieren, aber der große Wurf wäre das auch nicht. Und mit einem eigenen Index, ich habe eine Tabelle mit einem Datensatz pro Wort(aggregiert) pro Posting. Das sind schonmal 12 Mio Datensätze. Da dei meisten Wörte nicht  nur in einem Postig vorkommen, habe ich keine unique Spalte, also auch keinen Primärschlüssel, d.h. ich müßte einen normalen Index drüber legen, was schonmal schlechter ist. Außerdem müßte ich noch die Posting_ID zu jedem Datensatz speichern, was bei 12 Mio Datensätzen das Volumen der Tabelle auf über 1 GB heben dürfte. Aber ich weiß es nicht, vielleicht ist das auch der bessere Weg, ich versuche es mal, auf alle Fälle hätte ich dann mehr Möglichkeiten, nur so ein Tabelle wird niemals in meinen RAM passen ;-)

Also das mit dem eigenen Index ist denke ich keine so gute Idee, zumindest nicht so wie ich es gemacht habe, dauert auch zu lange.

Aber vielleicht ja so:

Tabelle wort_index:

• id (primary)
• wort-string (index)

Tabelle posting_index:
posting_id (primary)
wort_id

Tabelle wort_anzahl
wort_id
anzahl

So, das vernünftig mit Joins verknüpft, könnte das funktionieren? Wie sollten die Indexe hier aussehen?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

mach mal eine kurze Kostenrechnung.

Ok, keine Ahnung wieso es nicht ging, hab jetzt
nochmal ordentlich gefoltert und die Datenmenge
von über 50MB auf ca. 12 MB reduziert.
300.000 Datensätze mit Primary-Index, da dauert
die Suche unter 0,01 Sekunden.

So viele Einträge brauchst Du gar nicht.

Scroll mal durch die entsprechenden Häufigkeiten und male Dir in Gedanken die Verteilungsfunktion hin.
Ich rechne damit, daß sehr viele Worte sehr selten vorkommen und ziemlich wenige Worte sehr oft.

Was willst Du eigentlich erreichen?

Du willst wissen, ob sich die Qualität zweier Suchbegriffe um Größenordnungen unterscheidet.
Tut sie das, dann willst Du die Reihenfolge des FULLTEXT-Zugriffs davon abgängig machen; tut sie es nicht, dann kann Dir die Reihenfolge egal sein.
Ein Faktor von 2 lohnt den zusätzlichen Zugriff Deiner Suchbegriffstermqualitätstabelle gar nicht - das muß schon etwas mehr sein.

Deshalb war mein Ansatz an dieses Problem, die Top 2% aller Suchbegriffe in diese Tabelle aufzunehmen und alles andere zu ignorieren.
Wenn einer Deiner beiden Terme in dieser Menge ist und der andere nicht, dann willst Du sortieren; wenn beide nicht in dieser Menge sind, dann ist es Dir egal.
Sind beide in der Menge, dann _kannst_ Du sie sortieren, weil Du nebenbei ihre Qualitätswerte berechnet hast ... das kostet Dich einfach nichts zusätzlich.
Um diese Prüfung zu machen, reicht Dir aber die Darstellung dieser Top2% in einer separaten (!) Tabelle, mit jeweils nur genau einer Zeile pro Term und dem Ergebnis des jeweiligen count(*)-Aggregats aus der eigentlichen Postingtabelle. Das ist Dein "Suchbegriffsqualitätscache" - und der ist mit etwa 6000 Zeilen und PRIMARY KEY irre schnell. Vor allem kannst Du den auch mühelos im RAM halten.

1. Wie sollte ich die Tabelle optimalerweise
   abfragen? Ich muß z.B. zu 3 Suchbegriffen das
   Vorkommen ermitteln, mache ich da leiber 3
   Abfragen wie
   SELECT count FROM words WHERE word= 'a'
   SELECT count FROM words WHERE word= 'b'
   SELECT count FROM words WHERE word= 'c'

Grusel. Das ist furchtbar langsam.

Nein, Du brauchst eine separate Tabelle aus nur noch zwei Spalten, nämlich dem Wort und seinen "Kosten". Ein "select count" sucht ja ggf. die gesamte Tabelle ab! Das sind intern tausende von Zugriffen.

Dafür mußt Du diese Tabelle - wie bereits in der letzten Diskussion zum Thema von mir erwähnt - nicht zeitnah aktuell halten. Die Top 2% Stopworte ändern sich nicht innerhalb von Tagen - sie tun es innerhalb von Monaten.

Es reicht also völlig, wenn Du diese zweispaltige Tabelle einmal im Monat neu aufbaust - und zwar im Hintergrund unter einem neuen Namen, während die alte Version noch produktiv eingesetzt wird.
Wenn Dein Neuaufbau fertig ist, dann benennst Du beide Tabelle einfach um - das darf Dir dann eine kurze Produktionsunterbrechung von wenigen Sekunden wert sein.

In der Tabelle stehen mnoch alle Wärter
vielfach drin, halt ime nur mit vielen
Zeichen drucm herum, halt "", (), '' $...
ich habe keine Ahnung wie ich das sinnvol
trennen kann,

Verwende exakt die wordchar()-Funktion von mySQL.

Problematischer gestaltet sich jetzt die weitere
Optimierung. Wenn was gsucht wird, was selten
ist, alles schön, aber sonst?

Auch dazu hatte ich bereits gepostet: LIMIT mit interner Begrenzung und Meldung an den Anwender "Ihre Suche war zu ungenau spezifiziert und wurde deshalb nach <n> Treffern abgebrochen; bitte geben Sie weitere bzw. genauere Suchbegriffe ein".

Bei Google bekommst Du auch erst mal nur 10 Treffer zu sehen - und im Ernst, wen interessiert, wieviele Treffer es insgesamt sind?

Und ich bin noch bei heap geblieben, da ich
nicht weiß, wie ich eien _tenporäre_ MyISAM
Tabelle auf einer RAMdisk speichern kann.

Indem Du eine RAM-Disk installierst und auf den Pfad mountest, wo mySQL seine temporären Tabellen speichert - auch dazu hatte ich bereits gepostet.

Mit normalen kein Problem, bis auf die
Kleinigkeit dass die Tabellen zu groß sind für
meinen RAM... Und den Fulltext-Index könnte ich
ggfs. doch auch einfach über sein sym. link auf
meine RAMdisk im RAM halten, oder?

Wenn das vom Platz her funktioniert - prima.

Da dei meisten Wörte nicht  nur in einem Postig
vorkommen, habe ich keine unique Spalte, also
auch keinen Primärschlüssel, d.h. ich müßte
einen normalen Index drüber legen, was schonmal
schlechter ist.

Das glaube ich gar nicht.

Natürlich dauert es länger, alle Treffer eines mehrdeutigen Suchbegriffs auszulesen - das liegt aber nicht (bzw. höchstens marginal, wie Cheatah andeutete) an einem Unterschied zwischen UNIQUE- und NONUNIQUE-Index.

Außerdem müßte ich noch die Posting_ID zu jedem
Datensatz speichern, was bei 12 Mio Datensätzen
das Volumen der Tabelle auf über 1 GB heben
dürfte.

Kann durchaus sein - macht aber gar nichts, weil die Suche immer nur auf einen möglichst keinen Teil dieser Daten zugreifen wird. _Deshalb_ sind die doch ein sortierter Baum ...

Aber ich weiß es nicht, vielleicht ist das auch
der bessere Weg, ich versuche es mal, auf alle
Fälle hätte ich dann mehr Möglichkeiten, nur so
ein Tabelle wird niemals in meinen RAM passen ;-)

Richtig.

Deshalb wirst Du den beobachteten Effekt, daß eine wiederholte Suche schneller wird, weil die von ihr geraden gelesenen Index-Segmente zufällig gerade im Hauptspeicher liegen und nicht neu von der Platte gelesen werden müssen, nicht komplett los werden.

Man darf auch die Belastung der Suche durch den
Durschnittsanwender nicht vernachlässigen.
So kann man sagden das meist nach 2 Wörtern
gesucht  wird, von denen eines ein sehr oft
vorkommendes wie "javascript" oder "html" ist.

Das glaube ich auch - und genau deshalb ist die Reihenfolge dieser beiden Worte beim Indexzugriff wahrscheinlich ziemlich wichtig.

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo Michael!

Ich _hatte_ Deine Beiträge extra bevor ich mich nochmal damit auseinander gesetzt habe nochmal gelesen ;-)

Ok, keine Ahnung wieso es nicht ging, hab jetzt
nochmal ordentlich gefoltert und die Datenmenge
von über 50MB auf ca. 12 MB reduziert.
300.000 Datensätze mit Primary-Index, da dauert
die Suche unter 0,01 Sekunden.

So viele Einträge brauchst Du gar nicht.

Ja, nur das filtern ist schwer, ich hatte halt gedacht damit verbinden zu können, dass worde die im Inex nicht vorkommen auch in der DB nicht vorkommen, aber das ist eh quatsch, da der Index nicht so aktuell sein würde.

Deshalb war mein Ansatz an dieses Problem, die Top 2% aller Suchbegriffe in diese Tabelle aufzunehmen und alles andere zu ignorieren.

Ja, hast Recht, so macht das erheblich mehr Sinn, da ist die Herangehensweise eines Informatikers doch besser ;-)

SELECT count FROM words WHERE word= 'a'
SELECT count FROM words WHERE word= 'b'
SELECT count FROM words WHERE word= 'c'

Grusel. Das ist furchtbar langsam.

Nein, Du brauchst eine separate Tabelle aus nur noch zwei Spalten, nämlich dem Wort und seinen "Kosten".

Das habe ich bereits! Nur noch mit _allen_ Wörtern.

Ein "select count" sucht ja ggf. die gesamte Tabelle ab! Das sind intern tausende von Zugriffen.

Aber irgendwie _muss_ ich das doch machen?! Oder meinst Du das auf die vollst. Tabelle bezogen?

In der Tabelle stehen mnoch alle Wärter
vielfach drin, halt ime nur mit vielen
Zeichen drucm herum, halt "", (), '' $...
ich habe keine Ahnung wie ich das sinnvol
trennen kann,

Verwende exakt die wordchar()-Funktion von mySQL.

Ich dachte Du meintest das:

"MySQL benutzt einen sehr einfachen Parser, um Text in Wörter zu zerlegen. Ein Wort'' ist jede Folge von Buchstaben, Zahlen, `'' und `\_'. Jedes Wort'', das in der Liste der Stopwords vorkommt oder einfach nur zu kurz ist (3 Zeichen oder weniger), wird ignoriert."

Denn zu "wordchar finde ich nichts:
http://www.mysql.com/search/?q=wordchar
http://www.google.de/search?q=mysql+wordchar&ie=UTF-8&oe=UTF-8&hl=de&btnG=Google-Suche&meta=

Problematischer gestaltet sich jetzt die weitere
Optimierung. Wenn was gsucht wird, was selten
ist, alles schön, aber sonst?

Auch dazu hatte ich bereits gepostet: LIMIT mit interner Begrenzung und Meldung an den Anwender "Ihre Suche war zu ungenau spezifiziert und wurde deshalb nach <n> Treffern abgebrochen; bitte geben Sie weitere bzw. genauere Suchbegriffe ein".

Würdest Du dann an dieser Stelle abbrechen und keien Ergebnisse liefern, oder alles was bis dahin gefunden wurde? ersteres ist wohl besser _und_ performanter, oder? Wenn auch nicht viel.

Bei Google bekommst Du auch erst mal nur 10 Treffer zu sehen - und im Ernst, wen interessiert, wieviele Treffer es insgesamt sind?

Ja, aber da gibt es einen kleine aber feinen Unterrschied:
Google bewertet die Ergebnisse und liefert die besten zu erst! Und das kann nur funktionieren wenn Du einmal _alles_ durchsucht hast! Ich denke mal das Googel den Speed weniger über dei Datenbank holt, klar, aber die sind auch irgendwann ausgereitzt, sondern vielmehr über eine geniale cache-Technik.

Und ich bin noch bei heap geblieben, da ich
nicht weiß, wie ich eien _tenporäre_ MyISAM
Tabelle auf einer RAMdisk speichern kann.

Indem Du eine RAM-Disk installierst und auf den Pfad mountest, wo mySQL seine temporären Tabellen speichert - auch dazu hatte ich bereits gepostet.

Ja, hast recht, ich hatte das etwas anders in Erinnerung, sorry.

Außerdem müßte ich noch die Posting_ID zu jedem
Datensatz speichern, was bei 12 Mio Datensätzen
das Volumen der Tabelle auf über 1 GB heben
dürfte.

Kann durchaus sein - macht aber gar nichts, weil die Suche immer nur auf einen möglichst keinen Teil dieser Daten zugreifen wird. _Deshalb_ sind die doch ein sortierter Baum ...

Aber nur bei Verwendung des Fulltext-Index, oder? Das ist ja gerade der entscheindende Unterschied wobei ich nicht verstehen kann das bei 150.000 Datensätzen und 105 MB Daten und 110 MB Fulltext Index die Suche 1 Minute Dauern kann, das verstehe ich nicht. Da ist das Suchen in der Tabelle mit 12 Mio DS die linear durchsucht werden sogar schneller!!!

Viele Grüße
Andreas

[Cheatah]

Hi,

Ich denke nicht das ich das besser hinbekomme, da mysql das eigenlich schon recht performant macht.

das stimmt schon; dennoch lässt sich ein Layout zumeist optimieren.

Das Problem bereiten mir seltenere Suchanfragen,

Das lässt auf einen schlecht durchdachten Index bzw. die fehlende Nutzung desselben schließen.

Order By über eine Tabelle mit 700.000 Datensätzen ist eine denkbar schlechte Idee!

Nur, wenn man es nicht richtig macht :-)

Erst muß man die Datensätze filtern und danach in einer temporären Tabelle sortieren.

Mich würde interessieren, wie diese Filterung stattfindet. Ich dachte "nur" an ein GROUP BY, und eine temporäre Tabelle wird da höchstens implizit erzeugt.

Es ist einfach absolute Zeitverschwendung wenn die Tabelle größer ist als sie sein muß.

Das ist wohl richtig; eine Tabelle sollte _genau_ die Daten enthalten, die drin sein sollten - nicht mehr und auch nicht weniger. Wenn der Wunsch-Datenbestand da ist, kommt es aber auf das DB-Layout an, wie performant die Abfragen sind, nicht auf die Datenmenge. Sprich: Wenn von den 700.000 Datensätzen nur 500.000 gewollt sind, dann lässt sich die Abfrage trotzdem optimieren, weil ja auch alle 700.000 hätten gewollt sein können.

Mir kommt es _ausschleißlich_ auf Performance an, daher mache ich das überhaupt, und nicht um mir noch eine Bremse oder ein Ranking einzubauen.

Natürlich :-)

Du solltest Dir in erster Linie überliegen, wie Du "sinnlos" definieren möchtest, und was andere - besonders die Suchenden - wohl von dieser Definition halten werden.
Das habe ich,

Nicht wirklich, würde ich sagen. Du willst dreibuchstabige Wörter löschen, welche aber einen sicher nicht unerheblichen Teil der Suche ausmachen.

An dessen Optimierung arbeite ich ja gerade, also an der Tabellenstruktur kann ich nicht viel falsch machen, da es nur eine Tabelle ist,

Darauf will ich hinaus: _Das_ kann bereits das Problem sein.

und einen vernünftigen Fulltext-Index habe ich ebenfalls.

Auch dies muss nicht unbedingt ein Vorteil sein.

Und wie gesagt, mit gecachter Anfrage, alles prima,

Leider irrelevant. Der DB-seitige Cache ist eine _zusätzliche_ Optimierung, die für die eigentliche Performancefrage ohne Belang ist.

Ist die Reihenfolge wirklich so von Bedeutung? Krass.
hätte ich auch nicht gedacht, das hat Michael Schröpl mir kürzlich erklärt, und es stimmt wirklich ;-)

MySQL ist lustig[tm] :-)

Was ich bräuchte sind ein paar Reguläre Ausdrücke die mal so richtig in der Tabelle aufräumen,

Richtig wäre, bereits nur die gewollten Daten in die DB zu schreiben. Da dies ein regelmäßiger Prozess ist (unterstelle ich einfach mal), solltest Du diesen optimieren, den Tabelleninhalt löschen und neu befüllen. Das kann die ganze Nacht dauern oder auch noch länger, völlig egal. Denk nur an Abbruchsicherheit ;-)

Ich habe immer Angst wichtige Dinge zu löschen.

Da Du schwerlich definieren kannst, welche _Begriffe_ wichtig sind, solltest Du Begriffe nicht löschen (eine Stopwordlist kann schon falsch sein - in der Regel ist sie es aber nicht). Was Du mit verhältnismäßig hoher Sicherheit sagen kannst ist, dass alles _außer_ Begriffen, insbesondere Satz- und Sonderzeichen, nicht wichtig sind.

Übrigens ist mein Fulltext-Index größer als die Daten selbst, mit 110:105 MB ;-)

Bei dieser niedlichen Datenmenge ;-) hat das Statement hochgradig performant zu sein, unabhängig von der Zahl der Einträge. Denk noch mal über das DB-Layout nach.

PS: Habe de ganze Zeit schon Probleme mit dem Abschicken "serverseitieg Schwierigkeiten..."

Ja, das passiert mir auch häufiger...

Cheatah

[Michael Schröpl]

Hi Cheatah,

Ist die Reihenfolge wirklich so von Bedeutung? Krass.
hätte ich auch nicht gedacht, das hat Michael Schröpl mir kürzlich erklärt, und es stimmt wirklich ;-)
MySQL ist lustig[tm] :-)

wenn mySQL einen FULLTEXT-Zugriff auf mehrere Suchbegriffe durchführen will, dann gibt es dafür ja verschiedene Implementierungsstrategien.

Es könnte beispielsweise ein JOIN zwischen den dabei erzeugten Treffermengen machen - wenn diese Mengen jeweils ähnlich groß sind, ist das wahrscheinlich eine gute Idee.

Sind die Mengen aber extrem unterschiedlich groß, dann könnte mySQL auch erst mal nur einen Indexzugriff für den ersten Suchbegriff machen und dann "nachdenken": Hoppla, das sind ja nur zehn Treffer, da spare ich mir den JOIN und prüfe die andere Bedingung über einen direkten Zugriff auf diese Zeilen".
Zugegeben, gerade bei FULLTEXT ist es nicht wahrscheinlich, daß so etwas Vorteile bringt, aber bei einem beliebigen AND kann ich mir sehr wohl vorstellen, daß es hilft.

Und je besser ein SQL-Optimizer ist (vor allem: je kostenbezogener er arbeitet), um so eher macht es Sinn, über einen solchen "Plan B" nachzudenken, weil er dafür zusätzliche Informationen nutzen kann (z. B. die durchschnittliche Projektionswirkung eines Index oder sogar die konkrete Wirkung eines Suchbegriffs, siehe ANALYZE TABLE). In diesem Falle "wüßte" die Datenbank nämlich vielleicht, daß 10 Treffer "gut" sind, gemessen an der mittleren Projektivität des Index.

Auf die Idee bin ich übrigens gekommen, weil die bisherige Suche "such.pl" genauso arbeitet: Sie macht zwar einen "full table scan" über die Indexdatei, prüft dann aber die Liste der Terme bis
zum Fehlschlagen.
Die Prüfung ist auch dort abhängig davon, wie selten ein Suchbegriff ist - wenn der erste Suchbegriff schon kaum Treffer liefert, dann müssen nur diese wenigen Treffer auf weitere Suchterme geprüft werden - shortcut-AND eben.
Ich hatte mir damals auch mal überlegt, vor der eigentlichen Suche eine passende Sortierung der Suchbegriffe vorzunehmen, hatte aber nie die Infrastruktur dafür, so etwas zu bauen.

Was ich bräuchte sind ein paar Reguläre
Ausdrücke die mal so richtig in der Tabelle
aufräumen,
Richtig wäre, bereits nur die gewollten Daten
in die DB zu schreiben.

Genau das tut FULLTEXT auch - dafür gibt es in  deren Quelltext die fest eingebrannte Stopwortliste und die Forderung einer Mindestlänge für "Worte".
Auch ein "!!!!" wird gar nicht erst im FULLTEXT-Index gespeichert, weil es nicht auf die wordchar()-Funktion von mySQL matched. (Insofern sollte die Stopwortliste auf der exakt gleichen wordchar-Logik aufbauen, die anschließend von der MATCH()-Funktion verwendet wird.)

Diese drei Quelltexteinstellungen im myISAM-Tabellentreiber sind die Schräubchen, an denen man bei mySQL 3.x im Quelltext drehen muß ... mySQL 4 soll diese dann als Konfigurationsdirektiven zugänglich machen, glaube ich gehört zu haben.

Viele Grüße
      Michael

[Matti Maekitalo]

use Mosche;

Mal ne ganz andere Frage:

Inzwischen bin ich wieder ne Ecke weiter mit meiner MySQL-Suche,

Soll das ganze auf dem Self-Server laufen? Denn hier gibt es ja laut Aussage von Christian kein MySQL (welches er auch nicht installieren will (soweit seine Aussage in einem Thread im Testforum, den ich jetzt nicht mehr finde)). Wenn das hier laufen sollte, kannst du dir MySQL ja gleich "abschminken" und gleich was "besseres" benutzen, hier läuft IMHO sowieso eine PostgreSQL-DB.

use Tschoe qw(Matti);

[Christian Kruse]

Hallo Matti,

Inzwischen bin ich wieder ne Ecke weiter mit meiner
MySQL-Suche,

Soll das ganze auf dem Self-Server laufen?

Nee. Soll es nicht. Da entwickelt Daniela was.

Denn hier gibt es ja laut Aussage von Christian kein MySQL
(welches er auch nicht installieren will (soweit seine
Aussage in einem Thread im Testforum, den ich jetzt nicht
mehr finde)).

Korrekt.

Wenn das hier laufen sollte, kannst du dir MySQL ja gleich
"abschminken" und gleich was "besseres" benutzen, hier
läuft IMHO sowieso eine PostgreSQL-DB.

Richtig.

Gruesse,
 CK

[Andreas Korthaus]

Hi!

Inzwischen bin ich wieder ne Ecke weiter mit meiner
MySQL-Suche,

Soll das ganze auf dem Self-Server laufen?

Eigentlich hatte ich mir das nur mal überlegt als die Suche ne ganze Zeit sehr oft schlecht ging, und um mal ein bisschen über SQL, MySQL und Datenbanken an sich zu lernen, was sich durchaus gelohnt hat! Aber ich denke das ich noch lange nicht in der Lage bin was wirklich vernünftiges zu schreiebn was auf dem SELF-Server engesetzt werden könnte, und außerdem:

Nee. Soll es nicht. Da entwickelt Daniela was.

Wenn ich da iegrndwas helfen oder beisteuern kann mache ich das gerne, aber wie gesagt, ich bin kein "richtiger" Informatiker!

Denn hier gibt es ja laut Aussage von Christian kein MySQL
(welches er auch nicht installieren will (soweit seine
Aussage in einem Thread im Testforum, den ich jetzt nicht
mehr finde)).

Korrekt.

Warum eigentlich? Was ich dazu gefunden habe war: http://openacs.org/philosophy/why-not-mysql.html, aber zum einen weiß ich nicht ob man für alle Anwendungen unbedingt

• stored procedures
• triggers or foreign key constraints

OK, subqueries ist schon recht sinnvoll, aber die kann man auch nachbilden, gerade für so eine Suche, wo es im Prinzip nur um Performance geht, ist doch mySQL garantiert schneller als PostgreSQL, oder?

"MySQL only has table-level locking" <= Das verstehe ich nicht, was soll ich denn sonst haben? Entweder ich sperre eine Tabelle oder meherere für alle anderen als den aktuellen User, was sollte man sonst wollen?

Grüße
Andreas

[Christian Kruse]

Hallo Andreas,

Warum eigentlich?

Weil MySQL unverhaeltnismaessig viel RAM braucht.

OK, subqueries ist schon recht sinnvoll, aber die kann man
auch nachbilden, gerade für so eine Suche, wo es im Prinzip
nur um Performance geht, ist doch mySQL garantiert
schneller als PostgreSQL, oder?

Warum sollte es? PostGreSQL steht MySQL nur wenig nach. Und
sobald die schreibenden Zugriffe mehr werden (und das
*werden* sie bei der Suche), degenerieren bei MySQL die
Indizes und man muss sie komplett neu anlegen -- da hilft
auch kein OPTIMIZE mehr.

"MySQL only has table-level locking" <= Das verstehe ich
nicht, was soll ich denn sonst haben?

Row-locking?

Entweder ich sperre eine Tabelle oder meherere für alle
anderen als den aktuellen User, was sollte man sonst
wollen?

Warum sollte ich gleich alles locken, wenn ich nur einen
kleinen Teil (vielleicht nur einen Datensatz) veraendern
will?

Gruesse,
 CK

[Andreas Korthaus]

Hallo!

Weil MySQL unverhaeltnismaessig viel RAM braucht.

Das kann ich bestätigen, zumindest wenn ich noch mehr RAM zuweise steigt die PErformance durch Caching ganz erheblich, aber leider nicht bei erst-Zugriffen, das ist auch mein Problem...

Warum sollte es? PostGreSQL steht MySQL nur wenig nach.

Aber wenn ich mich nicht irre ist das "MySQL-projekt" erheblich größer als das PostGreSQL, was doch vermutlich für schnellere Entwicklung spricht, also mySQL wurde ja mehr für extremst schnelle Lesezugriffe optimiert, daher wohl auch die Meinung das MySQL nicht viel mehr als ein SQL-Forntend für ein Filesystem ist, aber wenn man sieht in welchem Tempo verschieden Techniken in MySQL implementiert werden, ich denke in Version 4.1 wird alles das was bisher kritisiert wurde enthalten sein, ein großer Teil ist schon in MySQl 4.0 beta. Naja, aber die sind halt noch nicht als stable verfügbar, das MySQL 3.23 nicht für alle Anwendungen geigent ist ist klar. Aber meinst Du auch das postgres seinen Vorsprung behalten wird?

Und
sobald die schreibenden Zugriffe mehr werden (und das
*werden* sie bei der Suche), degenerieren bei MySQL die
Indizes und man muss sie komplett neu anlegen -- da hilft
auch kein OPTIMIZE mehr.

Und das ist wirklich so eine Sache, wenn ich habe das ja mit dem 2002er Archiv versucht, da dauert das Schreiben des Fulltext-Index 2 Stunden bei standard-Speichereinstellung, bei Erhöhung des entsprechenden Parameters auf 128 MB dauert dasselbe 6 Minuten!

Warum sollte ich gleich alles locken, wenn ich nur einen
kleinen Teil (vielleicht nur einen Datensatz) veraendern
will?

klingt logisch, kenne leider nur mysql etwas genauer. Aber wenn postgres doch so viel besser ist, wieso setzt sich mysql dann so durch? Ich kenne glaube ich keinen Provider der postgres anbietet. Wobei ich das Gefühl habe, das mysql irgendwann Geld kostet, also nur noch eine lite-Version kostenlos bleibt, naja.

Grüße
Andreas

[Matti Maekitalo]

use Mosche;

Aber wenn postgres doch so viel besser ist, wieso setzt sich mysql dann so durch? Ich kenne glaube ich keinen Provider der postgres anbietet.

http://aktuell.de.selfhtml.org/live/lounge/forum/?t=115&m=1835
http://www.linuxnewmedia.de/presse/:
<cite>
Bei den Datenbanken passiert ein Führungswechsel: PostgreSQL zieht an MySQL vorbei.
</cite>

Das Problem sind eigentlich nicht die verschiedenen Datenbanksysteme, sondern die aufsetzenden Programmiersprachen. Ich habe bei einem meiner Projekte das Problem, dass ich lokal auf PostgreSQL entwickle, das ganze aber auf MySQL in Produktion laufen lasse (ich weiss, das ist suboptimal, aber ich installier doch nicht lokal zwei Datenbanken).

Dies wiederum bedeutet für mich eine Einschränkung bei der Wahl der Programmiersprachen: solange das PHP-Konzept (was Verbindungen zu DB's angeht) so _schlecht_ ist, kann ich zB PHP nicht verwenden. Bei meinem Projekt wird zur Laufzeit entschieden, welche Datenbank es ansprechen soll, und tatsächlich wird durch diese Unterscheidung gerade mal _eine_ Zeile Code ausgetauscht - alles ein Vorteil von generischen Datenbank-Aufsätzen, wie Perl es mit DBI hat.

use Tschoe qw(Matti);

[Christian Kruse]

Hallo Matti,

Dies wiederum bedeutet für mich eine Einschränkung bei der
Wahl der Programmiersprachen: solange das PHP-Konzept (was
Verbindungen zu DB's angeht) so _schlecht_ ist, kann ich zB
PHP nicht verwenden.

Du kennst Pear::DB?

http://pear.php.net/manual/en/core.db.php

Bei meinem Projekt wird zur Laufzeit entschieden, welche
Datenbank es ansprechen soll, und tatsächlich wird durch
diese Unterscheidung gerade mal _eine_ Zeile Code
ausgetauscht - alles ein Vorteil von generischen
Datenbank-Aufsätzen, wie Perl es mit DBI hat.

Bei mir keine einzige. Ist eine Einstellung in der
Config-File ;)

Gruesse,
 CK

[Andreas Korthaus]

Hallo!

Das Problem sind eigentlich nicht die verschiedenen Datenbanksysteme, sondern die aufsetzenden Programmiersprachen. Ich habe bei einem meiner Projekte das Problem, dass ich lokal auf PostgreSQL entwickle, das ganze aber auf MySQL in Produktion laufen lasse (ich weiss, das ist suboptimal, aber ich installier doch nicht lokal zwei Datenbanken).

Dies wiederum bedeutet für mich eine Einschränkung bei der Wahl der Programmiersprachen: solange das PHP-Konzept (was Verbindungen zu DB's angeht) so _schlecht_ ist, kann ich zB PHP nicht verwenden. Bei meinem Projekt wird zur Laufzeit entschieden, welche Datenbank es ansprechen soll, und tatsächlich wird durch diese Unterscheidung gerade mal _eine_ Zeile Code ausgetauscht - alles ein Vorteil von generischen Datenbank-Aufsätzen, wie Perl es mit DBI hat.

Aber damir ist der gesamte Vorteil von Postgres ja zunichte gemacht, denn wenn Du dasselbe Programm sowohl mit mysql als auch mit prostgres laufen läßt kann es von den Vorteilen von Postgres nicht mehr profitieren.  Und welchen Zweckt hat es erst zur Laufzeit zu entscheiden, welche DB eingesetzt wird? Jetzt nur wegen Verfügbarkeit oder was? Das ist doch dann nur ein kleines Feature des Programm das man einfach die DBMS wechseln kann, aber hierging es ja gerade um die Vorteile von postgres für eine spezielle Anwendung.

Grüße
Andreas

[Christian Kruse]

Hallo Andreas,

Warum sollte es? PostGreSQL steht MySQL nur wenig nach.
Aber wenn ich mich nicht irre ist das "MySQL-projekt"
erheblich größer als das PostGreSQL, was doch vermutlich
für schnellere Entwicklung spricht,

Deshalb kann PG ja auch Stored Procedures, Referenzielle
Integritaet, etc., ne? :)

Und das ist wirklich so eine Sache, wenn ich habe das ja
mit dem 2002er Archiv versucht, da dauert das Schreiben
des Fulltext-Index 2 Stunden bei
standard-Speichereinstellung, bei Erhöhung des
entsprechenden Parameters auf 128 MB dauert dasselbe 6
Minuten!

Es geht gar nicht um den Fulltext-Index, es geht generell um
Indizes.

Gruesse,
 CK