Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
20.07.2024, 21:12
(Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2024, 11:44 von Jules Dreki.)
Da das ein eigenes Thema ist, mach ich mal lieber einen eigenen Thread auf.
Vor längerer Zeit habe ich auf Bitte von Night (Admin von https://swissgrid.opensim.ch/index.php/de/) mich mal mit dem Thema befasst, ob es zum Aufräumen der Datenbank möglich ist ein SQL-Script zu schreiben. Wie Mareta das wie im folgenden schon andeutete, wird das in größeren Grids kompliziert.
(18.07.2024, 23:11)Mareta Dagostino schrieb: ...
Nehmen wir nun ein größeres Grid an - mit mehreren Regionenservern, die verschiedenen realen Personen gehören. Wenn nun Objekte nur auf einer Region verbaut sind, aber in keinem Inventar mehr vorkommen, kann eine eventuelle Löschroutine nichts davon wissen. Die Assets dieser Objekte würden aus der Datenbank des Grids gelöscht, obwohl sie noch benötigt werden.
...
Ich habe mich daher damals auf kleine Grids mit einem physischen Server beschränkt, wie die meisten ein Grid betreiben. Trotzdem stellte sich das als schwierig heraus. Dafür hatte ich lokal ein Grid aufgesetzt und dessen Datenbank mit Beispiel Assets und Avatar besuchen von aussen mit Hilfe des Tools DBeaver-CE analysiert. Wie ich zugeben muß sind allerdings Datenbanken nicht mein tägliches Brot, nichts desto trotz gehört aber der Umgang damit zur IT-Ausbildung. Jedenfalls war mein Eindruck, das das Relationship-Model des Opensim-Servers nicht ganz so toll ist (UbitUmarov hat natürlich trotzdem insgesamt eine tolle Arbeit geleistet). Über die Primary-Keys liess sich die Struktur der Datenbank analysieren. Allerdings fand ich das die Beziehung der Datensätze über die Tabellen hinweg über Foreign-Keys nicht ausreichend modelliert ist. Letztlich war ich mir nie 100%ig sicher, kann ich nun den oder den Datensatz löschen. Am Ende habe ich das Ganze aufgegeben. Berichtigt mich falls das Sülze ist, wie gesagt ich bin kein DB-Admin!
@Manfred Aabye
Soweit ich das hier im Forum mitbekommen habe, gehöst Du mit zum Team, das den Opensimulator weiterentwickelt. Deshalb zu deiner folgenden Aussage bitte eine Frage.
(20.07.2024, 11:40)Manfred Aabye schrieb: ...
Das einzige Manko, was an OpenSim ist, das ist die Datenbank, dieser Programmbereich muss an moderne Zeiten angepasst werden, also komplett erneuert werden.
...
1) Heisst das, daß das komplette Relationship-Modell überarbeitet werden soll? Ist das schon in Arbeit oder geplant? Was schwebt Dir da genauer vor?
2) Abgesehen davon suche ich ein Projekt, mit dem ich mich in die Programmiersprache Rust einarbeiten kann. Mir schwebt dabei ein Viewer basierend auf eine der folgenden Game-Engines vor. Wie würdest Du mir empfehlen mich in die Thematik einzuarbeiten? Sind die Dokus auf http://opensimulator.org/wiki/Main_Page aktuell?
https://bevyengine.org/
https://github.com/FyroxEngine/Fyrox
Versprechen kann ich nichts, schon gar nicht zu irgendwelchen Zeiträumen, aber das wäre schon ein interessantes Thema. Es würde ja eventuell helfen, auch wenn es nur eine Intialzündung ist. Möglicherweise entwickelt Rust ja mehr Anziehungskraft auf die Community als Mono. :-) Jedenfalls wäre das mein Wunsch.
Beiträge: 7.008
Themen: 773
Thanks Received: 1.332 in 655 posts
Thanks Given: 3.436
Registriert seit: Jul 2010
Hallo ;D
Also ich finde die Idee hört sich gut an, nur warum das Rad neu erfinden und nicht an ein Projekt dran hängen ? Vielleicht eines, was in die Richtung von OpenSim geht ? Dann musste nicht ganz von vorne anfangen und kannst von den anderen programmierer lernen ;D
Obwohl ich das andere auch sehr intressant finde, als Pluginsprache vielleicht noch python einbauen ? *gg
Aber ich hab eh keinen Schimmer von dem ganzen, sind nur so Gedanken von mir ;D
Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
20.07.2024, 22:24
(Dieser Beitrag wurde zuletzt bearbeitet: 20.07.2024, 22:31 von Jules Dreki.)
@Bogus
Das Ganze soll schon in Richtung Opensim gehen. Es schwebt mir ja gerade ein Opensim-Viewer vor.
Im Prinzip hast Du ja Recht, am effektivsten wäre es sich irgendwo anzuschliessen, das würde aber heissen, man wäre auf die verwendete Programmiersprache festgelegt. Der Firestorm wird zum Beispiel in C++ entwickelt. Ich möchte aber Rust lernen.
Während meines Studiums war C++ ein klasse Sprache, vorallem übersichtlich. Heute ist sie ziemlich aufgebläht, gefällt mir jedenfalls nicht mehr. Ich glaube, ich habe auch mal gelesen, daß der ursprüngliche C++ Entwickler Professor Tanenbaum sich kritisch zum aktuellen C++ geäußert hat, allerdings kann ich das im Moment nicht belegen. Noch suche ich nach der entsprechenden Homepage. Allerdings kritisieren auch andere namenhafte Programmierer diese Sprache.
https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B
Vom Urschleim an möchte ich den Viewer auch gar nicht entwickeln, deshalb soll ja eine der oben genannten Game-Engines die Grundlage sein.
Beiträge: 7.008
Themen: 773
Thanks Received: 1.332 in 655 posts
Thanks Given: 3.436
Registriert seit: Jul 2010
@Jules
Wenn ich das richtig verstehe, geht es dir also nur um den Viewer, aber nicht um den Server richtig ?
Ähm, evtl. dann aber das Thema ändern, weil wenn du einen Viewer in Rust entwickeln möchtest, dann gehts ja ncht nur um die Datenbank oder sehe ich dss falsch ? Ich versuche schon seit jahren, Python mir beizubringen bzw. ähm überhaupt programmieren zu erlernen *gg Bin also keine grosse Hilfe, das einzige was ich anbieten könnte, das ich Tester wäre und ich auch mal schau, ob ich ein 3DFramework in Rust finde. Was ist denn so besonderes an Rust ? Ich wess nur das es von Mozilla entwickelt wurde und dann weiter ging an die Community ;D Was du ja auch geschrieben hast ;D
Wegen C++, die Kritik von dem Hauptentwicker, das hab ich auch mal bei Heise gelesen ? Jedenfalls kann ich das bestätigen, aber stecke halt eh nicht so drin ;D
Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
21.07.2024, 12:02
(Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2024, 12:20 von Jules Dreki.)
OK, die Verquickung zweier Themen im Thread war nicht so glücklich. Ich habe das Thema mal angepasst.
@Bogus
Du siehst das richtig, es geht bei der Viewer-Entwicklung nicht um die Datenbank selbst, aber eventuell um die DB-Schnittstelle. Da bin ich mir noch nicht sicher, das klärt sich erst, wenn ich mich mit den Kommunikationsprotokollen auseinandersetze.
Python ist nicht so meine Sache. Mein Kritkpunkt sind die fehlenden Syntaktischen Begrenzungen von logischen Blöcke, wie z.B ein begin/end wie in Pascal oder die geschweiften Klammern aus C. So ist die Logik des Programms bei Python von der Formatierung des Quelltextes abhängig. Das halte ich für einen Rückschritt. Mir ist es vor Jahren mal passiert, dass durch Copy/Paste die Formatierung eines Pythonprogramms zerstört wurde, damit war das ganze Programm im Eimer. Aber ok, mittlerweile sind die Pythoneditoren besser geworden, so kritisch ist das heute nicht mehr. Man kommt auch um die Sprache nicht herum, sie ist eben halt weit verbreitet und weitestgehend plattformunabhängig. Du wirst also jede Menge Infos zu Python im Internet finden. Pass aber auf das es Infos zu Python3 und nicht zu Python2 sind, da gibt es erhebliche Unterschiede, und Python2 ist ein aussterbender Ast.
Früher war Pascal gut um das Programmieren zu lernen. Aus diesem Anspruch heraus wurde es ja auch vom Niklaus Wirth entwickelt. Mit dem Verschwinden von Borland, dem Anbieter von Turbo Pascal, hat es aber sehr an Popularität eingebüsst.
https://www.lazarus-ide.org/
Lazarus ist sowas ähnliches wie Delphi von Borland, ich habe damit aber nie selbst gearbeitet. Daher den Link zur Info, aber ohne Empfehlung.
Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
21.07.2024, 12:16
(Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2024, 12:23 von Jules Dreki.)
Ahh ok, du hattest ja noch ein Frage zu Rust. Das besondere an Rust ist, dass es mit dem Anspruch angetreten ist Speicherlecks, durch die Sprache selbst, prinzipbedingt unmöglich zu machen. Diese Fehlerklasse der Speicherlecks soll die häufigste Ursache für Programmierfehler sein. Das wichtige Stichwort dabei ist "Ownership" ein Alleinstellungsmerkmal von Rust. Wen die Hintergründe näher interssieren liest bitte den Abschnitt "4 Eigentümerschaft (ownership) verstehen" unter dem folgenden Link.
https://rust-lang-de.github.io/rustbook-...rship.html
Ansonsten ist mein Eindruck, das Rust auf gute Ideen anderer Sprachen zurückgreift, und so die Erfahrungen aus der Vergangenheit berücksichtigt. Mir kommt es jedenfalls so vor, als ob Rust Elemente von C, Python und Pascal benutzt. Ausserdem ist es eine übersichtliche Sprache mit einem begrenzten Sprachumfang. Ich hoffe das wird so bleiben, und nicht wie bei C++ ausufern.
https://www.rust-lang.org/
Beiträge: 907
Themen: 135
Thanks Received: 534 in 288 posts
Thanks Given: 69
Registriert seit: Feb 2015
Die Server und die Datenleitungen werden immer besser,
dadurch wird aber auch die Datenbank immer größer.
Die Datenbankstruktur in OpenSim wurde zwar immer wieder nachgebessert,
aber irgendwann reicht das nicht mehr und es muss erneuert werden.
Ich finde das die assets Struktur so aussieht, als hätte man das damals einfach so hineingeworfen,
damit man ein schnelles Erfolgserlebnis hat, was ja auch damals vielleicht nicht schlecht war.
Heute benötigen wir aber skalierbare Datenbankstrukturen und da bin ich am Experimentieren.
Ich habe mir dazu einen zweiten Server gemietet, mal sehen, was das gibt.
Ein Metaversum sind viele kleine Räume, die nahtlos aneinander passen,
sowie direkt sichtbar und begehbar sind, als wäre es aus einem Guss.
Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
@Manfred
Danke für Deine Antwort. Ich nehme mal den Begriff skalierbare Datenbankstrukturen mit, mal nachlesen was das genau bedeutet. Ansonsten scheine ich ja mit der Einschätzung des Datenbankmodells nicht soweit danebengelegen zu haben. Puhhh.... *Angstschweiss abwischt* :-)
Beiträge: 907
Themen: 135
Thanks Received: 534 in 288 posts
Thanks Given: 69
Registriert seit: Feb 2015
21.07.2024, 20:31
(Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2024, 20:36 von Manfred Aabye.)
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.
Diese Techniken ermöglichen es jedem, ihre Datenbanken so zu gestalten,
dass sie mit dem Wachstum ihrer Nutzerzahlen oder Datenmengen mithalten können,
ohne dass es zu Engpässen oder Leistungsproblemen kommt.
Von meiner KI
Ein Metaversum sind viele kleine Räume, die nahtlos aneinander passen,
sowie direkt sichtbar und begehbar sind, als wäre es aus einem Guss.
Beiträge: 76
Themen: 10
Thanks Received: 38 in 28 posts
Thanks Given: 5
Registriert seit: Apr 2020
Upps, das war jetzt unerwartet. Vielen Dank für den Lesestoff Manfred.
|