Opensim-Entwicklung Datenbank/Viewer

[Jules Dreki]

So, ich habe jetzt etwas über die Punkte zu skalierbaren Datenbanken nachgedacht.

Skalierbare Datenbankstrukturen sind Systeme, die mit steigender Datenmenge oder Benutzerzahl effizient
umgehen zu können, ohne dabei an Leistung oder Zuverlässigkeit zu verlieren. Hier sind einige Konzepte:

1. **Vertikale Skalierung:** Bei vertikaler Skalierung verbessert man die Leistungsfähigkeit einer Datenbank,
indem man sie auf leistungsfähigeren Servern oder mit mehr Ressourcen (wie mehr RAM oder CPU) betreibt.
Das ist ähnlich wie wenn man einen leistungsstärkeren Computer kauft, um schneller arbeiten zu können.

2. **Horizontale Skalierung:** Hierbei verteilt man die Datenbank auf mehrere Server oder Rechner. Jeder
Server kann dann einen Teil der Last übernehmen, was insgesamt zu besserer Leistung führt.
Es ist vergleichbar mit der Arbeit in einem Team, bei der jeder Mitarbeiter eine spezifische Aufgabe übernimmt,
um schneller zum Ziel zu kommen.

3. **Sharding:** Diese Methode teilt die Datenbank in kleinere Teile (Shards) auf,
die unabhängig voneinander auf verschiedenen Servern gespeichert werden.
Jeder Shard enthält nur einen Teil der Daten, was die Abfragegeschwindigkeit verbessern kann,
da weniger Daten durchsucht werden müssen.

4. **Replikation:** Bei der Replikation werden Datenbanken kopiert und auf mehreren Servern gespeichert.
Dies verbessert die Zuverlässigkeit, da Daten im Falle eines Serverausfalls weiterhin verfügbar sind.
Es ist vergleichbar mit der Sicherung wichtiger Dokumente, die an verschiedenen Orten aufbewahrt werden,
um sicherzustellen, dass man sie nicht verliert.

Wenn ich das richtige sehe sollten die Punkte 1 und 4 unabhängig vom Datenmodell sein. Upgrades einer virtuellen Maschine mit mehr CPU-Kernen oder mehr RAM sollten immer möglich sein. Das Selbe gilt für das parallele laufenlassen der selben Datenbank auf mehreren Servern. Für die Punkte 2 und 3 ist sicher ein angepasstes Datenbankmodell notwendig, damit die Daten mit ihren Beziehungen zueinander überhaupt verteilbar sind.

@Manfred
Aus meiner Sicht zielen diese Maßnahmen aber nur auf grosse Grids ab, die sowieso auf mehreren Servern laufen. Habt Ihr dabei auch eine Clean-Funktion der Datenbank im Fokus? Also eine Funktion die überflüssige Datensätze entfernt. Ich denke das wäre eine Funktion, die den kleinen Grids, die auf einen Server laufen, und für die auch nicht mehrere Server in Frage kommen, helfen würde. Jedenfalls scheint die ständig wachsende Datenbank ja immer wieder hier im Forum ein Thema zu sein.

Allerdings hatte ich mich am Anfang des Threads auf einen Post von Mareta bezogen, in dem anklang, daß das Löschen in verteilten Grids schwierig/unmöglich ist. Ich frage daher etwas provokativ :-) sollte man dann Opensims nicht auf den Standalone Modus beschränken? Damit sollte eine Cleanfunktion doch möglich sein?! Der Standalone Modus sollte der Arbeitsweise der Domains von Vircardia und Overte entsprechen. Oder so eine Funktion wird extra nur für kleine Grids geschrieben.

[Mareta Dagostino]

Allerdings hatte ich mich am Anfang des Threads auf einen Post von Mareta bezogen, in dem anklang, daß das Löschen in verteilten Grids schwierig/unmöglich ist. Ich frage daher etwas provokativ :-) sollte man dann Opensims nicht auf den Standalone Modus beschränken? Damit sollte eine Cleanfunktion doch möglich sein?! Der Standalone Modus sollte der Arbeitsweise der Domains von Vircardia und Overte entsprechen. Oder so eine Funktion wird extra nur für kleine Grids geschrieben.

