nicht angemeldet
(FORUM) gute Nachricht schlechte Nachricht und Frage
0 0 0
(FORUM) gute Nachricht schlechte Nachricht und Frage
Liebe Forumsbesucher,
Background: die Diskussion um eine moegliche Datenbankloesung fuer das Forumsarchiv. Einzelheiten
siehe http://www.teamone.de/selfhtml/sfarchiv/2000_1/t10164.htm
Die gute Nachricht: auf dem teamone-Server ist mSQL installiert, und der Prov. hätte kein Problem damit, uns das auch nutzen zu lassen.
Die schlechte Nachricht: mSQL ist so installiert, daß es nur mit root-Berechtigung administrierbar ist. Und die root-Berechtigung für den Server will der Prov. und verständlicherweise nicht geben.
Der Admin dort kennt sich mit dem Datenbankzeugs nicht so aus, gibt er offen zu. Wenn wir also herausfinden koennen, dass es eine Moeglichkeit gibt, mSQL so zu installieren oder zu konfigurieren, dass man mit einer untergeordneten User-Kennung da ran kommt, waere er durchaus bereit, uns eine mSQL-Loesung basteln zu lassen ...
Also liebe Freaks, bitte postet die entscheidenden Eintraege in den Konfigdateien von Linux, vielleicht klappt es ja ...
viele Gruesse
Stefan Muenz
-
Moin!
Die schlechte Nachricht: mSQL ist so installiert, daß es nur mit root-Berechtigung administrierbar ist. Und die root-Berechtigung für den Server will der Prov. und verständlicherweise nicht geben.
wenn ich das richtig verstehe, müssen die Skripte, mit denen die Datenbank aktualisiert werden soll unter root laufen? Warum können die dann nicht einfach unter suidperl laufen (also erste Zeile im Skript: #!/usr/bin/suidperl ...)? Wenn der Dateieigentümer der Skripte 'root' ist und das 's-Bit' mit chmod +s datei.pl gesetzt ist, können diese Skripte dann von jedem user gestartet werden und laufen mit root-Rechten.
Oder war das jetzt zu einfach gedacht?
Bis dannundwann
Andreas
-
wenn ich das richtig verstehe, müssen die Skripte, mit denen die Datenbank aktualisiert werden soll unter root laufen? Warum können die dann nicht einfach unter suidperl laufen (also erste Zeile im Skript: #!/usr/bin/suidperl ...)? Wenn der Dateieigentümer der Skripte 'root' ist und das 's-Bit' mit chmod +s datei.pl gesetzt ist, können diese Skripte dann von jedem user gestartet werden und laufen mit root-Rechten.
Oder war das jetzt zu einfach gedacht?Ich fürchte, dieser Teil des Problems könnte plattformspezifisch sein. Die Frage ist letztlich, wer im Betriebssystem das s-Bit wie auswertet.
Bei einem Programm (binary) ist es einfach: Die Programmdatei hat das s-Bit, oder sie hat es nicht. Da kann der Programmlader nicht viel falsch machen.
Anders ist es bei einem Skript. Da hat der Lader die Möglichkeit, ein s-Bit der Skript-Datei auszuwerten - er könnte aber genauso ein s-Bit des Interpreters nehmen, der selbst ggf. ein Programm ist - oder vielleicht auch wieder ein Skript, in dem ebenfalls ein Interpreter eingetragen ist ... und so weiter.
Ich erinnere mich daran, daß in IBM AIX 3.1 (Anfang der 90er) das s-Bit bei Shell-Skripts noch funktionierte. Aber beim Wechsel auf AIX 3.2. hat der Hersteller dieses Feature ausgebaut! (Ich glaube, weil irgendwelche Sicherheitsbedenken bestanden, gnlpfts ...)
Und ich, der ich meine gesamte Prozeß-Steuerung naiverweise mit s-Bit-shell-Skripten realisiert hatte, mußte mir ein kleines C-Programm schreiben, welches den ihm übergebenen Parameter prüft und ggf. als Kommando ausführt - denn ein C-Programm darf natürlich weiterhin ein s-Bit haben ...Nicht, daß ich irgend eine Ahnung von mSQL hätte und deshalb abschätzen könnte, wo das Problem wirklich liegt.
-
Hallo,
wieso muß man root-Rechte haben um die Datenbank beschreiben zu können? Es gibt doch sicher die Möglichkeit, Nutzer einzurichten, oder?
Wie machen es denn andere Provider? Die geben ja auch niemanden ein root-Recht...
Was allerdings sein kann (oder so ist), ist vielleicht, daß der root die Tabellenstruktur anlegen muß, die man ihm dann vorgeben müßte.Reiner
-
wieso muß man root-Rechte haben um die Datenbank beschreiben zu können? Es gibt doch sicher die Möglichkeit, Nutzer einzurichten, oder?
Wie machen es denn andere Provider? Die geben ja auch niemanden ein root-Recht...
Was allerdings sein kann (oder so ist), ist vielleicht, daß der root die Tabellenstruktur anlegen muß, die man ihm dann vorgeben müßte.Es kommt wahrscheinlich darauf an, wie sich die Datenbank-Engine mit dem Betriebssystem verschmilzt.
Ich kann die Problematik nur aus dem Universum von IBM-AIX und Oracle beschreiben.
Dort ist es so, daß bei der Installation von Oracle erst einmal eine Kernel-Erweiterung mit installiert wird - ich weiß nicht genau, was die tut, irgendwas mit Interprozeßkommunikation, glaube ich. (Außerdem macht Oracle seine gesamte Festplattenverwaltung weitgehend selbst, statt auf Funktionen des Betriebssystems zuzugreifen - auch dafür müssen wohl irgendwelche Privilegien her.)Ab diesem Moment reicht auch eine normale Benutzerkennung. Oracle wird sinnvollerweise unter einer solchen eigenen Kennung installiert.
Oracle arbeitet sogar so, daß es eine eigene Gruppenkennung "dba" verlangt, und alle Benutzerkennungen, die in dieser Gruppe sind, können die Datenbank administrieren (z. B. starten und stoppen). Die Oracle-RDBMS-Prozesse (Transaktionsmanagement, LogWriter, Monitor etc.) laufen dann unter der Benutzerkennung, welche die Datenbank gestartet hat; Anwendungsprogramme, die auf die Datenbank zugreifen, starten (in dem Prozeßmodell, das wir gewählt haben) Partner-Tasks unter ihrer eigenen Kennung, die mit den Server-Tasks kommunizieren.Also: Zum Betrieb einer Datenbank erscheint mir die Notwendigkeit einer root-Berechtigung nicht zwingend sinnvoll. Für die Installation hingegen ...
-
-
Moin,
Ich fürchte, dieser Teil des Problems könnte plattformspezifisch sein. Die Frage ist letztlich, wer im Betriebssystem das s-Bit wie auswertet.
Bei einem Programm (binary) ist es einfach: Die Programmdatei hat das s-Bit, oder sie hat es nicht. Da kann der Programmlader nicht viel falsch machen.
Anders ist es bei einem Skript. Da hat der Lader die Möglichkeit, ein s-Bit der Skript-Datei auszuwerten - er könnte aber genauso ein s-Bit des Interpreters nehmen, der selbst ggf. ein Programm ist - oder vielleicht auch wieder ein Skript, in dem ebenfalls ein Interpreter eingetragen ist ... und so weiter.
Bei den heute gängigen Linux-Versionen ist es normalerweise so, daß ein Skript
trotz gesetztem s-Bit keine root Rechte erhält. Aber eben gerade für diesen Fall gibt es
suidperl. Wenn suidperl installiert ist, reicht es, statt perl einfach als Interpreter
#!/usr/bin/suidperl zu verwenden und es funzt (hab ich zumindest unter RedHat mal getestet).Bis dannundwann
Andreas
-
-
-
Hallo zusammen !
Leider kenne ich mich speziell mit mSQL nicht aus und durch das Ueberfliegen der Manuals unter http://www.hughes.com.au/ bin ich auf die Schnelle auch nicht schlau geworden,
scheinbar ist aber die Vergabe von Benutzerrechten vorgesehen.Zitat :
'To fill another problem associated with delivering "real" applications over the web, W3-mSQL provides an enhanced and flexible authentication system. Any page that is accessed via W3-mSQL is subjected to the new W3-auth access scrutiny. Access can be restricted via a combination of username/passwd and requesting host. Configuration of the security system, including management of user groups, definition of secure areas, and creation of authorised users, is via a graphical interface accessed via a web page.'Von MySQL weiss ich, dass man dort als Root
Datenbanken anlegen kann, auf die dann User
mit Password zugreifen koennen, die dann innerhalb dieser Datenbank alle Moeglichkeiten haben, Tabellen anzulegen und zu loeschen, und was man halt so braucht.Ich hoffe, das hilft euch ein wenig weiter.
Gruss,
Kerki-
Hallo Kerki
vielen Dank fuer die guten Tips!
Derzeit sieht es aber wohl so aus, als ob eine Loesung mit mSQL doch nicht in Frage kommt - irgendwie scheint mSQL auch "out" zu sein, nachdem es vor drei vier Jahren mal die Nummer eins der Webber-Szene war. Mittlerweile reden alle nur noch von MySQL. Scheint doch deutlich ueberlegen zu sein.
viele Gruesse
Stefan Muenz-
Hallo Stefan !
Danke fuer deine Antwort. Ich hatte schon gedacht, ich als Neuling hier haette mich besser nicht eingemischt, wenn 'Erwachsene' sich unterhalten.
Mittlerweile reden alle nur noch von MySQL. Scheint doch deutlich ueberlegen zu sein.
Das denke ich auch. Und wenn man den Benchmark-Charts
auf der Homepage von MySQL trauen kann, uebertrifft MySQL nicht nur miniSQL, sondern auch noch viele andere alteingesessene Datenbank-Programme. Mich hat die Geschwindigkeit bei meinen ersten Tests jedenfalls voll ueberzeugt.Den Thread ueber die Einfuehrung einer SQL-Datenbank fuer die Suche im Forum+Archiv lese ich mit grosser Wonne. Schoen zu wissen, dass ich mit meinen Problemen nicht allein dastehe und andere eben auch nur mit Wasser kochen.
Ich bin derzeit auch damit beschaeftigt, eine groessere Datenbank mit Adressen und Links ins Netz zu stellen, und zerbreche mir seit laengerem den Kopf darueber wie ich am besten eine Art Volltextsuche per SQL realisieren soll.
Umlaute, Phrasen etc. sind da m.E. echt ein Problem.
Zusaetzlich soll eine Yahoo-aehnliche Baumstruktur realisiert werden. Vielleicht findet sich unter den vielen Klugen Koepfen hier ja jemand, der mir dazu ein paar Tips geben kann. Hat ja entfernt auch etwas mit Eurem Forum-Problem zu tun.
Gruss,
Kerki
-
-
-
Der Admin dort kennt sich mit dem Datenbankzeugs nicht so aus, gibt er offen zu. Wenn wir also herausfinden koennen, dass es eine Moeglichkeit gibt, mSQL so zu installieren oder zu konfigurieren, dass man mit einer untergeordneten User-Kennung da ran kommt, waere er durchaus bereit, uns eine mSQL-Loesung basteln zu lassen ...
Ich habe das starke Gefühl, daß hier zuerst über den Algorithmus diskutiert wird, ohne über die Dienstleistung nachzudenken.
Wieviel vom bisherigen Suchverfahren soll denn aufgegeben werden? regular expressions mit einer SQL-Datenbank? Volltextsuche mit einer SQL-Datenbank? Ich sehe irgendwie keine auch nur vage Ähnlichkeit zu dem bestehenden Suchverfahren.Gerade bei regulären Ausdrücken nützt uns die gesamte Datenbank inklusive Indexbäumen nichts, und auch "Volltext" und "DB-Index" widersprechen einander m. E. ziemlich fundamental.
Stell Dir einfach vor, ein Indexeintrag müßte so lang werden können wie ein komplettes Posting - wie groß würde da wohl der Index werden, wenn er auch noch *jeden* Teilstring enthalten sollte? (Denn tut er das nicht, dann muß er wieder linear durchsucht werden, und die ganze schöne logarithmische Suchdauer ist beim Teufel.)
Das riecht nach exponentieller Größe (es wird ja einfach Zeit mit Platz erkauft), und das halten wir bei diesen Datenmengen nicht aus. Wir brechen ja schon unter einer linear wachsenden Datenmenge zusammen.
Wieviele Gigabytes darf unsere mSQL-Datenbank denn auf dem Server belegen?Mir ist das Problem der wachsenden Datenmenge bewußt. Aber "SQL-Datenbank" ist kein Zauberwort, das die Datenmenge etwa kleiner machen würde, sondern nur ein Werkzeug zur Umsetzung einer bestimmten Strategie.
Bei einem Schlagwortindex würde ich eine relationale Datenbank prima finden, das hatte ich ja schon geschrieben. Aber bei einer Volltextsuche ... hm ...Wenn schon eine Diskussion, dann würde ich diese über Ziele führen wollen und nicht über Technologien. Beispielsweise: "Ist eine Suche nach Phrasen in einem Volltextindex das, was dieses Forum unbedingt braucht?" Wenn die Antwort darauf ein überzeugendes "nein" ist, *dann* könnten die Karten neu gemischt werden.
Lautet sie aber "ja" (und in der bisherigen Diskussion war dies der Fall!), dann würde ich darüber nachdenken, wirklich am Datenvolumen zu drehen.
Beispielsweise könnte man den Index genauso in mehrere Dateien zerlegen wie das Archiv in mehrere Verzeichnisse, und dann wäre es die Entscheidung des Anwenders, wieviele Kreuzchen er im Suchformular macht. Macht er zuviele, dann wird es halt wirklich langsam - und über einen geeigneten timeout-Wert im Webserver (!) wird die Suche dann halt abgebrochen werden. (Man könnte ein Verzeichnis für Indexdateien auf dem Server scannen, daraus diese Auswahlfelder im Formular dynamisch generieren, dabei die Größe des jeweiligen Indexes in MB einblenden und sogar jede Auswahl zurückweisen, bei der die Summe der gewählten Indexe 'zu groß' wird - sogar die zu erwartende Suchdauer für seine Auswahl könnte man dem Anwender via JavaScript vorher ausrechnen ... alles ist machbar.)
Eine Einschränkung auf z. B. den letzten Jahrgang des Archivs oder so ähnlich klingt zunächst mager, aber wenn dort Postings zu finden sind, die selbst wiederum Verweise auf ältere Archiveinträge liefern, reicht es ggf. halbwegs aus.Das eigentliche Problem ist, daß sich die Fragen im Forum ständig wiederholen und das intellektuelle Wachstum des Archivs mit dem reinen Mengenwachstum nicht annähernd Schritt halten kann. Mehr und mehr ähnelt eine Suche im Archiv einer Suche im WWW, weil die Archiveinträge inzwischen ähnlich viel "Rauschen" wie beliebige WWW-Seiten enthalten.
Die Antwort auf dieses Phänomen im WWW ist der Katalog, also die manuelle Indexierung der 'wirklich wichtigen' Informationen. Das Gegenstück hierzu in SelfAktuell ist die Archiv-Auslese! Diese würde ich also pushen, also z. B. dort neue Themengebiete wie XML, WAP usw. zu eröffnen und entsprechende Redakteure anzusaugen versuchen. Das macht gerade bei einem Themenforum mehr Sinn als eine technische Lösung, um aus viel Masse mit wenig Qualität etwas herauszufiltern - im letzten Jahr ist das Verhältnis zwischen Qualität und Quantität ja eher ungünstiger geworden, wie vereinzelt von den Auslese-Autoren im Forum angedeutet wurde.
So viel künstliche Intelligenz, um Semantik automatisch filtern zu können, haben wir leider nicht - hätten wir sie, dann könnte nämlich auch schon der bestehende Indexer im Schwanzabschneider versuchen, zu entscheiden, ob ein Posting es wirklich wert ist, geindext zu werden. Und dann müßten wir an den Datenstrukturen gar nichts ändern, weil wir deren Wachstum in den Griff bekämen.Hätten wir zuverlässiges 'Personal' in irgendeiner dauerhaften Form, dann würde ich darüber nachdenken, einen Index-Zensor einzuführen, also eine Person, die das Forum liest und 'Luft-Postings' als solche markiert. (Ein Dialog-Interface dafür läßt sich ja programmieren - das schreibt dann halt einen zusätzlichen HTML-Kommentar in die Posting-Datei rein.)
Der Indexer könnte anschließend automatisch erkennen, welche Einträge in den Index aufgenommen werden sollen und welche nicht (ins Archiv selbst wandern natürlich alle).
Allerdings: Das Forum komplett zu lesen ist inzwischen vermutlich ein fulltime-Job, zumal dieser sofort erledigt werden muß, weil der Schwanzabschneider derzeit fast schon täglich aktiviert wird. Und die Verantwortung dieser Person wäre auch keine geringe.Eine rein technische Lösung weiterzuentwickeln ist natürlich andererseits auch nicht völlig verkehrt.
Nur so als Info: Seit gestern habe ich einen Indexer, der SelfHTML in das Format des Archiv-Index umsetzen kann. Ich kann also mit dem Archiv-Suchskript in SelfHTML suchen, wenn ich ihm die entsprechende Indexdatei angebe. (Und die Indexdatei von SelfHTML ist gerade mal 2.4 MB groß, die Suche geht also rasend schnell!)
Dasselbe gedenke ich für die Forum-Auslese zu bauen (deren Volumen - derzeit - noch viel kleiner ist - das bißchen Verzeichnistraversieren habe ich schon in einem anderen Skript vorliegen). Und auch über die SelfAktuell-Artikel könnte man "schnell mal drüberfahren" ...Danach könnten wir als nächstes mal darüber diskutieren, ob
1. das bestehende Archiv-Suchskript einfach einen großen Index durchsuchen sollte, der aus den drei Teil-Indexen zusammengemischt wurde, oder
2. man im Such-Skript über radio buttons auswählen können sollte, worin man suchen will, oder
3. es mehrere Verweise auf mehrere Such-Skripte geben sollte, die den zu durchsuchenden Index als CGI-Parameter erhalten würden, oder
4. es zwei Indexe geben sollte (einen für das Archiv und einen für alles Andere), oder
5. whatever.Das erste, was der Anwender eine Suchmaschine über SelfHTML übrigens lernen muß, ist, *viele* Suchbegriffe anzugeben, also sein Problem exakt zu beschreiben. Bei einem einzelnen Suchbegriff ist die Treffermenge angesichts des eigentlich kleinen Datenvolumens ungeheuer. (Kein Wunder, wenn man halt auch im geballten Wissen wühlt ...)
Der Nutzeffekt einer Suche nur genau in SelfHTML ist meiner Meinung nach gar nicht so überragend groß, denn das Werk ist derartig gut über Kapitel und Schlagworte navigierbar, daß der Leser auch so findet, was er sucht.
Was aber meiner Meinung nach wirklich etwas bringen wird, das ist eine Suche über SelfHTML *und* Forum-Auslese *und* SelfAktuell-Artikel - denn semantisch ergänzen diese drei Teile einander, ohne daß die Navigation dies bisher unterstützen würde. Es gibt beispielsweise in der Auslese zwar Verweise auf SelfHTML-Kapitel, nicht aber auf SelfAktuell-Artikel - damit gibt es keine gemeinsame Navigationswurzel außer der SelfAktuell-Startseite.Und die erschlägt den Suchenden halt doch irgendwie mit der Menge ihrer Angebote, zumal die Menge der Artikel ja nicht kleiner wird.
Es ist halt die typische Portalseite - und die Anwender verhalten sich entsprechend: Sie nutzen den Dienst, den sie verstehen, und behandeln alles andere wie Werbung ... "Wieso Auslese lesen? Es gibt doch das Forum, und damit kann ich umgehen."-
Wenn schon eine Diskussion, dann würde ich diese über Ziele führen wollen und nicht über Technologien. Beispielsweise: "Ist eine Suche nach Phrasen in einem Volltextindex das, was dieses Forum unbedingt braucht?" Wenn die Antwort darauf ein überzeugendes "nein" ist, *dann* könnten die Karten neu gemischt werden.
Guten Morgen, Michael.
Ob das mal nicht genau das ist, was bei der letzten Diskussion zu diesem Thema mein Anliegen war. Und ob ich nicht mal ein DB-bezogenes Kurzkonzept mit Vor- und Nachteilen gepostet hatte. Leider wurde die Diskussion drum herum geführt und unter anderem auch mit dem Argument abgeblockt, man könne kein Konzept erstellen, wenn man die DB nicht kenne. Das sehe ich zwar anders, aber ... naja. Meinetwegen.
Jetzt könnte vielleicht eine DB verfügbar sein und nun blockst du ab mit der Bemerkung 'Erst müsse ein Konzept her'. .... äh... ja...<bissig>Am besten, wir lassen alles so wie es ist. Das hat riesige Vorteile: Keinen Streß, keine Diskussion, keinen Zeitaufwand, keine Kosten, keine Fragen an den Provider ... Doch, das ist es!
Und wenn die Datenmengen irgendwann wirklich zu groß für das derzeitige Script sind, kann man immer noch diskutieren. Bis die neue Suche dann 2005 irgendwann mal läuft, interessiert sich zwar keiner mehr für das Archiv. Aber das ist nebensächllich. </bissig>Immerhin ein Gutes hat es: jetzt liegen auch Ideen von dir vor, wie man das bestehende Script für die Zukunft ausrichten könnte. Nach dem ersten Durchlesen ist mehr als eine dabei, die man weiter verfolgen sollte.
Dummerweise ist mir irgendwie die Laune am aktiven Mitdenken vergangen.Viele Grüße
Kess-
Leider wurde die Diskussion drum herum geführt und unter anderem auch mit dem Argument abgeblockt, man könne kein Konzept erstellen, wenn man die DB nicht kenne.
Von mir???
Das sehe ich zwar anders, aber ... naja. Meinetwegen.
Jetzt könnte vielleicht eine DB verfügbar sein und nun blockst du ab mit der Bemerkung 'Erst müsse ein Konzept her'. .... äh... ja...Und? Offenbar bist Du doch derselben Meinung?
Ich suche eine Lösung für ein Problem, und bei mir fängt so etwas damit an, das Problem zu beschreiben.<bissig>Am besten, wir lassen alles so wie es ist. Das hat riesige Vorteile: Keinen Streß, keine Diskussion, keinen Zeitaufwand, keine Kosten, keine Fragen an den Provider ... Doch, das ist es!
Von wegen!
Es bedeutet eben genau Streß, Diskussion, Zeitaufwand (alle drei für die Beantwortung von Fragen im Forum, die per Suche möglich gewesen wäre) und Kosten (Last auf dem Server).
Würden wir sonst diese Diskussion überhaupt führen?Und wenn die Datenmengen irgendwann wirklich zu groß für das derzeitige Script sind, kann man immer noch diskutieren.
Genau. Wir werden das schon merken, wenn der Server unter der Last zusammenbricht.
Welches Antwortverhalten definieren wir denn eigentlich so als wünschenswert? Ohne eine solche Erwartungshaltung können wir "zu groß" ja gar nicht messen ...
Immerhin hat Stefan schon mal festgestellt, daß die mittlere Suchdauer in den letzten Monaten von 7 auf 12 CPU-Sekunden angewachsen ist. Und die Realzeitverzögerung bei einer Suchanfrage scheint in der Größenordnung von Faktor 4-5 zu liegen, weil der Server ja auch noch andere Aufgaben zu erledigen hat. Also: Derzeit etwa eine Minute Suchdauer.Bis die neue Suche dann 2005 irgendwann mal läuft, interessiert sich zwar keiner mehr für das Archiv. Aber das ist nebensächlich. </bissig>
Wie Du gelesen hast, interessiere ich mich selbst schon kaum noch für das Archiv, sondern versuche, inhaltlich hochwertigeren Quellen wie der Archiv-Auslese eine technisch hochwertige Schnittstelle zu geben.
Genau hier sehe ich nämlich mögliche Synergie-Effekte zwischen zwei Gruppen von Leuten, die einander zuarbeiten können: Den Autoren und den Infrastrukturmenschen.Immerhin ein Gutes hat es: jetzt liegen auch Ideen von dir vor, wie man das bestehende Script für die Zukunft ausrichten könnte. Nach dem ersten Durchlesen ist mehr als eine dabei, die man weiter verfolgen sollte.
Aus Deinen Fingern lese ich das besonders gerne! :-)
Dummerweise ist mir irgendwie die Laune am aktiven Mitdenken vergangen.
Das hingegen eher nicht, schluchz ...
-
Aus Deinen Fingern lese ich das besonders gerne! :-)
...
Das hingegen eher nicht, schluchz ...
*grmpf* ;-) Wickel mich doch nicht so um den Finger. Deine Antwort kann ich doch jetzt nicht unkommentiert stehen lassen.
Doch für momentan habe ich mir über Andreas' Idee schon genug den Kopf zerbrochen. Jetzt ruft die Arbeit und hoffentlich heute abend werde ich mich dann noch mal hiermit befassen können. Der Schwanzabschneider wird diesen Thread beim nächsten Lauf hoffentlich noch einmal verschonen.Btw. <cite>Am liebsten wäre mir immer noch eine RAM-Disk</cite>
Stefan, könntest Du nicht einmal nachfragen, wer bestochen werden muß, um für Selfhtml eine 100 MB RAM-Disk zu erhalten, auf die die Indexdatei bei jedem Hochbooten und nach jeder Aktualisierung geladen wird ? 100 MB sollten doch für ein Weilchen reichen. :-)Viele Grüße
Kess-
Stefan, könntest Du nicht einmal nachfragen, wer bestochen werden muß, um für Selfhtml eine 100 MB RAM-Disk zu erhalten, auf die die Indexdatei bei jedem Hochbooten und nach jeder Aktualisierung geladen wird ? 100 MB sollten doch für ein Weilchen reichen. :-)
<stups>Aha! So schnell geht das. Gerade waren wir noch beim Design des neuen Universums, und schon sind wir wieder bei der Mängelverwaltung ...</stups>
Aber ganz im Ernst: Genau an solchen Schrauben ist bisher noch nicht genug gedreht worden, denke ich.
Deshalb auch weiter unten meine Idee, aus der Indexdatei die Zitate des Vorgängerpostings herauszuhalten - damit kriegen wir sie bestimmt um 10, wenn nicht um 20% kleiner, würde ich mal sagen. Jedes bißchen hilft ...Ich sehe schon, dafür würde ich einen separaten Voll-Indexer für das ganze Archiv schreiben müssen - oder gibt es einen solchen schon irgendwo und man müßte ihn noch anpassen, Stefan?
(Das Archiv-Format ist doch irgendwann mal umgestellt worden ...?)Ich erinnere mich auch, daß irgendwer für PAFs Community-Seiten Statistiken über das Archiv erstellt hat (längster Thread etc.). Ist das alles Handarbeit, oder gibt es dort schon ein Skript, welches über das gesamte Archiv drüberläuft?
-
Hi Michael!
So, nun hab ich den Thread doch noch gelesen. *g*
Ich erinnere mich auch, daß irgendwer für PAFs Community-Seiten Statistiken über das Archiv erstellt hat (längster Thread etc.). Ist das alles Handarbeit, oder gibt es dort schon ein Skript, welches über das gesamte Archiv drüberläuft?
Natuerlich war das keine Handarbeit!!! Ich kann Dir die Scripts schicken; hoffentlich denke ich heute noch dran. Wenn nicht - am Montag. Allerdings stammen die Scripts noch aus meiner Anfaengerzeit, sind ziemlich unstrukturiert und quickgehackt. Ausserdem indexen sie nicht die Inhalte der Postings, sondern nur die Subjects a.s.o. Des weiterhin sind viele Archivdateien fehlerhaft, die muessen vorher noch repariert werden. Na egal, ich schicks sie Dir einfach mal.
Calocybe
-
Des weiterhin sind viele Archivdateien fehlerhaft, die muessen vorher noch repariert werden.
Oha! Erfahrungen in dieser Hinsicht interessieren mich natürlich noch mehr als die Skripte ...
-
-
<stups>Aha! So schnell geht das. Gerade waren wir noch beim Design des neuen Universums, und schon sind wir wieder bei der Mängelverwaltung ...</stups>
LOL! Der Gedanke an eine Idee, schließt nicht aus, auch andere Wege zu verfolgen. :-)
Viele Grüße
Kess
-
-
-
-
-
Moin nochmal,
Das riecht nach exponentieller Größe (es wird ja einfach Zeit mit Platz erkauft), und das halten wir bei diesen Datenmengen nicht aus. Wir brechen ja schon unter einer linear wachsenden Datenmenge zusammen.
Wieviele Gigabytes darf unsere mSQL-Datenbank denn auf dem Server belegen?daß die Archivsuche nicht prinzipiell an den technischen Möglichkeiten scheitert, bekommt man ja jederzeit deutlich von Altavista & Co. vorgeführt - dort wird eine um Größenordnungen größere Datenmenge in einem Bruchteil der Zeit durchsucht - und das von einer um Größenordnungen größeren Menge an Leuten - so daß es also nicht einzig an einem schnelleren Rechner oder so liegen kann.
Ich weiß nicht, wie die das genau machen, vermute aber mal, daß es mit Hash-Tabellen funktionieren könnte: Man definiere eine Funktion, die aus einem X-beliebigen Wort einen sog. "Hash-Wert" von z.B. 0-9999 generiert. Danach muß irgendein Skript das Archiv komplett durchforsten und eine Hash-Tabelle mit Einträgen der Form{wort, Nummer_des_Archivbeitrages, Anker (Sprungmarke)}
generieren. Diese Tabelle könnte man dann auf 10000 Dateien verteilen, was zwar nach viel klingt, aber angesichts der Anzahl von mittlerweile >50000 Forumsbeiträgen auch nicht mehr ins Gewicht fällt <g>.
Eine Suche würde dann für jedes Suchwort wie folgt ablaufen:1.) Hashfunktion des Suchwortes berechnen (geht schnell).
2.) Das Ergebnis wäre z.B. eine Zahl zwischen 0 und 9999.
Die entsprechende Indexdatei wird geöffnet.
3.) Alle Einträge (die in der oben erwähnten Form vorliegen) in dieser Datei
durchsuchen, ob sie mit dem Suchwort übereinstimmen und gegebenenfalls
die entsprechenden Archivlinks ausgeben.Bei Und/Oder-Verknüpfungen müßte man diese Schritte mehrmals mit den einzelnen Wörtern durchführen und bei Suchbegriffen aus mehreren Wörtern hintereinander müßte man vielleicht erstmal nach den einzelnen Wörtern suchen und dann in der "Lösungsmenge" nochmals kontrollieren, ob die Worte auch hintereinander stehen - sollte immer noch deutlich schneller gehen als wie bisher.
Angenommen, ein Durchschnittsbeitrag hat ca. 500 Wörter (hat dieser hier in etwa), dann wären wir bis jetzt bei einer Gesamtzahl von ca. 30 Millionen Wörtern für alle Beiträge. Das heißt, in jeder Einzeldatei der Hashtabelle stehen durchschnittlich gut 3000 Einträge, was sich im Ggs. zu >25 MB relativ schnell durchsuchen lassen sollte. Wenn man gleiche Wörter in verschiedenen Beiträgen noch zusammenfaßt, so daß man Einträge der Form
{wort, Liste von Links auf Archivbeiträgen und Anker}
erhält, wird die zu durchsuchende Datenmenge weiter reduziert. Insbesondere wächst die Datenmenge linear und nicht exponentiell. Im Detail habe ich sowas noch nicht gesehen, vielleicht gibt's entsprechende Skripte ja auch schon irgendwo fertig zum Download - aber als Idee wollte ich das einfach mal anregen...
Bis dannundwann
Andreas
-
daß die Archivsuche nicht prinzipiell an den technischen Möglichkeiten scheitert, bekommt man ja jederzeit deutlich von Altavista & Co. vorgeführt - dort wird eine um Größenordnungen größere Datenmenge in einem Bruchteil der Zeit durchsucht - und das von einer um Größenordnungen größeren Menge an Leuten - so daß es also nicht einzig an einem schnelleren Rechner oder so liegen kann.
Sondern an cleveren Datenstrukturen und Algorithmen, in der Tat.
Deine Idee mit der Auflösung der Phrasensuche in Teiloperationen könnte genau der Weg zum Sieg sein - hier haben mir die Profis natürlich Jahre an Erfahrung und Performance-Tests voraus.
Diese Tabelle könnte man dann auf 10000 Dateien verteilen, was zwar nach viel klingt, aber angesichts der Anzahl von mittlerweile >50000 Forumsbeiträgen auch nicht mehr ins Gewicht fällt <g>.
Und diese Dateien dann in mehrstufigen Unterverzeichnissen ablegen, damit nicht die lineare Suche des Betriebssystems nach dem Dateinamen einiges wieder kaputt macht!
(Also maximal diejenige Anzahl von Dateien in einem Verzeichnis ablegen, welche vom Betriebssystem in einem directory buffer gecached wird - hier wird es wieder implementierungsabhängig, aber das Prinzip ist klar. Ich denke, bei 10000 Dateien werden 100 Verzeichnisse mit je 100 Dateien reichen, aber wir können auch gerne vier Ebenen mit je 10 Dateien ausprobieren ...)Im Klartext: Der Ergebnistyp der Hash-Funktion sollte ein n-Tupel überschaubar kleiner Werte sein. (Das können ja auch Buchstaben sein, falls Datei- bzw. Verzeichnisnamen aus Zahlen nicht erwünscht sein sollten.)
Eine Suche würde dann für jedes Suchwort wie folgt ablaufen:
1.) Hashfunktion des Suchwortes berechnen (geht schnell).
2.) Das Ergebnis wäre z.B. eine Zahl zwischen 0 und 9999.
Die entsprechende Indexdatei wird geöffnet.
3.) Alle Einträge (die in der oben erwähnten Form vorliegen) in dieser Datei
durchsuchen, ob sie mit dem Suchwort übereinstimmen und gegebenenfalls
die entsprechenden Archivlinks ausgeben.Das ist eine relativ kleine Änderung im Suchskript - kein echtes Problem.
Über die Verwendung mehrerer Indexe hatte ich ja bereits nachgedacht - den Namen zu berechnen, kann nicht das Problem sein. Ich denke, das ist eine zusätzliche Funktion mit ca. 30 Zeilen.Bei Und/Oder-Verknüpfungen müßte man diese Schritte mehrmals mit den einzelnen Wörtern durchführen
... und die Zwischenergebnisse im Speicher halten, um sie später zu JOINen - genau hier beginnt die Sache, tricky zu werden bzw. Ressourcen zu kosten.
Deshalb habe ich bewußt kein ODER und keine rekursiven Ausdrücke implementiert, sondern nur die Trivial-Operatoren AND und NOT.und bei Suchbegriffen aus mehreren Wörtern hintereinander müßte man vielleicht erstmal nach den einzelnen Wörtern suchen und dann in der "Lösungsmenge" nochmals kontrollieren, ob die Worte auch hintereinander stehen - sollte immer noch deutlich schneller gehen als wie bisher.
Phrasensuche als mehrfache Schlagwortsuche mit Nachbearbeitung emulieren, das ist es! Das sollte das Problem der Phrasensuche (die wahrscheinlich ohnehin nicht so wahnsinnig häufig anfällt und gerne etwas langsamer sein darf) in den Griff bekommen.
Angenommen, ein Durchschnittsbeitrag hat ca. 500 Wörter (hat dieser hier in etwa), dann wären wir bis jetzt bei einer Gesamtzahl von ca. 30 Millionen Wörtern für alle Beiträge.
Es sind derzeit 40+ MB Index (der fast nur den Volltext der Postings enthält) aus 50000+ Beiträgen, die also im Mittel keine 800 Bytes lang sind - davon vielleicht 50-100 Bytes Verfasser, Titel, Datum und relativer URL.
Also eher zwischen 100 und 200 Wörtern. Aber in 2-3 Jahren werden wir die von Dir beschriebenen Dimensionen erreicht haben. ;-)Das heißt, in jeder Einzeldatei der Hashtabelle stehen durchschnittlich gut 3000 Einträge, was sich im Ggs. zu >25 MB relativ schnell durchsuchen lassen sollte.
Yep. Die Frage ist allerdings, ob es wirklich diese Einträge sein sollten, die durchsucht werden! (Siehe unten.)
Wenn man gleiche Wörter in verschiedenen Beiträgen noch zusammenfaßt, so daß man Einträge der Form
{wort, Liste von Links auf Archivbeiträgen und Anker}
erhält, wird die zu durchsuchende Datenmenge weiter reduziert.Genau hier wird es wieder teuer.
Bedenke, daß dann der Indexer nicht mehr so leicht inkrementell arbeiten kann!
Und wenn der Schwanzabschneider jedesmal den gesamten Index Datei für Datei einlesen, um eine Handvoll Einträge erweitern und dann wieder abspeichern muß, dann wird Stefan Dir was husten ... ;-)
Deshalb würde ich an dieser Stelle das derzeitige Konzept mit Anhängen neuer Einträge an das Ende von Indexdateien nicht ohne Not opfern.Insbesondere wächst die Datenmenge linear und nicht exponentiell.
Yep. Die Aufgliederung einer komplexen Suche in mehrere einfache Suchen ist es, durch die der Platzbedarf wieder zurück in Zeitbedarf getauscht wird.
Allerdings wird der Index auf diese Weise dann
trotzdem insgesamt *sehr* viel größer als bisher. Denn das Format (und damit das Volumen) eines Indexeintrages ändert sich ja zunächst einmal nicht, und ein Posting mit 200 Worten kann (und sollte, wenn die Hash-Funktion etwas taugt!) sehr wohl simultan in 200 verschiedenen Indexdateien eingetragen werden!
Der Index wird dann also um Faktor 200 größer, und der Indexer wird wesentlich langsamer - das ist der Preis für die schnellere Suche. (Haben wir 8 GB auf der Platte verfügbar? Tendenz steigend! Die Profis haben natürlich fette Server ...)Es gäbe allerdings eine Alternative.
Der Index enthält bisher pro Zeile den Volltext des Postings.
An dieser Stelle könnte man wiederum eine Abstraktionsebene einziehen und in den Index nur einen Verweis auf die Posting-Datei (oder auf eine für Suchzwecke optimierte Version derselben, also das, was bisher im Index-Feld "body" steht) eintragen. Gewinn: Faktor 100-200 an Speicherplatz, weil das Posting nun wieder nur ein oder zweimal auf der Platte steht. Preis: Eine große Anzahl weiterer Dateizugriffe, weil jeder einzelne body erst aus einer Datei eingelesen werden muß. (So optimiert man halt ständig zwischen Zeit und Platz hin und her ...)
Und diese Dateien sollten dann ggf. wieder eine pro Posting sein, also 50000+ Dateien, mit denselben Infrastrukturmaßnahmen wie für den hashed index ... hm ... so etwa sieht es eben aus, wenn man eine hierarchische Datenbankstruktur in Perl realisieren will.Im Detail habe ich sowas noch nicht gesehen, vielleicht gibt's entsprechende Skripte ja auch schon irgendwo fertig zum Download
Kennt sich jemand gut genug mit CPAN-Modulen aus, um das zu beantworten? (Cheatah?)
aber als Idee wollte ich das einfach mal anregen...
Ich denke, das meiste von dem, was Du beschrieben hast, ist nicht wirklich schwer zu realisieren. (Insbesondere das parallele Generieren vieler Dateien durch den Total-Indexer habe ich im Dezember selbst in Perl programmieren müssen, und durch ein hilfreiches Forum-Posting ging das sehr elegant.)
Es muß halt auch der Indexer zu jedem Posting den Hash-Wert berechnen und begreifen, an welche der vielen Dateien er die aktuelle Zeile anhängen muß.Bei dem bereits modularisierten Suchskript sind es nur zwei oder drei von 13 Funktionen, die von einer derartigen Architekturänderung betroffen sind. Davor habe ich überhaupt keine Angst.
Der Schwanzabschneider dagegen müßte wahrscheinlich in einen Inhaltsparser (der tags eliminiert, Steuerzeichen umcodiert etc.) und einen Indexer aufgeteilt und danach zur Hälfte neu geschrieben werden - wer hat Lust dazu?
-
Eine Suche würde dann für jedes Suchwort wie folgt ablaufen:
1.) Hashfunktion des Suchwortes berechnen (geht schnell).
2.) Das Ergebnis wäre z.B. eine Zahl zwischen 0 und 9999.
Die entsprechende Indexdatei wird geöffnet.
3.) Alle Einträge (die in der oben erwähnten Form vorliegen) in dieser Datei
durchsuchen, ob sie mit dem Suchwort übereinstimmen und gegebenenfalls
die entsprechenden Archivlinks ausgeben.Inzwischen habe ich das Such-Skript mal wieder in der Mangel gehabt. Dabei ist mir mehr und mehr bewußt geworden, was eine Schlagwortsuche gegenüber dem bisherigen Stand der Dinge alles nicht könnte - gerade die V2.x-features reizen die Möglichkeiten der Volltextsuche, die mir der aktuelle Index bietet, ziemlich aus.
Bis zum Beweis des Gegenteils gehe ich davon aus, daß die Aufgabenstellung, über die wir hier diskutieren, lautet: "Beschleunige die Archiv-Suche, ohne dabei die Funktionalität zu reduzieren."
Und wenn dem so sein sollte, dann stelle ich bezüglich eines jeden Ansatzes mit Verschlagwortung und/oder Datenbank folgende Fragen:
1. Wie wird eine Suche mit regulären Ausdrücken realisiert? ("LIKE %" kann viel weniger und nutzt zudem den binären Indexzugriff nicht, ist also langsam.)
2. Wie wird eine Suche nach Teilworten realisiert, die kein Präfix eines Schlagwortes sind?
3. Wie wird eine Suche nach Phrasen realisiert, die Teilworte enthalten? (Das Verfahren, welches Andreas vorgeschlagen hat, findet m. E. *nicht* die Zeichenkette "efan Mün".)
4. Wie wird eine Suche nach "intelligenten Umlauten" (Münz => Muenz oder Münz) realisiert? (Das ist ggf. äquivalent zu 1.)
5. Wie wird eine Suche optional mit oder ohne Berücksichtigtung von Wortgrenzen realisiert?
6. Wie wird eine Suche optional mit oder ohne Berücksichtung von case-Sensitivität realisiert?
Dies alles kann das derzeitige Such-Skript, weil seine Suchtechnik bewußt auf Volltextindex ausgelegt ist - und *dort* geht all dies mit regulären Ausdrücken ziemlich einfach (wenn auch nicht beliebig performant).
-
Moin nochmal,
-
Wie wird eine Suche mit regulären Ausdrücken realisiert? ("LIKE %" kann viel weniger und nutzt zudem den binären Indexzugriff nicht, ist also langsam.)
-
Wie wird eine Suche nach Teilworten realisiert, die kein Präfix eines Schlagwortes sind?
-
Wie wird eine Suche nach Phrasen realisiert, die Teilworte enthalten? (Das Verfahren, welches Andreas vorgeschlagen hat, findet m. E. *nicht* die Zeichenkette "efan Mün".)
-
Wie wird eine Suche nach "intelligenten Umlauten" (Münz => Muenz oder Münz) realisiert? (Das ist ggf. äquivalent zu 1.)
-
Wie wird eine Suche optional mit oder ohne Berücksichtigtung von Wortgrenzen realisiert?
-
Wie wird eine Suche optional mit oder ohne Berücksichtung von case-Sensitivität realisiert?
bei der case-Sensitivität könnte man sich noch behelfen, indem alle Begriffe z.B. grundsätzlich nur mit Kleinbuchstaben im Hash abgelegt werden. Auch mit den Umlauten könnte es gehen: Das Suchskript könnte auf Wunsch aus dem Wort "Münz" die Versionen "Münz" und "Muenz" generieren und nacheinander nach beiden Worten suchen. Bei regulären Ausdrücken usw. sehe ich dagegen gewisse <g> Probleme. Auch für die Teilworten kann ich keine schnelle Lösung erkennen. Allerdings schaffen Suchdienste wie Altavista usw. das mit regulären Ausdrücken usw. auch nicht (oder etwa doch??) - möglicherweise muß man hier zwecks besserer Performance einen Kompromiß machen. Ich muß aber auch sagen, daß ich selber das Suchfeature mit den regulären Ausdrücken noch nie benutzt habe, abgesehen davon, daß die Benutzer der Suchfunktion zu einem vermutlich großen Teil noch nie mit regulären Ausdrücken gearbeitet haben. Bin mal gespannt, was bei der Diskussion letztlich herauskommt...
Bis dannundwann
Andreas
-
bei der case-Sensitivität könnte man sich noch behelfen, indem alle Begriffe z.B. grundsätzlich nur mit Kleinbuchstaben im Hash abgelegt werden.
Was soll das nützen? Ich will doch aber manchmal gerade "Muenz" und "muenz" unterscheiden können ...
Auch mit den Umlauten könnte es gehen: Das Suchskript könnte auf Wunsch aus dem Wort "Münz" die Versionen "Münz" und "Muenz" generieren und nacheinander nach beiden Worten suchen.
Das führt dazu, daß andere Suchabfragen - nämlich solche, die *keine* intelligenten Umlaute verwenden wollen - falsche Treffer bekommen.
Allerdings schaffen Suchdienste wie Altavista usw. das mit regulären Ausdrücken usw. auch nicht (oder etwa doch??) - möglicherweise muß man hier zwecks besserer Performance einen Kompromiß machen.
Eben diese Ausrichtung sollte über der aktuellen Diskussion in Richtung mSQL nicht unter den Tisch fallen. Ich will nicht (zu sehr) darüber diskutieren, ob ich einen Hammer oder einen Schraubenzieher verwenden will, wenn ich noch nicht weiß, was ich damit wie bearbeiten soll.
Ich muß aber auch sagen, daß ich selber das Suchfeature mit den regulären Ausdrücken noch nie benutzt habe, abgesehen davon, daß die Benutzer der Suchfunktion zu einem vermutlich großen Teil noch nie mit regulären Ausdrücken gearbeitet haben.
Ich seit der Einführung von AND und NOT auch nicht mehr - und ich hoffe, es geht vielen Anwendern genauso. ;-)
-
bei der case-Sensitivität könnte man sich noch behelfen, indem alle Begriffe z.B. grundsätzlich nur mit Kleinbuchstaben im Hash abgelegt werden.
Was soll das nützen? Ich will doch aber manchmal gerade "Muenz" und "muenz" unterscheiden können ...
...ist doch ganz einfach: Bei case-sensitiver Suche wird in den gefundenen Beiträgen das Wort eben nochmal gesucht - und zwar diesmal case-sensitiv...
Auch mit den Umlauten könnte es gehen: Das Suchskript könnte auf Wunsch aus dem Wort "Münz" die Versionen "Münz" und "Muenz" generieren und nacheinander nach beiden Worten suchen.
Das führt dazu, daß andere Suchabfragen - nämlich solche, die *keine* intelligenten Umlaute verwenden wollen - falsche Treffer bekommen.
dazu bräuchte das Suchformular einen entsprechenden Auswahl-Schalter.
Eben diese Ausrichtung sollte über der aktuellen Diskussion in Richtung mSQL nicht unter den Tisch fallen. Ich will nicht (zu sehr) darüber diskutieren, ob ich einen Hammer oder einen Schraubenzieher verwenden will, wenn ich noch nicht weiß, was ich damit wie bearbeiten soll.
Ich kann mir auch nicht vorstellen, daß man in einer SQL-Datenbank abgelegte Begriffe mit regulären Ausdrücken effizient suchen kann. Falls das doch geht, lasse ich mich gerne vom Gegenteil überzeugen.
Ich muß aber auch sagen, daß ich selber das Suchfeature mit den regulären Ausdrücken noch nie benutzt habe, abgesehen davon, daß die Benutzer der Suchfunktion zu einem vermutlich großen Teil noch nie mit regulären Ausdrücken gearbeitet haben.
Ich seit der Einführung von AND und NOT auch nicht mehr - und ich hoffe, es geht vielen Anwendern genauso. ;-)
Dann fällt das "wegfallen" ja gar nicht weiter auf ;-)
Bis dannundwann
Andreas
-
-
-
-
Hallo Andreas und Michael.
Performancemäßig ist das eine super Idee.
Leider hat sie einen kleinen Schönheitesfehler, der jedoch zu verschmerzen sein dürfte: Je genauer die Suche eingegrenzt wird, d.h. mit je mehr Suchbegriffen das gewünschte Ergebniss eingegrenzt wird, desto länger dauert die Suche. Dem Suchenden wird dies möglicherweise nicht gleich einleuchten. Doch auf die Faulheit der Menschen bauend, gehe ich davon aus, daß niemals mehr als eine Handvoll Suchbegriffe eingegeben werden. Damit dürften die Antwortzeiten noch immer deutlich unter den jetzigen/künftig zu erwartenden liegen.
Ganz wichtig ist für die Geschwindigkeit natürlich der Range des Hashes. Der darf auf keinen Fall zu klein gewählt werden. Dann dann würden die Indexdateien wieder zu groß werden. Die gescheite Aufteilung der Dateien auf Directories ist ebenfalls von elementarer Bedeutung. Also kurz gesagt, mit einem gescheiten Hash steht und fällt alles. Dabei muß von vorneherein vor allem auf Zukunft gebaut werden.
Den Schwanzabschneider würden wohl in der Tat die größten Änderungen treffen. Und seine Laufzeit wird deutlich steigen. Das sehe ich auch so. Mit geschickter Codierung kann man natürlich erreichen, daß während der Archivierung jedes Indexfile nur einmal angefaßt wird. Trotzdem werden die vielen Filezugriffe Zeit kosten. Während dieser Zeit muß das Forum unbedingt gegen Schreibzugriffe geperrt sein.Es wäre einfach einmal auszutesten, wie sehr die Laufzeit ansteigt. Zumindest ist hier mit steigender Archivgröße wenigstens nicht auch mit wesentlich steigender Laufzeit des Schwanzabschneiders zu rechnen. Der Schwanzabschneider sollte also letzlich nicht das Problem sein.
Das Problem sehe ich vielmehr im Plattenplatz. Mal eben ein paar GB werden Stefan mit Sicherheit nicht zur Verfügung stehen. Und wer die Preise für Webspace kennt, kann sich auch ausrechnen, was soetwas regulär kosten würde. So verlockend dieser Ansatz ist, ist er wohl nur mit einem großzügigen Sponsor zu realisieren. Schade.
Viele Grüße
Kess-
Je genauer die Suche eingegrenzt wird, d.h. mit je mehr Suchbegriffen das gewünschte Ergebniss eingegrenzt wird, desto länger dauert die Suche.
Das ist auch bisher schon so.
Allerdings: Wenn der erste Suchbegriff gut projeziert, dann werden die zusätzlichen Vergleiche mit weiteren Suchbegriffen nur noch für die Treffer des ersten Suchbegriffs durchgeführt.
Und da nach meiner Erfahrung *kein* Suchbegriff mehr als 20% Treffer erzielt, sind die zusätzlichen Abfragen ziemlich erträglich. Will sagen: Niemand sollte Angst davor haben, seine Suche so exakt wie möglich zu spezifizieren!Doch auf die Faulheit der Menschen bauend, gehe ich davon aus, daß niemals mehr als eine Handvoll Suchbegriffe eingegeben werden.
Aber wenn es dort passiert, dann ist mir das lieber, als wenn der Anwender sich erst mit vielen nacheinander durchgeführten Suchvorgängen an sein Ziel herantasten und die Treffermenge einschränken muß. *Das* dauert nämlich noch länger, und es frustriert außerdem die Anwender.
Also kurz gesagt, mit einem gescheiten Hash steht und fällt alles. Dabei muß von vorneherein vor allem auf Zukunft gebaut werden.
Yep. Ich würde so etwas auf 3-5 Jahre dimensionieren, also für Faktor 5-10 des heutigen Archiv-Volumens. (Stefan: Wie lange reicht denn der teamone-Server überhaupt noch, wenn wir einfach gar nichts ändern? Wieviel Platz hast Du dort?)
Mit geschickter Codierung kann man natürlich erreichen, daß während der Archivierung jedes Indexfile nur einmal angefaßt wird.
Darüber habe ich mir schon eine Weile den Kopf zerbrochen.
Bei einem Vollindexer geht es einfach nicht (der müßte entweder alles im Speicher halten oder tausende von file handles parallel bedienen dürfen - für beides ist der Server wohl zu klein); bei einem inkrementellen Indexer wie im Schwanzabschneider ist Methode 1 (alles im RAM) machbar.Trotzdem werden die vielen Filezugriffe Zeit kosten. Während dieser Zeit muß das Forum unbedingt gegen Schreibzugriffe geperrt sein.
Das ist auch heute schon so - Zitat: "Bahnschranke". Ansonsten würden verschiedene Prozesse gleichzeitig in der Forumshauptdatei herumschreiben ...
Das Problem sehe ich vielmehr im Plattenplatz. Mal eben ein paar GB werden Stefan mit Sicherheit nicht zur Verfügung stehen.
Eben deshalb habe ich ja versucht, den vielen Speicherplatz "billig" zurück in Zeit zu tauschen, auf Kosten von vielen, vielen Dateizugriffen.
Wenn man
1. das, was bisher in einer Zeile der Indexdatei steht, in eine Datei eines Hash-Verzeichnis-Baums schreibt,
2. in der bisher angedachten neuen Index-Hash-Struktur nur einen *Verweis* auf diese Datei einfügt und
3. pro Indexzeilenlesen also eine zusätzliche (kleine) Datei einliest,
dann belegt diese kombinierte Lösung 'nur unwesentlich' mehr Platz als die bisherige (also jedenfals nicht 200 mal so viel):
a) Die Postings werden wieder nur einmal abgelegt,
b) zusätzlich entsteht eine separate Indexstruktur mit Verweisen, die Posting nur ca. 30 Bytes groß ist, aber jedes Posting ca. 100 mal referenziert.
Bei 50000 Postings wäre diese Struktur derzeit insgesamt 150 MB groß und würde im selben Tempo weiter wachsen wie das (etwa halb so große) Archiv.
Vielleicht kann man diese 30 Bytes durch effiziente Kompimierung auf 20 oder so drücken - wiederum auf Kosten von Zeit zur Codierung (Indexer) und Decodierung (Sucher), natürlich ...Dies wäre dann äquivalent zu CREATE INDEX in SQL. Insgesamt würden wir Faktor 5 an Speicherplatz bezahlen, um näherungsweise logarithmische Suchzeiten zu erhalten - das sieht rentabel aus.
(Nebenbei: Etwa dieselben Größenwerte würden wir auch mit einer SQL-Datenbank erhalten - die kann ja auch nicht zaubern, sie würde uns lediglich die Codierung der ganzen Indexzugriffe abnehmen.)Durch die vielen zusätzlichen Dateizugriffe existiert ein hoher "Sockeleffekt", d. h. der relative Gewinn der Suchzeit wird zwar mit zunehmender Größe des Archivs immer größer, aber erst ab einer bestimmten "kritischen Masse" überhaupt eintreten.
Ich wollte, ich könnte auch nur annähern abschätzen, für welche n
sockelfaktor * O(log (n)) <= O(n)
ist ... davon hängt nämlich *alles* ab.
Wenn n für eine "Datenbanklösung" so groß sein muß, daß der Server darunter dann in jedem Fall zusammenklappt, dann haben wir einfach verloren.-
Bei einem Vollindexer geht es einfach nicht (der müßte entweder alles im Speicher halten oder tausende von file handles parallel bedienen dürfen - für beides ist der Server wohl zu klein); bei einem inkrementellen Indexer wie im Schwanzabschneider ist Methode 1 (alles im RAM) machbar.
Ich sprach an dieser Stelle nur vom Schwanzabschneider. Daß der erstaufbau der Index-Files nicht nach diesem Prinzip arbeiten kann, ist klar. Der startet im Idealfall aber nur ein einziges mal.
Das Problem sehe ich vielmehr im Plattenplatz. Mal eben ein paar GB werden Stefan mit Sicherheit nicht zur Verfügung stehen.
Eben deshalb habe ich ja versucht, den vielen Speicherplatz "billig" zurück in Zeit zu tauschen, auf Kosten von vielen, vielen Dateizugriffen.
Hierüber grübele ich nun schon den ganzen Tag. Irgendwas hatte mich heute morgen noch gestört. Aber die Arbeit geht vor. Inzwischen hat es allerdings 'Klick' gemacht. Bei der Berechnung gehst Du davon aus, für jedes Wort, den gesamten Inhalt des Postings zu integrieren. Das ergibt natürlich solch imense Datenmengen. Aber so ist das gar nicht gedacht. Die Indexfiles enthalten ausschließlich Schlagworte. und die Verweise auf die entsprechenden Archivdateien, in denen das Wort enthalten ist. Damit dürfte der Index
vielleicht auf die doppelte Größe anwachsen, aufgeteilt auf viele Files. Aber mehr auch nicht.Durch die vielen zusätzlichen Dateizugriffe existiert ein hoher "Sockeleffekt", d. h. der relative Gewinn der Suchzeit wird zwar mit zunehmender Größe des Archivs immer größer, aber erst ab einer bestimmten "kritischen Masse" überhaupt eintreten.
Jepp. Aber da die Index-Files sehr klein sind, sind sie auch schnell geladen. <Behauptung> Der Effekt dürfte sich be der derzeitigen Größe von 40 MB bereits sofort bemerkbar machen. </Behauptung>
Viele Grüße
Kess -
Hallo Michael
Stefan: Wie lange reicht denn der teamone-Server überhaupt noch, wenn wir einfach gar nichts ändern? Wieviel Platz hast Du dort?
Wir haben hier 20MB Festplattenspeicher laut Vertrag von 1996. Belegen tuen wir derzeit das Zehnfache. Eine Vertragsaenderung hat es deshalb noch nicht gegeben. Noch Fragen? <g>
Koennen wir denn mal festhalten, dass derzeit eine Loesung favorisiert wird, die ohne externe Datenbank und nur mit Perl auskommt, und bei der der einzige aus organisatorischer Sicht kritische Faktor der Plattenspeicher ist? Ich rede dann naechste Woche mal mit dem Provider. Plattenspeicher ist ja heute eigentlich kein Thema mehr. Zur Not kriegt er ein Dauerbanner auf der Einstiegsseite von Selfaktuell (ja ja, der Muenz denkt um <g>), und dafuer will ich 1 GB. Mal gucken.
viele Gruesse
Stefan Muenz
-
-
-
Moin Michael und Moin Forum,
Allerdings wird der Index auf diese Weise dann
trotzdem insgesamt *sehr* viel größer als bisher. Denn das Format (und damit das Volumen) eines Indexeintrages ändert sich ja zunächst einmal nicht, und ein Posting mit 200 Worten kann (und sollte, wenn die Hash-Funktion etwas taugt!) sehr wohl simultan in 200 verschiedenen Indexdateien eingetragen werden!
Der Index wird dann also um Faktor 200 größer, und der Indexer wird wesentlich langsamer - das ist der Preis für die schnellere Suche. (Haben wir 8 GB auf der Platte verfügbar? Tendenz steigend! Die Profis haben natürlich fette Server ...)Das verstehe ich jetzt aber nicht so ganz: Es sollen ja nicht mehr die kompletten Postings abgelegt werden sondern nur noch links darauf. Eine Indexdatei könnte z.B. wie folgt aussehen:
webserver, 1314, a1
webserver, 4234, a1
webserver, 4234, a2
webserver, 4234, a7
webserver, 30234, a4
nappsülze, 24542, a1
...also: { Begriff, Nummer der Archivdatei, Sprungmarke (Anker) }
(Wobei hier vorausgesetzt wurde, daß "nappsülze" zufällig den gleichen Hash-Wert
bekommt wie "webserver" ;-))Wenn weitere Dateien ins Archiv hinzugenommen werden, reicht es völlig aus,
die jeweiligen Index-Dateien im 'Append'-Modus zu öffnen und die neuen Einträge
hinten dranzuhängen. Also nix mit Index jedesmal komplett neu generieren...Die 10000 (oder wieviele auch immer) Indexdateien werden natürlich etwas mehr Platz beanspruchen als die alte Indexdatei - Faktor 3-4 dürfte es schon sein, aber Faktor 200 scheint mir etwas zu hoch gegriffen...
Bis dannundwann!
Andreas
-
Der Index wird dann also um Faktor 200 größer, und der Indexer wird wesentlich langsamer
Das verstehe ich jetzt aber nicht so ganz: Es sollen ja nicht mehr die kompletten Postings abgelegt werden sondern nur noch links darauf.
Die 10000 (oder wieviele auch immer) Indexdateien werden natürlich etwas mehr Platz beanspruchen als die alte Indexdatei - Faktor 3-4 dürfte es schon sein, aber Faktor 200 scheint mir etwas zu hoch gegriffen...Diese zusätzliche Indirektion hatte ich Deinem ersten Ansatz nicht entnommen - und sie kostet ja nun mal auch einige hundert fopen() pro Suchvorgang, statt dem bisherigen linearen Lesen einer einzigen Inedxdatei.
In einem anderen Posting dieses Threads habe ich das mal durchgerechnet - und kam ebenfalls auf Faktor 3-5 für den kompletten Indexbaum.-
Der Index wird dann also um Faktor 200 größer, und der Indexer wird wesentlich langsamer
Das verstehe ich jetzt aber nicht so ganz: Es sollen ja nicht mehr die kompletten Postings abgelegt werden sondern nur noch links darauf.
Die 10000 (oder wieviele auch immer) Indexdateien werden natürlich etwas mehr Platz beanspruchen als die alte Indexdatei - Faktor 3-4 dürfte es schon sein, aber Faktor 200 scheint mir etwas zu hoch gegriffen...Ups, da steht es ja schon, worüber ich mir an anderer Stelle den Kopf zerbrochen habe. Naja ... vielleicht sollte ich mir angewöhnen, doch erst den ganzen Thread zu lesen, bevor ich etwas poste.
Nimmt man eine Verweisliste je Schlagwort anstelle je eines Eintrages pro Posting, in dem das Schlagwort vorkommt, dann dürfte sich der Faktor auf etwa 2 reduzieren. Der Schwanzabschneider hätte dabei etwas mehr Arbeit, da er nicht mit append arbeiten kann, sondern einfügen muß. Dafür muß ein Suchlauf nicht die ganze Datei scannen, sondern kann mit Auffinden des gesuchten Wortes den Lesevorgang für das betreffende Wort abbrechen.
Diese zusätzliche Indirektion hatte ich Deinem ersten Ansatz nicht entnommen - und sie kostet ja nun mal auch einige hundert fopen() pro Suchvorgang, statt dem bisherigen linearen Lesen einer einzigen Inedxdatei.
Bitte ? Einige hundert fopen() pro Suchvorgang ? Dem kann ich nicht folgen. Pro Suchbegriff wird exakt eine Indexdatei geöffnet. Einzig bei der Phrasensuche kommen noch die Zugriffe auf die Threaddateien aus der Schnittmenge der Treffer im Index hinzu.
Viele Grüße
Kess-
Moin nochmal!
Nimmt man eine Verweisliste je Schlagwort anstelle je eines Eintrages pro Posting, in dem das Schlagwort vorkommt, dann dürfte sich der Faktor auf etwa 2 reduzieren. Der Schwanzabschneider hätte dabei etwas mehr Arbeit, da er nicht mit append arbeiten kann, sondern einfügen muß. Dafür muß ein Suchlauf nicht die ganze Datei scannen, sondern kann mit Auffinden des gesuchten Wortes den Lesevorgang für das betreffende Wort abbrechen.
Faktor 2 würde ich auch schätzen, zumal einfache Wörter wie "und" oder "Schwanzabschneider" pro Artikel mehrfach vorkommen können und dann für den jeweiligen Artikel nur einmal gelistet werden müssen. Ich verstehe aber nicht, warum der Schwanzabschneider nicht inkrementell d.h. mit Append arbeiten können soll. Die Einträge aus den neu hinzugekommenen Archivbeiträgen können doch einfach hinten an die jeweiligen Index-Dateien angehängt werden - nebenbei bewirkt dies, daß die Suchergebnisse nach wie vor in chronologischer Reihenfolge ausgegeben werden (könnte man dann in der Antwortseite noch umdrehen, so daß die aktuellsten Antworten immer oben erscheinen).
Bitte ? Einige hundert fopen() pro Suchvorgang ? Dem kann ich nicht folgen. Pro Suchbegriff wird exakt eine Indexdatei geöffnet. Einzig bei der Phrasensuche kommen noch die Zugriffe auf die Threaddateien aus der Schnittmenge der Treffer im Index hinzu.
Genau - auch bei Kontrolle auf Groß/Kleinschreibung usw. wären noch ein paar zusätzliche Zugriffe nötig - unter Umständen können da natürlich schon mal 100 oder mehr fopen() zusammenkommen, was aber immer noch deutlich schneller sein sollte als die bisherige Methode...
Bis dannunwann
Andreas
-
-
-
-
Ich hab mir mal folgendes überlegt, was man wunderbar mit ner Datenbank machen könnte. Einmal ne ganz normale Tabelle mit folgenden Eintraegen:
Nummer-Autor-Datum-Subject-Text
Da kann man schon mal prima nach Subject suchen, und nach Autor und Datum. Nur ne Suche nach Text wird langsam. Deswegen machen wir noch ne 2. Tabelle. Wir schreiben jedes Wort, das in nem Beitrag vorkam, in ne extra Zeile. Und daneben die Nummer, in welchem Beitrag es vorkam. Das Feld mit dem Wort belegen wir mit nem Index. Dann können wir sehr schnell mit Select Nummer from Woerter where Wort = "Stefan"; nach dem Beitrag suchen, und wir müssen auch fast nix programmieren. Also geringer Aufwand.
Das verbraucht natürlich viel an Plattenplatz. Aber wenn wir dem Provider nen schönen SQL-Server einrichten, den dann auch andere seiner Kunden benutzen können, wird er uns den Plattenplatz wohl geben.
-
-
-
Ich habe das starke Gefühl, daß hier zuerst über den Algorithmus diskutiert wird, ohne über die Dienstleistung nachzudenken.
Wieviel vom bisherigen Suchverfahren soll denn aufgegeben werden? regular expressions mit einer SQL-Datenbank? Volltextsuche mit einer SQL-Datenbank? Ich sehe irgendwie keine auch nur vage Ähnlichkeit zu dem bestehenden Suchverfahren.Gerade bei regulären Ausdrücken nützt uns die gesamte Datenbank inklusive Indexbäumen nichts, und auch "Volltext" und "DB-Index" widersprechen einander m. E. ziemlich fundamental.
Stell Dir einfach vor, ein Indexeintrag müßte so lang werden können wie ein komplettes Posting - wie groß würde da wohl der Index werden, wenn er auch noch *jeden* Teilstring enthalten sollte? (Denn tut er das nicht, dann muß er wieder linear durchsucht werden, und die ganze schöne logarithmische Suchdauer ist beim Teufel.)
Das riecht nach exponentieller Größe (es wird ja einfach Zeit mit Platz erkauft), und das halten wir bei diesen Datenmengen nicht aus. Wir brechen ja schon unter einer linear wachsenden Datenmenge zusammen.
Wieviele Gigabytes darf unsere mSQL-Datenbank denn auf dem Server belegen?Hallo,
Das Zauberwort SQL hilft da schon, nur mußt du lernen umzudenken. Ich weiß nicht wie gut du dich in der Syntax von SQL auskennst. Aber im Prinzip ist das ziemlich einfach.
Du hast folgende felder in der DB:
ID, Datum, Verfasser, Email, Subject (ohne RE:), Bodywird nach etwas gesucht kann man gleich eines oder mehrere subjects auswählen. zb:
SELECT * FROM archiv WHERE body LIKE '%suchbegriff%' AND subject='HTML';Fertig, mehr ist das nicht, eine kleine Routine noch um die nachrichten samt wurm anzuzeigen fertig. (also in der form <a href=.....php3?id=3>...
In php3 wäre das eine Arbeit von ca. 2h - 4h nur ist php3 installiert?
Das Problem mSQL ist schon ein größerers. msql ist nur eine sehr bescheidene form von SQL die auch nicht den gesamten SQL sprachsatz drauf hat. Man müsste den Prov davon überzeugen mysql zu installiern (ist für den nichtkomerziellen einsatz gratis, was ja selfhtml ist)
das Problem USER in dem mSQL verzeichnis gibt es eine config datei auf der man den zugriff für jeden user expliziet angeben kann. Das ist also wirklich kein maleur.
lg
Ludwig-
SELECT * FROM archiv WHERE body LIKE '%suchbegriff%' AND subject='HTML';
Fertig, mehr ist das nichtNichts davon dürfen wir verwenden!
Wenn wir mit % und LIKE arbeiten, kann das RDBMS keine Indexbäume mehr verwenden und schaltet auf full table scan. Das ist dann exakt das, was bereits die Perl-Lösung tut, und genau so langsam - eher noch viel langsamer, weil die Datenbank eine Menge Overhead produziert, den das Skript nicht braucht.
Nein, so einfach ist die Sache nicht. Entweder regular expressions oder Indexbäume, denke ich.Das einzige, was wir bei SQL gewinnen sofort, ist, daß das RDMBS mit rekursiven Ausdrücken umgehen kann, weil es die Zwischenergebnisse cached und joint. Das ist aber nicht die Aufgabenstellung.
Das Problem mSQL ist schon ein größerers. msql ist nur eine sehr bescheidene form von SQL die auch nicht den gesamten SQL sprachsatz drauf hat.
Aha. So etwas hatte ich befürchtet.
Dann halte ich mich vom Entwurf der Datenbankstrukturen schon mal fern, weil ich Oracle gewohnt bin, und *das* kann viel ...
-
-
Huhu Loits!
Sorry, leider hab ich heute nicht so viel Zeit, den ganz Thread durchzulesen, deshalb nur mal schnell meine humble opinion hierher geschmissen...
Gerade bei regulären Ausdrücken nützt uns die gesamte Datenbank inklusive Indexbäumen nichts, und auch "Volltext" und "DB-Index" widersprechen einander m. E. ziemlich fundamental.
Yoh, und gerade regulaere Ausdruecke und Suchen nach ganzen Phrasen helfen mir beim Wiederfinden eines Postings oft am meisten (da ich mich z.B. an irgendeine bestimmte Redewendung oder sonstwas erinnere).
Bei einem Schlagwortindex würde ich eine relationale Datenbank prima finden, das hatte ich ja schon geschrieben. Aber bei einer Volltextsuche ... hm ...
Nun, koennen wir nicht beides machen und das Script entscheidet je nach Anforderung, welchen Datenbestand (DB oder Textfile) es durchsucht? Braucht natuerlich dann Platz fuer DB *und* File auf dem Server. Weiss nicht, ob wir uns das leisten koennen.
Beispielsweise könnte man den Index genauso in mehrere Dateien zerlegen wie das Archiv in mehrere Verzeichnisse, und dann wäre es die Entscheidung des Anwenders, wieviele Kreuzchen er im Suchformular macht. Macht er zuviele, dann wird es halt wirklich langsam - und über einen geeigneten timeout-Wert im Webserver (!) wird die Suche dann halt abgebrochen werden. (Man könnte ein Verzeichnis für Indexdateien auf dem Server scannen, daraus diese Auswahlfelder im Formular dynamisch generieren, dabei die Größe des jeweiligen Indexes in MB einblenden
Und aus den Dateinamen der Files generiert man die Bezeichnung, die dann z.B. ein bestimmtes Quartal widerspiegelt. Ich finde die Idee gut. Ein Suche mit Zeitraumbeschraenkung haette mir auch schon mehrmals geholfen.
So, das war's schon von mir, have a nice weekend, man sieht sich
P.S. Michael: Mailantwort kommt noch... ;-)
-