"Dorenas World", neue Wege.

[Sleimer Akina]

Verstehe ich jetzt irgendwie nicht, denn die UUID ist doch in der DB Prim-key, von daher kann doch eine bereits vorhandene UUID auch nicht zu einem doppelten Eintrag führen. Doppelte Objekte in der DB entstehen nur dadurch, dass das gleiche Objekt mit verschiedenen UUIDS existiert - und das dürfte mit fasset nicht anders sein.

Kann sein, dass ich mich irre, aber so habe ich das immer verstanden. Korrigiere mich wer es besser weiss.

Ich war und bin gegenüber fasset immer skeptisch, weil das Funktionalität der DB auf das File-System verlagert - was ich eigentlich für keine gute Idee halte.

fassets sollte nur genutzt werden eine entsprechend Festplatte dafür da ist, in diesem Fall ist eine SSD vorhanden, weit aus mehr geschwindigkeit bringt, wie die MySQL.

Desweiteren wird in der Datenbank ein Index angelegt der passen zu den den Assets auf dem FileSystem ist.
(Kategorisiert)

Die UUID ist nicht der Prim-Key in der Datenbank, sondern die ID, welche aufgabe genau diese ID hat, ist fragwürdig jedenfalls passt sie nicht zu den UUID geschweige den zu den Objekten.
Aufgrund dessen ist ein Objekt mehrfach vorhanden, an verschiedenen avataren wenn du mir ein objekt gibst wird eine kopie nochmals in der datenbank angelegt. und so weiter.

Die Skeptis mag zwar berechtigt sein, jedoch basiert eine Datenbank ebenfalls auf ein Filesystem vom grunde genommen.

Der Vorteil hierbei ist nur, das Objekte weit aus schneller zugeordnet werden können, da die datenbank hier nicht alle Zeilen durch gehen muss. Dies geht aber auch nur wenn die Festplatte entsprechend schnell genug ist SSD oder NvME.

Backups können dadurch leichter vollzogen werden, da diese in Pakete z.b. gezippt werden können.

Der Nachteil des bisherigen assetssystem ist es, da durch das aufblähen der Datenbank, es ab eine gewisser Größe Technisch unmöglich macht, noch ein vernüftiges Backup zu realisieren > als 1 TB
(Aktueller Stand ca. 700 GB)

Auszug aus OpenSimulator:

FSAssets ist für Grids vorgesehen, bei denen die Größe der Datenbank voraussichtlich 50 GB überschreitet. Diese Option speichert die Assets im Dateisystem im Gegensatz zum Standarddienst, der Assets als Blobs in der Datenbank speichert. Diese Option bietet auch Deduplizierungsfunktionen. Jedes Asset wird gehasht, wenn es zur Speicherung empfangen wird. Wenn das Asset bereits vorhanden ist, wird der Asset-Service mit der vorhandenen Datei verknüpft, anstatt zwei Kopien zu speichern. Einzelpersonen erreichen sehr schnell ein Inventar der Größe 12 GB im laufe der zeit erhöht sich das ganze meist auf 18 GB pro Benutzer, es gibt aber ausnahmen wo einzelne Personen schon 50 GB erreichen.

Quelle: http://opensimulator.org/wiki/FSAssets_Service/de

Man kann das alte verfahren gerne weiter nutzen, nur eine Garantie für irgendwas werde ich nicht leisten
Jetzt hat man noch die Möglichkeit, das so zu gestalten, das Backups noch Sinn machen.
Das ist halt eben kein kleines Grid.
Ich kann nur Technische Verbesserungen bieten.
Aber mehr auch nicht.

Das muss man dabei bedenken.

Das ganze wurde extra so geschaffen wie oben beschrieben von OpenSimulator.
Und man wird hier bestimmt auch nicht der einzige sein

Ein Fileystem hat immer seine vor und nachteile, das möchte ich nicht bestreiten.
Aber mit den heutigen technischen möglichkeiten, ist vieles sehr vieles besser geworden.

Ich finde es aber schön, um ehrlich zu sein, das man offen darüber redet und auch Kritik an den kopfgeworfen bekommt.

Ich kann lediglich Lösungen bringen, mich vorher schlau machen darüber, und umsehen wie es andere tun
weil man eben nicht alleine ist.