Das Aufteilen von Assets

[Manfred Aabye]

Das Aufteilen von Assets in Einzeltabellen und die Parallelisierung der Zugriffe darauf können mehrere Vorteile bieten:
1. Verbesserte Leistung: Durch die Aufteilung der Assets in mehrere Tabellen können Sie die Datenbanklast auf mehrere Datenbankverbindungen verteilen. Dies kann die Gesamtleistung verbessern, insbesondere in Umgebungen mit hohem Datenbankverkehr.
2. Parallele Abfragen: Wenn verschiedene Tabellen für verschiedene Arten von Assets verwendet werden, können Abfragen für verschiedene Arten von Assets parallel ausgeführt werden. Dies kann die Antwortzeiten verkürzen, da mehrere Abfragen gleichzeitig bearbeitet werden können.
3. Einfachere Skalierung: Durch die Verwendung mehrerer Tabellen können Sie die Datenbank leichter horizontal skalieren, indem Sie verschiedene Tabellen auf verschiedene Datenbankserver verteilen. Dies kann die Skalierbarkeit verbessern, da Sie neue Datenbankserver hinzufügen können, um die Last zu bewältigen.
4. Bessere Isolation: Durch die Verwendung separater Tabellen für verschiedene Arten von Assets können Sie die Daten besser isolieren. Dies kann die Integrität der Daten verbessern und das Risiko von Datenbeschädigungen oder -konflikten verringern.
5. Einfachere Verwaltung: Die Verwendung mehrerer Tabellen kann die Verwaltung der Datenbank erleichtern, da Sie die Daten besser organisieren können. Dies kann die Wartung, Sicherung und Wiederherstellung der Datenbank vereinfachen.
6. Bessere Skalierung auf Anwendungsebene: Durch die Parallelisierung von Datenbankzugriffen können Sie auch auf Anwendungsebene skalieren, indem Sie mehrere Threads oder Prozesse verwenden, um gleichzeitig auf die Datenbank zuzugreifen. Dies kann die Gesamtleistung der Anwendung verbessern.
Insgesamt ermöglicht die Aufteilung von Assets in mehrere Einzeltabellen und die Parallelisierung der Zugriffe darauf eine effizientere und skalierbarer Verarbeitung von Asset-Daten in großen und stark frequentierten Systemen.

Um die oft Terabyte große asset Tabelle zu reduzieren und durch Parallelisieren vielleicht noch zu beschleunigen komme ich an meine Wissensgrenzen.
Im Anhang habe ich meine Dateien, die hierfür benötigt, werden, aber wahrscheinlich sind diese nicht vollständig.

Inhalt 20 CSharp Dateien und 19 Migrationsdateien (Anfang der Umsetzung meiner Idee):
https://eu2.contabostorage.com/52253033f...t_Data.zip

[Dorena Verne]

Klingt toll, aber an meinem Monster traue ich mich nicht ran.

[Pius Noel]

Bei grösseren Grids ist das bestimmt bestimmt eine Überlegung wert. Das bedeuted aber auch, dass man bei Updates, welche die Daten betreffen, immer auch die entsprechenden .cs- und Migration-Files anpassen muss.

[Manfred Aabye]

Es wird eigentlich schon bei nur 3 Personen oder einer Person mit Sammelwut im Grid benötigt.
Die Migration ist übrigens automatisch und braucht nur einmal gemacht werden.

Ich denke, es müssen noch die folgenden Dateien angepasst werden:
HypergridService - HGAssetService.cs, HGRemoteAssetService.cs
AssetService - AssetService.cs, AssetServiceBase.cs

Vielleicht sollte ein eigener Service erstellt werden und das auch mit einem falback-service.
Die Rede war eh schon das sich ein MariaDB Implementierung lohnen könnte, da mySQL und MariaDB sich stetig auseinanderleben.
Ich persönlich halte eine Aufsplittung der Assets seit OpenSimulator 0.8.x für zwingend nötig.

[Mareta Dagostino]

(MariaDB sowieso.) Die Idee finde ich super, kann aber auch Dorena in der Rolle als größere Grid-Admina verstehen. Sowas müsste wirklich felsenfest durchgetestet sein und eine idiotensichere Anleitung haben, sonst ist das Risiko für ein Grid einfach gewaltig. Was ist schlimmer, ein ab gewisser Größe weniger performantes Grid (kann man ggf. in mehrere Grids aufteilen) oder eine zerstörte Asset-Datenbank mit vielen super verärgerten Einwohnern?

[Manfred Aabye]

Backup einer Datenbank, aber richtig.
Mysqldump in der Datei mysqldump.cnf einstellen auf: max_allowed_packet=2147483648

Bitte niemals die Robust Datenbank mit einem Webinterface wie phpmyadmin oder admin-panel sichern.

Zuerst sichert ihr alle Tabellen eurer Robust Datenbank außer der assets Tabelle.

Die assets sind so groß das diese per assetType gespeichert werden muss das sind etwa/bis 32 AssetTypen die in Tabellen gesichert werden.

Nach jeder gesicherten Tabelle müsst ihr die Einträge zählen und vergleichen, wenn dies unterschiedlich ist, dann ist der Fehler meist einen Eintrag hinter dem letzten gesicherten Eintrag.

Wenn auf eurem Server nicht genug Platz ist, könnt ihr zwischendurch jede Tabelle einzeln auf euren PC verlagern.

Ihr habt jetzt eure Datenbank in viele Teilbereiche und die Fehler sind auch behoben.
Ihr könnt euch jetzt damit eine neue Datenbank bauen, indem ihr alles in einer neuen Datenbank einfügt.

Das Ganze ist zwar etwas zeitaufwendig, aber kinderleicht und 100 % sicher.

[Manfred Aabye]

Stand der Dinge
Ich arbeite immer noch daran, die Assets zu vereinzeln.
Das Problem ist, dass hierfür folgendes überarbeitet werden muss:
* LibOpenMetaverse - https://github.com/opensim/libopenmetaverse
* OpenSim-Libs - https://github.com/opensim/opensim-libs
* OpenSimulator - https://github.com/opensim/opensim
Natürlich müssen die alten Assets, bis sie nach und nach verschoben sind, beibehalten werden.
Um den alten Zustand zurückzuerhalten, brauchen die vereinzelten Assets nur wieder in die "assets" Tabelle kopiert werden, also Sicherheitsbedenken habe ich da keine.