nicht angemeldet
Indexerstellung bei großen Datenbanken und Performance
Hallo erstmal!
Was ist eine Indexerstellung?
Unter "Indexerstellung" stelle ich mir vor, dass ein Index alle 10 minuten aktualisiert wird, um den Server zu entlasten. Der Index enthält in meinem Falle die artikel für eine Auktion. Es wäre sehr unnütz und performance-lastig wenn für jeden User bei jedem klick die Datenbank neu durchforstet werden würde und unnötigen Traffic verursacht.
Welche Arten der Indexerstellung habe ich bis jetzt überprüft?
1.
Alle 10 Minuten werden alle Artikel einmal in ein Array geschrieben. Dieses Array wird sortiert (wonach es sortiert wird ist nicht weiter wichtig...) und dann werden Teile des Arrays (nämlich die Artikel die auf die Kategorie sowie Subkategorie zutreffen) in eine eigene Datei geschrieben. Dann wird eine index.php erstellt die , dann dementsprechend die Artikel der Kategorie und Subkategorie included.
2.
In diesem Falle werden für jede bedenkliche Art eine statische html-Datei erstellt. Es gibt 3 sortierungsartung, also 6 (auf + absteigend) verschiedene Indexe. Hier entfällt im gegensatz zu der ersten Methode also die PHP-Rechenzeit.
Es ist mir klar, dass die Unterschiede bei kleinen Datensätzen gleich Null ist, aber wenn man 1 Mio. Datensätze hat, könnte das wahrscheinlich schon einen Unterschied machen....
Was für Methoden gibt es noch? Was haltet ihr von meinen Methoden?
-
Hi,
Was ist eine Indexerstellung?
im Kontext einer relationalen Datenbank verstehe ich darunter, einen Indexbaum über eine Menge von Spalten einer Tabelle aufzubauen.
Unter "Indexerstellung" stelle ich mir vor, dass ein
Index alle 10 minuten aktualisiert wird, um den
Server zu entlasten.Ich finde, gerade ein solches Verhalten würde den Server in den meisten Fällen eher be- als entlasten.
Denn warum solltest Du alle 10 Minuten dasselbe tun, was im vorherigen Durchgang auch schon zum richtigen Ergebnis geführt hat?Das hängt natürlich ein wenig von Deinen konkreten Daten ab. Aber in den meisten Fällen wirst Du relativ wenige Änderungen innerhalb Deines Datenvorrats haben - und in diesem Falle ist es günstiger, den Index inkrementell zu pflegen, d. h. während jeder INSERT-, UPDATE bzw. DELETE-Operation den entsprechenden Eintrag des Indexbaums gleich mit anzupassen.
Der Index enthält in meinem Falle die artikel für
eine Auktion. Es wäre sehr unnütz und performance-
lastig wenn für jeden User bei jedem klick die
Datenbank neu durchforstet werden würde und
unnötigen Traffic verursacht.Das verstehe ich nicht. Der Sinn eines Indexbaums ist doch gerade, daß der Benutzer eben _nicht_ die _gesamte_ Datenbank durchforstet, sondern mit einer logarithmischen Anzahl von Zugriffen innerhalb des Indexbaums den richtigen Datensatz findet.
Alle 10 Minuten werden alle Artikel einmal in ein
Array geschrieben. Dieses Array wird sortiert
(wonach es sortiert wird ist nicht weiter
wichtig...) und dann werden Teile des Arrays
(nämlich die Artikel die auf die Kategorie sowie
Subkategorie zutreffen) in eine eigene Datei
geschrieben. Dann wird eine index.php erstellt,
die dann dementsprechend die Artikel der Kategorie
und Subkategorie included.Der Array nützt Dir wenig, weil Du in ihm selbst keinen schnellen Zugriffspfad hast. (Es sei denn, Du implementiert auf diesem Array eine binäre Suche durch Halbierung des betrachteten Intervalls, simulierst also einen binären Baum mit diesem Array.)
Wenn Du den Array aber gleich durch einen (binären) Baum ersetzt, macht die Sache mehr Sinn - doch wie gesagt: Ein ständiger Neuaufbau ist wesentlich teurer als eine inkrementelle Änderung.In diesem Falle werden für jede bedenkliche Art
eine statische html-Datei erstellt. Es gibt 3
sortierungsartung, also 6 (auf + absteigend)
verschiedene Indexe. Hier entfällt im gegensatz
zu der ersten Methode also die PHP-Rechenzeit.Deine Aufgabenstellung eignet sich nicht für eine eigene Implementierung. Nimm eine beliebige relationale Datenbank und laß diese machen. mySQL reicht völlig - das wirst Du mit einer eigenen Realisierung nicht schlagen können, und es besteht die Gefahr, daß Deine Lösung um mehrere Zehnerpotenzen langsamer ist.
Es ist mir klar, dass die Unterschiede bei kleinen
Datensätzen gleich Null ist, aber wenn man 1 Mio.
Datensätze hat, könnte das wahrscheinlich schon
einen Unterschied machen....Wenn Du eine Million Datensätze sortieren willst, dann brauchst Du dafür ungefähr 20 Millionen Vergleiche (n * log2(n)), aber innerhalb eines sortierten binären Indexbaums eben nur noch 20 Vergleiche zum Auffinden eines bestimmten Datensatzes.
Was für Methoden gibt es noch? Was haltet ihr von
meinen Methoden?Du bewegst Dich auf einem Feld, in dem Du bei einer eigenen Implementierung mit 30+ Jahren Erfahrung der Programmierer von RDBMS konkurrieren müßtest.
Ich kann nur wiederholen: Mach es nicht - die wissen, was sie tun. Nutze lieber deren API. Gerade wenn Du eine Million Datensätze hast.Viele Grüße
Michael
(der gerade eine Suchmaschine über eine Million News-Stories realisiert, mit einer mySQL-Datenbank)-
Hi!
erstmal vielen Dank für die antwort, aber Du hast das ein bisschen falsch verstanden, vieleicht habe ich mich auch nicht so ordentlich ausgedrückt... war ja auch schon später.
Also:
Ich rede nicht davon, die Indexierung innerhalb der Datenbank zu ändern. Ich versuche auch nicht die Datenbank zu ändern. Ich benutze mysql + PHP.Also was meine ich denn nun ;) ?
Mal gucken, ob ich das besser erklären kann.... Alle 10 minuten wird die Datenbank durchforstet und alle Artikel werden ausgespuckt. Diese werden dann nach Kategorie und Sub-Kategorie in eigene php-Dateien geschrieben die halt irgendwo liegen. Wenn ein User jetzt durch die Artikel durchsucht , schickt er also nicht jedes Mal eine Abfrage an die Datenbank, die dann den Eintrag raussucht, sondern sucht sich die daten heraus, die in dem php-file stehen.Meines Wissens macht das ebay genaus so. Erst wenn man dann auf einen Artikel klickt, und die Details sieht wird die Datenbank in Anspruch genommen.
Hoffentlich kann damit jemand mehr anfangen!
Gruß
Sui-
Hi auch,
Alle 10 minuten wird die Datenbank durchforstet und alle Artikel
werden ausgespuckt. Diese werden dann nach Kategorie und Sub-
Kategorie in eigene php-Dateien geschrieben die halt irgendwo
liegen.Ah! Du willst also einen serverseitigen Cache vor Deine Datenbank
legen - richtig?Wenn ein User jetzt durch die Artikel durchsucht , schickt er also
nicht jedes Mal eine Abfrage an die Datenbank, die dann den Eintrag
raussucht, sondern sucht sich die daten heraus, die in dem php-file
stehen.Wird diese PHP-Datei einfach nur ausgeliefert, oder wird aus ihr
wirklich noch etwas "herausgesucht"? Denn letzteres wäre per Daten-
bankzugriff wahrscheinlich sogar schneller möglich.Hoffentlich kann damit jemand mehr anfangen!
Ein Cache macht dann Sinn, wenn Du
- glaubst, sehr viele Lesezugriffe auf einen sich nur selten ändernden,
aber aufwändig zu berechnenden Inhalt zu bekommen und - damit leben kannst, daß dieser Inhalt nicht absolut echtzeit-korrekt
ist.
Beschreibt dies Dein Szenario angemessen?
Meines Wissens macht das ebay genaus so. Erst wenn man dann auf
einen Artikel klickt, und die Details sieht wird die Datenbank in
Anspruch genommen.Die Fragen, die Du Dir stellen solltest, lauten also vermutlich:
a) Habe ich wirklich so irre viele Zugriffe wie Ebay?
b) Kostet mich die Berechnung der Seite wirklich so irre viel, daß die
Implementierung eines solchen Cache-Mechanismus gerechtfertigt ist?
c) Falls b) zutrifft, kann ich an der Infrastruktur meines Datenzugriffs
etwas ändern (beispielsweise an den Indexdefinitionen der Tabellen),
um das Problem mit geringerem Aufwand in den Griff zu bekommen?Viele Grüße
Michael
(der in einem einzigen Fall schon mal einen solchen Cache realisiert hat,
weil die Berechnungsdauer im einstelligen Sekundenbereich pro Seite lag,
die Berechnung von einem black box binary realisiert wurde und die Anzahl
der Zugriffe schwer vorhersehbar war, wie aber einen provozierbaren Last-
Peak vermeiden wollten)-
Ah! Du willst also einen serverseitigen Cache vor Deine Datenbank
legen - richtig?JUHUU Jemand versteht mich :)
Wird diese PHP-Datei einfach nur ausgeliefert, oder wird aus ihr
wirklich noch etwas "herausgesucht"? Denn letzteres wäre per Daten-
bankzugriff wahrscheinlich sogar schneller möglich.Diese PHP-Datei stellt alle Daten, ein Datenbankzugriff ist nicht mehr notwendig. Sonst würde das doch alles keinen Sinn machen, oder?
Ein Cache macht dann Sinn, wenn Du
- glaubst, sehr viele Lesezugriffe auf einen sich nur selten ändernden,
aber aufwändig zu berechnenden Inhalt zu bekommen und - damit leben kannst, daß dieser Inhalt nicht absolut echtzeit-korrekt
ist.
Beschreibt dies Dein Szenario angemessen?
Ja, tut es!
Die Fragen, die Du Dir stellen solltest, lauten also vermutlich:
a) Habe ich wirklich so irre viele Zugriffe wie Ebay?Nein, natürlich nicht. Aber man sollte sich auf den Fall der Fälle vorbereiten :). Wir stellen eigentlich nur noch eine 2. Lösung für Leute, die mit vielen Zugriffen rechnen bereit.
b) Kostet mich die Berechnung der Seite wirklich so irre viel, daß die
Implementierung eines solchen Cache-Mechanismus gerechtfertigt ist?ziehe Antwort zu a
c) Falls b) zutrifft, kann ich an der Infrastruktur meines Datenzugriffs etwas ändern (beispielsweise an den Indexdefinitionen der Tabellen), um das Problem mit geringerem Aufwand in den Griff zu bekommen?
Die Indexdefinition sollten eigentlich alle in Ordnung sein, werde mich aber da noch mal mehr mit beschäftigen... Natürlich würden wir auf die cahing-methode nur zurückgreifen wenn es notwendig ist.
Aber Danke für deine Antworten!!!
Gruß
Sui-
Hi Sui,
Diese PHP-Datei stellt alle Daten, ein Datenbankzugriff ist nicht
mehr notwendig. Sonst würde das doch alles keinen Sinn machen, oder?Brauchst Du denn an dieser Stelle überhaupt noch PHP - könntest Du
nicht gleich eine statische HTML-Seite generieren? Auch PHP kostet ...Viele Grüße
Michael
- glaubst, sehr viele Lesezugriffe auf einen sich nur selten ändernden,
- glaubst, sehr viele Lesezugriffe auf einen sich nur selten ändernden,
-
-