Extrem lange Themen werden gesplittet

Hallo zusammen!

Die Performance-Problematik bei langen Resultsets ist ein leidiges Thema, dem man nur bedingt mit passenden Indizes beikommen kann. Allein für den Pager, der die Seitenzahlen anzeigt, wird höchstwahrscheinlich eine ähnliche Query abgesetzt wie für die eigentliche Anzeige der Beiträge. Falls das so sein sollte, liesse sich an der Stelle durch separate Counter-Tables ein wenig Zeit sparen (eine Query).
Andere Datenbanksysteme sind da unter Umständen cleverer. Ich kenne mich mit der Forensoftware hier nicht aus, aber wenn die einen Datenbankabstraktionslayer mitbringt, dann wäre Oracle oder DB2 mal nen Versuch wert.
Ansonsten lässt sich auch über MySQL Clustering nachdenken, wenn das nicht bereits im Einsatz ist.

Davon ab: Diese ewig langen Threads voller Einzeiler gehen mir persönlich eh auf den Sack. NIEMAND wird je den "Was hört ihr gerade..."-Thread von Anfang bis Ende durchlesen wollen. Von mir aus könnte man im FIFO-Style in solchen Threads alles vor einem bestimmten Datum einfach wegarchivieren...


Cheers,
Dan
 
Die Performance-Problematik bei langen Resultsets ist ein leidiges Thema, dem man nur bedingt mit passenden Indizes beikommen kann. Allein für den Pager, der die Seitenzahlen anzeigt, wird höchstwahrscheinlich eine ähnliche Query abgesetzt wie für die eigentliche Anzeige der Beiträge. Falls das so sein sollte, liesse sich an der Stelle durch separate Counter-Tables ein wenig Zeit sparen (eine Query).

Den Aufwand, das zu implementieren koennen wir selbst nicht leisten - gut moeglich, dass der Hersteller der Forensoftware da irgendwann taetig wird.

Andere Datenbanksysteme sind da unter Umständen cleverer. Ich kenne mich mit der Forensoftware hier nicht aus, aber wenn die einen Datenbankabstraktionslayer mitbringt, dann wäre Oracle oder DB2 mal nen Versuch wert.

Soooo wichtig finde ich die Sache mit den langen Themen nicht, als dass wir da ernsthaft Geld in ein zweites RDBMS investieren koennen/wollen ;)

Alles andere bis auf die Volltextsuche kann MySQL sehr gut und performant.

Ansonsten lässt sich auch über MySQL Clustering nachdenken, wenn das nicht bereits im Einsatz ist.

Ist es.
 
Auf MyISAM-Tables ist der Volltextindex doch eigentlich ganz brauchbar! Oder macht ihr InnoDB? Dann wäre nämlich bei jeder Suche ein kompletter Tablescan fällig, was ich mir hier ehrlich gesagt nicht vorstellen kann...

Nein, InnoDB ist fuer ein Forum nicht wirklich vorteilhaft, im Gegenteil.

Der Fulltext-Index von MyISAM funktioniert recht gut, wenn du aber ein paar Millionen Zeilen hast, wird auch der recht traege. Groessenordnung 1-2 Sekunden fuer eine Volltextsuche ist da keine Seltenheit und fuehrt in einem Board wie diesem, in dem die Suche ueberaus gern genutzt wird, schnell mal zu richtig fiesen Lags - selbst bei einem eigenen Slave nur fuer die Suche.

Wir haben daher den gesamten Themen- und Beitragsbestand mit Sphinx[1] indexiert, jetzt ist so eine Volltextsuche ueber alle Beitraege z. B. nach 'rikman' in 25 ms erledigt (bei ~9k Ergebnisdatensaetzen).

[1] http://www.sphinxsearch.com/
 
Ah, cool. Sphinx ist da natürlich eine andere Liga. Auf Dauer sollte man Lucene (nicht die Java-Variante) im Auge behalten, vielleicht geht da noch was. Erste Experimente mit dem php-Port von Zend waren von der Funktion her vielversprechend, die Performance reicht allerdings noch nicht.
Ich denke aber, dass diese Schlacht hier auf Applikationsebene stattfinden muss... schlaueres Schema und schlauere Abfragen sparen mehr Zeit, als jedes noch so schnelle DBMS je rausholen kann.

Cheers,
D.
 
Ah, da hatte ich noch gar nicht nachgesehen... geht ja ordentlich was durch hier ;-)
Warum nicht veröffentlichen? Für potentielle Werbekunden doch sicher ein Anreiz, oder?

Later,
D.
 