In Grids, deren Regionen auf Server verschiedener unabhängiger Betreiber verteilt sind, kann das Grid nicht in die Regionen-Datenbanken reinschauen. Daher ist Aufräumen dort nicht möglich, außer man würde entsprechende neue Schnittstellen definieren. Wenn jetzt auch noch manche/viele Regionen nur sporadisch online kommen, wie zum Beispiel im OSgrid, wird es nahezu unmöglich.

In den Metro-Zeiten hatte ich mal drüber nachgedacht, OpenSim so umzuändern, dass jeder Regionenserver ein Standalone-Grid ist. Damit man trotzdem das Gefühl hat, in einem gemeinsamen Grid zu sein, wären in diesem Konzept die "sozialen" Dienste weiter zentral geblieben. Das Grid hätte also die Map, die Gruppen usw. Die Assets und Inventare wären dann lokal. (Natürlich hätte das zentrale Grid für Bewohner ohne eigene Regionen auch ein solches gepimptes Standalone betreiben können.) Der Nachteil dieses Konzepts: Man kann kein "Mainland" bauen! Man könnte also nicht von einer Region in Standalone A auf die Nachbarregion in Standalone B rüber laufen; ja, man würde sie nicht einmal sehen, selbst wenn sie direkt angrenzt. Daher hatte sich damals niemand für dieses Konzept interessiert.

[Jules Dreki]

Danke für Deine Erläuterungen Mareta, das war gut verständlich. :-)

Es ist doch immer wieder überraschend, wie unterschiedliche Menschen zu ähnlichen Ideen/Schlussfolgerungen gelangen, wie hier wieder mit dem Thema Standalone. Genau wie Du das erklärt hast Mareta, würde ich mir das vorstellen.

1) Mainland von Standalone zu Standalone Server ist nicht möglich ok, aber innerhalb eines Standalone Servers sollte man doch Regionen andocken können oder? (faktisch Mainland pro Server, bzw. könnte ich mir einen kräftigen "Mainlandserver" vorstellen)

2) Du hattest aber geschrieben "OpenSim umändern". Das heisst, man könnte ein Grid bzw. die Standalone-Server nach aktuellem Stand so nicht konfigurieren?

Wenn man so den Vorteil hätte, die Datenbank besser warten zu können, würde mich das Konzept nicht stören. Wie oben schon geschrieben, es entspricht der Arbeitsweise der Domains von Overte und Vircadia (bzw. ist dem ähnlich), und man kann dann ja trotzdem große Var-Regionen definieren, oder eben Standard-Regionen auf einem Server andocken, und man hätte auch eine gemeinsame Freundesliste, Gruppen und Chat.

Ausserdem müsste das zentrale Grid weniger Kosten tragen, da ja jeder Server seinen eigenen Asset-Server besitzen würde.

[Anachron]

...
Ausserdem müsste das zentrale Grid weniger Kosten tragen, da ja jeder Server seinen eigenen Asset-Server besitzen würde.

Das Problem sind da ja nicht die Regionsserver - die haben ja eine eigene Datenbank, in der nur die Objekte der Regionen liegen. Der ausufernde Asset-Server im zentralen Grid entsteht ja durch die Inventare der Nutzer.

[Mareta Dagostino]

Mainland von Standalone zu Standalone Server ist nicht möglich ok, aber innerhalb eines Standalone Servers sollte man doch Regionen andocken können oder? (faktisch Mainland pro Server, bzw. könnte ich mir einen kräftigen "Mainlandserver" vorstellen)

Ja, ein Besitzer kann auf seiner/ihrer Standalone so viele Regionen haben, wie die eigene Instanz aushält. Da kann man dann auch von einer zur nächsten Region laufen usw.

Du hattest aber geschrieben "OpenSim umändern". Das heisst, man könnte ein Grid bzw. die Standalone-Server nach aktuellem Stand so nicht konfigurieren?

In einem ersten Wurf könnte man das vielleicht auch durch reine Konfiguration testen. Jeder Teleport innerhalb des Grids ist dann ja technisch ein Hypergrid-TP. Probleme sehe ich z.B.in den dann großen Mengen totem Code, der zu Fehlkonfigurationen verleiten kann. (Beispiel: In der Standalone lokale Benutzer anlegen.) Außerdem gehen die Hypergrid-Gruppen momentan noch nicht so richtig sauber. Wenn das richtig gut werden soll, wäre es auch schick, zwei Sorten Hypergrid-Teleports einzuführen: Einer innerhalb des Grids mit vollem Vertrauen ohne Suitcase. Der sollte sich für die Benutzer anfühlen wie ein normaler TP, also ohne IP-Adresse usw. eingeben zu müssen. Der andere dann wie bisher für echte Hypergrid-Besucher.

