Hi

So funktioniert eine DB nicht, das ist da schon etwas geschickter geregelt. Wenn ich mein "endlich mal meine Boomarks aufräumen" ...

ich glaub euch sofort das DB nahe am optimum arbeiten, allerdings von generellen szenarien ausgehend.

Ja, und warum solte das hier kein generelles Szenario sein?

Nein, sondern genau dafür, wofür das Dingen ursprünglich gedacht war: um auf einfache Weise nachschauen zu können, ob mit einer recht genau bestimmbaren Wahrscheinlichkeit etwas gecached wurde.

Also mein Cache ist ein Hash in das ich sowieso direkt nachschaue, und statt dessen soll ich x Hashfkten eines Filters starten, der mir nur eine probalistische Aussage gibt, ob mein Wort im Cache ist???

Ja, denn das ist deutlich flexibler und es besteht auch noch die gute Möglichkeit, das der Server dabei nicht belastet wird.

Selbst ob die JS-Ausage "liegt im Cache" hilft mir _hier_ viel hilft, wenn ich im Gegenzug bei jedem Cachen den Filter aktualisieren muss?

Das mußt Du gar nicht, denn das Dingen ist fehlertolerant und es damit ist auch nicht tödlich, wenn das Dingen veraltet, denn das tut es nur direkt proportional zur Änderung im Cache.
Wie Du schon richtig festgestellt hast: das Ding arbeitet probabilistisch, die Exaktheit ist nicht wesentlich, die Masse macht's.

Ach so, du meinst nur die Ausgabe auf die Suche? das macht 1. bei Mehrwortsuche keinen Sinn, und 2. das generieren der Seite kann nicht wirklich viel teurer sein als sie fertig umzukopieren.

Das Generieren der Seite beinhaltet aber eine DB-Anfrage, fertige Seiten könnte man im RAM halten. Wird zu groß? Mal schauen:
Ich such einmal ganz doof nach "Javascript", das ergibt 100 Treffer, Maximum erreicht, er sucht sonst nirgendwo. Gut, das ist jetzt kein ideales Beispiel, das man cachen sollte, aber die Größe dürfte maximal sein: gute 90 kib, gzipped gute 20 kib. gehe ich mal ganz uveschämt von etwas aus, und zwar von 4 kib großen RAM-Kartons, dann sind das pro Seite 5, na, besser 6 Boxen, macht 24 Kib, macht runde 42 Seiten pro Emmchen. 10 Emmchen lassen sich immer irgendwo abzweigen, darin kann man also theoretisch runde 420 Seiten vorhalten. Gut, aber abzüglich der nötigen Verwaltung bestimmt immer noch rund 400 Seiten. Die 400 Top-Suchbegriffe des Vortages derart preiswert vorhalten zu können fände ich doch recht angenehm.

Das ist Microoptimierung, vergiss es schnell wieder.
(Du verbrauchst fast schon mehr Zeit diese Differenzen zu erstellen, als sie nachher gewinnen)

wieso, Integeraddition ist mit das billigste was ein Prozessor kann
(bereits früher auf dem 68000er 4 Zyklen), wenn dafür doppelt soviele Listen ins RAM passen und ich dafür sehr viele Plattenzugriffe einspare lohnt es sich extremst.

Ja, ich weiß, ich hätte mir die Klammer saren sollen, das war ja schon fast Microoptimierung bei mir.

Das eigentliche Problem ist dabei, das Deine Geschichte immer komplexer wird. Simplizität ist aber auch ein wichtiges Kriterium für einen Algorithmus, wenn er in Code umgesetzt werden soll. Da die Listen komprimiert werden können und wahrscheinlich auch sollten ist eigentlich jedem klar, sollte es zumindest sein. Das ändert aber nichts am eigentlichem Algorithmus. Erster Gedanke sollte also sein: "Gibt es einen besseren Algorithmus?" und nicht "Wie läßt sich der Algorithmus hier im Detail verbessern?". Zu "besser" kann natürlich auch "einfacher" gehören, selbst wenn es evt ein klein wenig langsamer ist.

Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.

... und schon ist das RAM voll.

nein die liegen doch auf der Platte!

Und das ist schneller?

Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.

Wie denn sonst?

ich steck da im Detail nicht drinnen wann etwas fragmentiert wird, wie die Blockgrenzen laufen, und was daraus für ein Overhead resultiert.
Wenn das alles keine Rolle spielt, gerne.

Bei so kleinen Dingern und ReiserFS kannst Du das getrost ignorieren.

Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden.  Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden

Skalierbarkeit hat hier wenig mit zu tun.

Nein, aber ich denke diese B-Bäume sind auch optimiert zum schnellen Einpflegen und organisieren sehr vieler Daten.

Ja, aber read-only sind sie alle ziemlich gleich. DB-Benchmarks kannst Du normalerweise sofort in die Tonne hauen, wenn Du nicht gerade _genau_ darauf testest, was Du nachher brauchst. Deshalb steht es in den Nutzungsbedingungen einiger DB-Hersteller sogar drin, das Du keine Benchmarks veröffentlichen darfst.

so short

Christoph Zurnieden