Ich denke aber, dass diese Schlacht hier auf Applikationsebene stattfinden muss... schlaueres Schema und schlauere Abfragen sparen mehr Zeit, als jedes noch so schnelle DBMS je rausholen kann.
Absolut. Allerdings hat man bei wohl jeder Anwendungsentwicklung typische Szenarien im Kopf und optimiert dann in dieser Richtung -- auf Kosten anderer Szenarien. Möglicherweise dachten die vBulletin-Entwickler viel ans Editieren und weniger ans Anzeigen von Threads mit mehreren 10'000 Beiträgen. Ein Ändern des Datenmodells stellt einen so tiefen Eingriff in das System dar, dass man das kaum wartbar selbst implementieren könnte.

Trotzdem interessehalber: Wie viele verschiedene Sichtbarkeitsebenen gibt es eigentlich (mit / ohne gelöschte Beiträge / ...)? Wenn das nur wenige sind (und auch Löschen/Zusammenführen eher selten vorkommt), könnte man ja in der Tat die threadinterne Beitragsnumerierung (#36 für diesen Beitrag), statt sie jedes mal ad hoc zu berechnen, ablegen und in umgekehrter Abbildung zum direkten Zugriff nutzen. (So als Vorschlag für die vB-Entwickler ;))
 
Follow-Up to http://www.vbulletin.com/forum/ ;)

Ich denke, der Aufwand, die laufende Beitragsnummer im Thread als Spalte mit in die Daten aufzunehmen und mit einem Index fuer die Sortierung zu versehen ist und diese Spalte zu pflegen zu hoch fuer das, was man bekommt.

Jedesmal, wenn ich aus einem Thema mit 40k Posts einen Beitrag herausnehme, muss ich theoretisch die laufenden Nummern der restlichen 39,999k Posts updaten. Sicher kann man hier auch noch etwas tricksen (jedesmal +- 10 Posts aus der DB lesen um evt. "Loecher" bei der Anzeige fuellen zu koennen), aber irgendwann kommt man um eine komplette Neunummerierung nicht herum. Und das kann im laufenden Betrieb zu aergerlichen Wartezeiten fuehren.

Schlussendlich sollte man sich vor Augen halten, dass es hier um ~50 Themen von 300.000 geht - also irgendwas um 1/6 Promille ... die allermeisten Themen erfordern nicht mal ein LIMIT oder wenn, dann nur innerhalb eines Sets von < 100 Records, was einfach nicht der Rede Wert ist. :)
 
Da haste natürlich Recht. Ich fände ein generelles Limit von z.B. 1000 Beiträgen pro Thread gar nicht so verkehrt (dann wäre der Thread geschlossen). Dann würden "Teil 2" und "Teil X" bei wirklicher Relevanz wohl schon von selbst entstehen...
Der Rohloff-Thread ist ein Beispiel für eine grosse Know-How-Sammlung geworden, die in einem einzigen, unübersichtlichen Thread lebt. Einzelne Themen wären echt schlauer gewesen.... aber das ist halt "Erziehungssache" ;-)

Cheers,
D.
 
War das Teilen eigentlich erst einmal eine einmalige Aktion oder werdet Ihr nun regelhaft ab 5000 Beiträge die entsprechenden Threads zumachen ?

Unser Thread ist nämlich auch bald soweit und falls zweiteres zutrifft, hätten wir wenigstens noch genügend Zeit ein nettes Eingangsstatement für den zweiten Teil unseres Threads zu kreieren.

Grüße

Google
 
Wird denn von den Admins in den alten Threads rechtzeitig gepostet, dass getrennt wird? Das würde ich fair finden, dann kann man den neuen Thread entsprechend planen... Nicht, dass mit mal unser Thread weg ist!!!

Grüße
 
Macht doch die Trennung einfach selber und sagt dann einem Mod bescheit, damit er den alten Thread schließt. So könnt ihr selber bestimmen wann getrennt wird, zB nicht mitten in einem Thema.
 
[...]Wir werden daher alle Themen mit mehr als 5000 Antworten heute schliessen und in einem neuen Thema fortsetzen. Dazu wird ein neues Thema erstellt und im alten Thema verlinkt. Das neue Thema trägt den Titel des alten Themas ergänzt um "[Teil 2]"

Viele Grüße
Thomas
Hi Thomas :)

Macht ihr das im Rennradforum dann genauso? Das wäre toll, denn dort ist mir das schon einmal stark aufgefallen, ich wusste nur nicht, dass es an der Länge des Themas liegt..

:wink2:
Goody
 
Zurück