Ausserdem müsste das zentrale Grid weniger Kosten tragen, da ja jeder Server seinen eigenen Asset-Server besitzen würde.

Aus meiner Sicht ist das kein großes Problem. Das OSgrid hatte mal Probleme mit der Datenbank, weil es einfach riesig ist. Aber das OSgrid ist die Hauptentwicklungslinie von OpenSim, die werden gewiss nicht einfach mal so umstellen wollen. Metro hatte ein Problem, weil während des Ausfalls von OSgrid sehr viele Neubürger dort eingezogen sind und ihre Inventare abgeladen hatten. Damit war dann Metro auch riesig, während die OSgrid Einwohner wieder zurück sind und die Restbewohner kein hinreichendes Spendenaufkommen mehr generiert hatten, auch aus anderen Gründen gab es gegen Ende dort nur noch sehr wenige aktive Bewohner. Dorena kommt gut klar, obwohl ihr Grid gewiss schon recht groß ist - im deutschsprachigen Raum vermutlich das größte. Dereos ist schon eher klein. => So ein Fork könnte sich auch als Nerd-Spielwiese entpuppen, ohne dass wirklich Bedarf besteht.

Das Problem sind da ja nicht die Regionsserver - die haben ja eine eigene Datenbank, in der nur die Objekte der Regionen liegen. Der ausufernde Asset-Server im zentralen Grid entsteht ja durch die Inventare der Nutzer.

Bei dem Konzept gäbe es keine zentral verwalteten Assets mehr, jede Standalone hätte ihre eigene Asset-Datenbank. Die Bewohner würden sich bezüglich Inventar auf die einzelnen Standalones aufteilen.

[Mareta Dagostino]

Zurück zum ursprünglichen Problem, eine Aufräum-Routine programmieren zu wollen.

Die noch existierenden deutschsprachigen Grids sind doch eher Communities von Bewohnern, die sich irgendwie untereinander kennen. Man könnte vielleicht einfach eine Gridregel aufstellen, dass jeder, der was auf einer Region baut, die Objekte auch kopiert und ins Inventar nimmt. Das Problem für eine Aufräumroutine sind ja hauptsächlich Assets, die ausschließlich auf Regionen verbaut sind und daher vom Grid aus nicht sichtbar. Wenn ein Grid so eine Regel hätte, dann wären Baumeister im Zweifel selbst schuld, wenn ungewollt was gelöscht wird.

[Jupiter Rowland]

Wird nur schwierig bei Prim-Gebäuden, die schon immer in Einzelteilen vorgelegen haben, damit sie keiner kopieren kann.

[Jules Dreki]

Erstmal vielen Dank, für Eure Beteiligung an der Diskussion!

Ich halte die Aufstellung so einer Regel auch nicht für eine gute Lösung, allerdings aus einem anderen Grund als Jupiters. So wie ich die User kenne, kann man sich nicht auf sie verlassen, dass gibt am Ende nur böses Blut. Versteht das nicht falsch, das ist nur menschlich, gerade wenn man nicht in der IT beschäftigt ist, und selbst dann wäre ich skeptisch. ;-)

Die Diskussion zur Standalone-Lösung ist zwar interessant, aber wie Mareta schrieb, nicht ohne Änderung des Opensimulators zufriedenstellend umsetzbar. Daher bleibt die Diskussion leider nur theoretischer Natur.

[Dorena Verne]

Ich bin im Prinzip mit allem einverstanden, was mein Konzept, welches ich über ein Jahrzehnt pflege und mich wohlfühle, nicht von irgendwelchen Codeschubsern, denen die Technik wichtiger ist als die Inworldcommunity.
Ich beschäftige mich ja auch mit der technischen Seite, aber die Nerd-Dialektik ist mir weitgehend fremd.

[Jules Dreki]

@Dorena
Wenn ich hier als Nerd bezeichnet werde, kann ich auch jeden weiteren Post hier sein lassen! Schon mal daran gedacht, daß eine gut wartbare Datenbank letztlich auch den Usern zu Gute kommt, nämlich durch ein besser funktionierendes Grid?!