Performance diverser Datenbansystemen

[counteam]

Hallöchen =)

Ich habe eine Grundlegende Frage, welches Datenbanksystem ich mir aneignen sollte.

Ich habe eine menge Datensätze (Derzeit bestehend aus einer Tabelle mit einem Feld "Benutzername"). Seither ist diese Tabelle auf 1 Mio. Datensätze gestiegen, einige Millionen sollen dieses noch verkraften (Für ein Community-Projekt).

Zur Info: Ich bin derzeit auf MySQL eingestellt.

Ich habe bereits in PHP eine Benutzersuche visualisiert (mit "SELECT * FROM tabelle LIKE ''%Suchwort%", nun leider dauert die Suche ein wenig, bis die ausgabe geschieht.

Jezt möchte ich gerne dies ein wenig beschleunigen, indem ich etwas herumbastle. Ich habe bereits die Seite auf einem Debian-Rootserver geparkt, da es eindeutig schneller ist (in verbindung mit Apache2) als ein ekeliger Windows-Rootserver (mit ekeligem IIS, was noch nichtmals mod-rewrite besizt).

Jezt meine Frage:
Welche Datenbank ist ambesten dazu geeignet, große Datensätze zu verarbeiten um ggf eine Suche zu ermöglichen.
Gibt es da wesentliche unterschiede in der Performance zwischen diversen Systemen alla MySQl, Postgresql oder Oracle?

Wie machen es eigendlich bekannte Seiten (Beispielsweise Google, etc)?
Wie schaffen diese es, eine derartige Datenmenge zu verarbeiten?

 

[marce]

bevor Du div. Enginges ausprobiertst solltest Du erstmal dafür sorgen, daß die DB/Tabelle an sich optimiert ist - und zwar in Struktur und Konfiguration.

und dann natürlich auch die Statements an sich - FTS ist auf jeder DB langsam.

 

[daemotron]

Ich habe eine Grundlegende Frage, welches Datenbanksystem ich mir aneignen sollte.

Das hängt vom Einsatzzweck ab - jedes hat seine Stärken und Schwächen.

Ich habe eine menge Datensätze (Derzeit bestehend aus einer Tabelle mit einem Feld "Benutzername"). Seither ist diese Tabelle auf 1 Mio. Datensätze gestiegen, einige Millionen sollen dieses noch verkraften (Für ein Community-Projekt).

Keine beunruhigende Größenordnung - damit sollten die gängigen RDBMSe fertig werden, wenn sie richtig konfiguriert sind.

Ich habe bereits in PHP eine Benutzersuche visualisiert (mit "SELECT * FROM tabelle LIKE ''%Suchwort%", nun leider dauert die Suche ein wenig, bis die ausgabe geschieht.

Ah, hier kommen wir zu des Pudels Kern. Textmustervergleiche sind teuer und daher langsam. Die meisten Engines unterstützen hier auch nicht mit entsprechender Indizierung - einzige mir bekannte Ausnahme: die MyISAM-Engine von MySQL. Hier ein bisschen Lesestoff, wie man das möglichst optimal aufbaut: http://dev.mysql.com/doc/refman/5.1/de/fulltext-search.html

Ich habe bereits die Seite auf einem Debian-Rootserver geparkt, da es eindeutig schneller ist (in verbindung mit Apache2) als ein ekeliger Windows-Rootserver (mit ekeligem IIS, was noch nichtmals mod-rewrite besizt).

Bei Debian lohnt es sich eventuell, auf das MySQL-Paket zu verzichten und die Software selbst zu kompilieren - in einigen Debian-Versionen waren die Compiler Flags und einige andere Einstellungen zu konservativ gewählt, so dass es meßbare Performance-Verluste gab. Ob das für die aktuellen Pakete noch gilt, entzieht sich allerdings meiner Kenntnis.

Welche Datenbank ist ambesten dazu geeignet, große Datensätze zu verarbeiten um ggf eine Suche zu ermöglichen.
Gibt es da wesentliche unterschiede in der Performance zwischen diversen Systemen alla MySQl, Postgresql oder Oracle?

Hängt von den Daten und der Menge ab. Für textbasierte Daten würde ich zu MySQL mit MyISAM greifen (s. o.), für Geo-Daten ist PostgreSQL im Moment einsame Spitze, und Oracle hat seine Stärken bei richtig großen DB-Setups (große SMP-Maschinen, Cluster, etc.)

Wie machen es eigendlich bekannte Seiten (Beispielsweise Google, etc)?

Ich gehe davon aus, dass dort z. B. für den Suchindex keine relationale Datenbank zum Einsatz kommt, sondern irgendwas hierarchisches. Natürlich weiß ich das nicht (werden sie mir auch nicht verraten), aber meine Vermutung stützt sich auf eine einfache Beobachtung: X.500-artige Verzeichnisdienste (z. B. OpenLDAP) können Suchanfragen auch bei riesigen Bäumen (DIT mit mehreren Millionen Leaf Nodes) in fast linearer Zeit beantworten (sofern das Backend richtig aufgebaut und der Dienst ordentlich implementiert ist). Damit das funktioniert, müssen natürlich auch die Fragen richtig gestellt sein (Subkontext für die Suche intelligent wählen, etc).

 

[Cenic]

Wenn du wie angegeben suchen willst (LIKE '%...%'), dann tun sich vermutlich erstmal alle Datenbanken schwer. Du suchst effektiv einen beliebig langen oder kurzen Ausschnitt eines Textes, der dazu noch an einer beliebigen Stelle vorkommen kann. Das ist für Oracle oder MySQL erstmal so, als wenn du im Telefonbuch alle Namen raussuchen sollst, die irgendwo ein 'ck' enthalten.

Google liefert mir bei der Suche nach 'Serversupportforum' sofort Treffer, wobei bei der Suche nach 'erversupportforu' nix kommt. Die können also auch nicht beliebige Teilstücke effizient wiederfinden.

Bei der Volltextsuche wird IMHO zumindest nach einzelnen Wörtern unterschieden, die dann eventuell normalisiert (Mehrzahl => Einzahl) und zerlegt werden, wenn es zusammengesetzte Wörter sind. Das sind Vereinfachungen, mit denen dann ein sinnvoller Suchindex angelegt werden kann.

Ohne eine passenden Index geht die Suche immer durch die ganze Tabelle. Und das benötigt I/O oder einen entsprechenden Cache und geht selbst dann noch gut in die CPU und skaliert deshalb nicht.

 

[Ben.]

Wenn du solche Abfragen planst würde ich bei dieser grossen Zahl an Datensätzen zu einem Indexserver raten.

Datenbanksysteme wie mySQL sind m.E. dafür nur bedingt geeignet.

 

[d4f]

Wie machen es eigendlich bekannte Seiten (Beispielsweise Google, etc)?

Die Google-eigene Datenbank traegt den Namen BigTable (welches als Whitepaper verfuegbar ist). Eine enge Anlehung im FOSS-Bereich findet man mit http://hbase.apache.org/ welches allerdings -wie (fast?) alle seiner Zunft- ein sog. NoSQL-System ist.