Umstrukturierung der Item-Datenbank [W1-14]

[Avalon]

An Sotrax Stelle würde ich jetzt nichts mehr ohne meinen Anwalt sagen

Ich finde es gut, dass das Problem mal angegangen wurde und es vergoldet die 1.0

[Sotrax]

@Galak: Wir können nicht den gesamten Quellcode zentral lagern. Wieso das der Fall ist, sollte einem schnell kommen, wenn man weiß, dass die Leute wollen, dass alte Items sich so wie früher verhalten und neue Items eben "neu" verhalten. Mit komplett zentralen Quellcodes wäre ein Update immer in allen Items drin. Die Leute fanden es bisher ja aber immer ganz gut, wenn es irgendwelche Antiquitäten gibt . Und dann kommen letztendlich die Uniques.

Die Engine muss also diese gesamte Funktionalität bereitststellen, und dabei möglichst sparsam vorgehen.

Daher brauchen wir einen transparenten Cache der das alles erledigt.

(Würden die leute sagen, sie wollen keine Antiquitäten mehr und keine Uniques mehr, ließe sich das ganze auch leicht mit Pointern lösen, so ist es aber deutlich komplexer. Bisher war diese Freiheit aber bei Updates immer eine Vorraussetzung.).

Wie auch immer, das neue System bietet einen sehr guten Kompromiss aus beidem.

[Galak]

Natürlich kannst du den gesamten Quellcode zentral lagern. In Einer Funktionstabelle z.B. und dann noch eine Tabelle für Texte, Werte und co. Am Ende erzeugst du dann die Items aus diesen Vorlagen und hast eine extrem schlanke Itemtabelle. Für Uniques machst du noch eine Spalte dazu(UniqueID z.B.) und eine Tabelle mit den Uniquetexten, welche dann die Standarttexte überschreiben. Antiquitäten fand ich schon immer schwachsinnig und wenn man sie unbedingt möchte erzeugt man halt eine neue Vorlage für das neue Item. Dann hast du zwar 2 Vorlagen für fast gleiche Items, verbrauchst aber im Endeffekt erheblich weniger Speicher.

[Sotrax]

@Galak: Das ganze hat wie gesagt deutliche Nachteile, nämlich die Antiquitäten und das sehr viel schwerere bearbeiten von Uniques.

Dazu kommt, dass du bei häufig verwendeten Items immer einen zweiten Lookup machen musst, also mehr Selects brauchst. Eine Cache-Lösung ist da deutlich besser, weil sie merkt was häufig verwendet wird und was nicht.

Die reine Größe ist ansonsten nicht wirklich ein Problem, wir selektieren ja eh über Indizes. Nur das Backupen wird halt nerviger.

Eine zentrale DB nimmt einem da einige Freiheiten. die jetzige Lösung ist aber sowas in der Art, nur dass sie eben dynamisch entscheidet was eingecached wird und was nicht. Das gibt einem Vorteile aus beiden Welten

[Sotrax]

BTW: Wenn man ins Detail gehen würde, ist es so:

Wir hatten schon immer einen zentralen Ort für allen Code, nämlich im Filesystem. Sprich jeder Heilzauber liegt irgendwo als Datei auf der Festplatte. Und da teilen sich alle Heilzauber natürlich immer die gleiche Datei und nur diese wird includet.

Das was in der DB gespeichert wurde, war noch nie Code der direkt verwendet wird sondern er hat immer nur zum Abgleich gedient. Platz hat dieser Abgleich dennoch gebraucht, und genau da setzt jetzt der zweite Cache an.

Sozusagen ein zweistufiges Cache-System.

[Galak]

oh man...ernsthaft? ich glaub ich geh mal lieber, bevor du noch mehr schauermärchen erzählst o__o'

[Sotrax]

@Galak: Was soll daran schaurig sein? Das System ist extrem effektiv. Das z.B. alles übers Filesystem läuft bemerkt man nichtmal, das geht völlig transparent und er erzeugt die Dateien on the fly wenn sie nicht vorhanden sind.

Glaub mir, wirklich schaurig wäre das, Code per eval aus der Datenbank auszuführen.

Das was wir da machen ist die beste Vorgehensweise, wenn man die PHP-Caches wie APC effektiv nutzen will.

[der Finstere]

Heisst das, dass sich auch die Performance verbessert? Hatte mal nen Account mit ca 6000 Items im SF (alles Seelensteine). Zum Laden gings etwa 10-15 Sek und als ich dann den Kasten leeren wollte, brauchte ich für jeden Seelenstein rauszunehmen etwa 10 Sekunden - ein Ding der Unmöglichkeit, wenn man mal soviele Items im SF hat. (da musste man schon fast administrative hilfe haben)

[Sotrax]

@der Finstere: Verschiedene Dinge gehen schneller als früher, andere gehen sogar minimal langsamer (wegen zweitem Lookup in zweiter Tabelle).

In dem von dir beschriebenen Fall dürfte sich aber nicht viel ändern, weil das langsame dabei ist nicht die Datenbank oder der Server, sondern das Problem ist dabei der Traffic. Die Webseite braucht eine gewisse Zeit um soviele Items anzuzeigen, auch je nachdem wie schnell deine Anbindung ist.

[der Finstere]

Okay - obwohl es mich erstaunt, trotz meiner 32k Leitung. Aber generell natürlich ein Daumen-Hoch - Optimierungen sind immer toll.

[Sotrax]

Wie gesagt, im gewissen Rahmen ist es egal wie groß die DB ist, solange man alles über Indizes macht und nur darüber selektiert und der RAM eh ausreicht um die ganze DB zu fassen.

Unterm Strich lohnt sich diese optimierung aber dennoch, alleine damit unsere Backups kleiner werden

[der Finstere]

Jo das sind halt die hässlichen backup-lags...

in w2 ists immer 35 nach. die sind schon recht hart und dauern meistens ne minute mit kleinen nachlags.

[Sotrax]

Die Backup-Lags sind natürlich weiterhin da, aber sie sollten merklich kürzer mir der Änderung gehen. (Etwa nur noch halb so lang).

@snigg: Muss mal schauen, evt. kann ich die Server Stück für Stück nachrüsten, evt. mache ich es auch erst nach dem nächsten Update

[Sotrax]

So aktueller Status: Ich spiele die Sache gerade mal in Welt 2 auf, weitere Welten werden folgen. Dauert halt pro Welt jeweils 15 Minuten in etwa.

[Sotrax]

Gerade sind Welt 3 und 4 dran, leider dauert dort die Durchrechnung scheinbar etwas länger.