Hi Andreas,
Ja, das hatt ich auch schonmal gehört, da wohl temporäre
"tabellen" dann mit 20000*9000 DS erstellt werden.. oder
wie war das?
Bei
SELECT A.X, B.Y
FROM A, B
WHERE A.Z = B.Z
AND A.M = '57'
AND B.N = '42'
wird die Datenbank sinnvollerweise _zuerst_ die Teilmengen der 57er und 42er-Datensätze bilden und nur für diese das kartesische Produkt ausmultiplizieren. Das ist meistens um Größenordnungen effizienter als anders herum, falls die Spalten M bzw. N hinreichend stark projezieren.
Sollte das nicht der Fall sein, also am Ende wirklich Millionen von Treffern heraus kommen, dann hat der Benutzer das so gewollt.
Ist es dann auf der anderen Seite besser eine Abfrage zu machen
und dann in einer Schleife noch mehr Abfragen?
Je besser die Datenbank, desto überzeugter würde ich sagen: "Nein, eher das Gegenteil."
Eine gute Datenbank kann die Inhalte von M und N beispielsweise analysieren (SQL-statement 'ANALYZE TABLE') und die Information, ob diese Spalten stark projezierend sind oder nicht, separat speichern - und basierend auf diesem Wissen dann entscheiden, in welcher Reihenfolge sie die Operationen in ihren Ausführungsplan aufnimmt.
Die Entscheidung, statt einer mächtigen SQL-Query lieber eine entsprechende Verarbeitungslogik in 3GL zu bauen, ist für mich vergleichbar mit der Entscheidung, in Assembler zu programmieren statt in einer Hochsprache, weil Du dem Compiler nicht traust.
Was denn für eine Suchmaschine?
Eine Suchfunktion eines Intranet/Extranet-Produkts unserer Firma.
Woher kommen die Daten?
Von der Maschine nebenan (die keinen HTTP-Anschluß hat, sondern nur proprietäre APIs, und auch keinen Webserver haben darf, weil sie unter hoher Last Realtime-Daten annehmen muß; meine Suchmaschine wird nur mit einem snapshot von Adressierungssystemen der eigentlichen Daten geladen, die sich intraday nicht mehr ändern - die Nutzdaten ändern sich ggf. sekündlich).
Warum importierst Du immer alle und aktualisiertst nicht lediglich
die geänderten?
Weil ich dafür herausfinden müßte, was sich geändert hat, und zudem INSERT und DELETE ausführen. Und dafür dann eventuell einige hunderttausend oder gar millionen mal ein halbes Dutzend Indexbäume pro INSERT und DELETE lokal anpassen - das ist ganz schön langsam, kann ich Dir sagen.
Außerdem - eine Datenbank mit vielen Änderungen degeneriert im Laufe der Zeit ihre Indexbäume, die müßte ich dann irgendwie reorganisieren.
Das alles spare ich mir.
Was ist an "indexen" so ein Problem?
Daß sie bei Schreiboperationen mit gepflegt werden müssen - und zwar einsortierend.
Stell Dir eine Tabelle mit 10 Spalten vor, wobei auf jeder Spalte ein separater Index liegt (im Wesentlichen eine Übersetzungstabelle zwischen "Sprachen). Jetzt fügst Du einen Datensatz ein. Das ist eine Schreiboperation auf die Tabellendaten - kein Problem - und danach 10 sortierende Einfügeoperationen auf jeden der Indexbäume, also jeweils mit logarithmischem Aufwand die Einfügestelle suchen! Mach das mal mit einer Tabelle mit 15 Millionen Datensätze (log2 (15Mio) ~ 24), dann hast Du eine Schreiboperation, aber 240 Index-Lesezugriffe für jeden Datensatz! Ach ja, die 10 Schreibzugriffe für die Indexeinträge kommen auch noch dazu, ich vergaß.
(Ich habe übrigens noch einen weiteren Faktor von 20 unter den Tisch fallen lassen, der hier aber zu weit in die Logik der Anwendung führen würde.)
Die inkrementelle Methode würde mich umbringen, wenn sich plötzlich ein paar Millionen Zeilen ändern (wogegen ich gar nichts tun könnte).
Womit machst Du das alles? Wahrscheinlich mit PERL, richtig?
Ja.
Bei PHP kann mir ehrlich gesagt nicht vorstellen, dass ein Script
30 Minuten läuft, auf gehosteten Servern wird sowas eh gekillt.
Wer hat etwas von CGI gesagt?
Außerdem ist das natürlich in gewisser Weise meine eigene Maschine. (Genauer gesagt die Maschine der Webhosting-Anwendung, in welche ich die Suchmaschine eingebaut habe.)
Ist es wohl ein Problem mit PHP solche Daten zu verwalten?
Keine Ahnung - ich kann kein PHP, vor allem kein nicht-HTTP-PHP.
Aber den Datenbank-Lader würde ich bestimmt nicht über eine HTTP-Schnittstelle starten - der läuft los, sobald auf dem Nachbar-Rechner frische Adressierungsdaten angekommen sind (der wiederum wird über eine Satellitenschüssel online beliefert ...).
Viele Grüße
Michael