Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Datenbank Asstet aka Userinventare ?
#1
Hallo hab da mal ne dumme Frage,
wenn ich eine Textur hochlade und eine UUID erhalte bei abfrage finde ich Diese 2 x im Mysql datanbank
Meine Sims sind auf PostSQL .db, also die Locale datenbank eingestellt....

1. Wenn ich meinen fund den ich 2x finde (z.B. Textur lösche ist dieser vom Inventory weg und aus dem Asset) kann auch mehrmals gefunden werden dann müsste es ein zeich sein das mehrere diese Textur haben als beispiel

2. Wenn ich ein OAR hochlade, get was davon in den Asset oder bleibt alles in der Sim(speicher)?

Bin am überlegen, um meinen server mal eine aufräumroutie zu geben, eine zu schreiben,
(liste UUID, Suche diese in Inventorys = wenn nicht in Inventory dann wech....)

Es passier öfters das man was hochläd und dann wieder löscht weil es nicht passt... also müll...und diesen möchte ich auch aus dem Asset
Zitieren
#2
(17.11.2018, 14:55)brenner23 schrieb: ...
(liste UUID, Suche diese in Inventorys = wenn nicht in Inventory dann wech....)
...

Wenn das so einfach wäre, hätten wir eine Garbage-Collection schon lange realisiert, aber natürlich kann eine Textur (z.B.) ohne Weiteres auf irgendeinem Prim kleben, ohne dass sie im Inventar eines Users vorkommt. (Das ist schon für alle Texturen gegeben, die auf Objekten aus dem Hypergrid pappen - die wurden mit dem Objekt in die Asset-DB gespült ohne jemals einem User des Grids gehört zu haben.)
Zudem kann eine UUID ja auch noch in einem Script hartcodiert sein, obwohl der User das zugehörige Item aus seinem Inventar gelöscht hat.
Und das sind nur einige der Bedenken die sich auf Texturen beziehen ... ähnliches gilt z.B. für Sounds u.v.m.

Insgesamt ist deine Frage aber leider in so unverständlicher Sprache abgefasst, dass es sich dem Leser nur schwer erschliesst, von was da die Rede sein soll. Huh
Wer nicht weiss wohin er will, der kommt leicht woanders hin.
Zitieren
#3
Schade , ich dachte man könnte den Assetspeicher ein wenig reduzieren, zumindest um diese Assets die nicht (mehr) benuzt wird... weil diese ja auch Speicher wegnimmt...
Da ich mein Testgrid aufbaue und meine ALten inventare aus OS und Metro zusammenziehe als IAR... und danach auf Doppelten, und Brauchbaren Kram absuchen wollte ... bleibt es nur auf ebene des Inventars.... Undecided

Mein Opsnsim Mysql dumb ist schon bei 3.5 GB, dachte man könnte da noch so paar Gigagbite eindampfen was da ungenuzt und unverlinkt rumdümpelt...

schade...
Zitieren
#4
(17.11.2018, 20:22)brenner23 schrieb: Schade , ich dachte man könnte den Assetspeicher ein wenig reduzieren, zumindest um diese Assets die nicht (mehr) benuzt wird... weil diese ja auch Speicher wegnimmt...
Da ich mein Testgrid aufbaue und meine ALten inventare aus OS und Metro zusammenziehe als IAR... und danach auf Doppelten, und Brauchbaren Kram absuchen wollte ...
Das wäre eigentlich ein interessantes Projekt. Ich bin gespannt, wie Metropolis es machen wird, wenn sie Anfangs 2019 das Inventar verkleinern wollen. Einfach in IAR's archivieren und wieder importieren eliminiert zwar die Inventare derer die nicht mehr aktiv sind, aber es verhindert nicht, dass derselbe Schrott wieder im Asset landet.

In meinem Testgrid sieht es auch nicht gut aus. Da hab ich mehrere Assets, die mehrfach vorkommen, nur weil sie aus verschiedenen Quellen kommen oder unterschiedlich importiert wurden.

Interessant wäre eine Art Hashcode, der zu den Assets gehört und Elemente mit gleichem Inhalt eindeutig markiert. Der Zugriff könnte dann indirekt über die bisherigen ID's erfolgen, egal wer der tatsächliche Ersteller oder Besitzer ist. Ist nur so eine Idee, die mir in diesem Zusammenhang gekommen ist.
Zitieren
#5
(17.11.2018, 20:45)Pius Noel schrieb: Ich bin gespannt, wie Metropolis es machen wird, wenn sie Anfangs 2019 das Inventar verkleinern wollen. Einfach in IAR's archivieren und wieder importieren eliminiert zwar die Inventare derer die nicht mehr aktiv sind, aber es verhindert nicht, dass derselbe Schrott wieder im Asset landet.

Es wird einfach darauf spekuliert, dass viele ehemalige Residents eben keine Regionen mehr ins neue Grid hochladen. Wenn die Assets weder im Inventar der neuen Residents noch auf Regionen des neuen Grids vorkommen, dann fallen sie in der neuen Datenbank nicht mehr an (= werden nicht importiert). Es werden also keine Inventare oder OARs automatisch übertragen, sondern an die aktiven Residents herausgegeben. Diese müssen das dann aktiv im neuen Grid wieder importieren, wobei die Metro-Admins Tools zur Unterstützung anbieten werden. (Nicht jede und jeder haben eine eigene Region, um IARs zu ziehen und wieder hochzuladen.)

Eine clevere technische Lösung ist das nicht, aber wie ihr schon erwähnt habt: In OpenSim kann man nicht feststellen, ob und wo ein bestimmtes Asset noch benötigt wird.
Zitieren
#6
Je größer und je länger ein Grid schon existiert umso größer das zu befürchtende Chaos.
Ich finde den Schritt den das Metro nun geht sehr mutig, Hut ab.
Unsere Assetdatenbank in Dorenas World hat mittlerweile ja auch schon ein Volumen von ca 500G.
Auch wir überlegten uns ja schon solch einen radikalen Schritt, aber vorerst nehme ich davor noch Abstand.
Zitieren
#7
(18.11.2018, 08:45)Dorena Verne schrieb: Je größer und je länger ein Grid schon existiert umso größer das zu befürchtende Chaos.
Ich finde den Schritt den das Metro nun geht sehr mutig, Hut ab.
Unsere Assetdatenbank in Dorenas World hat mittlerweile ja auch schon ein Volumen von ca 500G.
Auch wir überlegten uns ja schon solch einen radikalen Schritt, aber vorerst nehme ich davor noch Abstand.

Kann man das mit einem Neustart gleichsetzen ???
-Wir Sichern alle unsere IARs
-Dann unsere Sims als OAR...

Dann Stichtag Grit Plattmachen .....
und wie laden alles wiesder hoch ???

Ich sehe schon Objecte die Weiss sind weil die Textur von Resident.name@unbekanntes grid hat...und auch Sounds und animationen nicht alle mehr dasein werden....

Ich dachte eher an eine lösung das man eine Funktion schreibt das alle alle abhängkeiten überprüft , UUID Objekt hat Textur UUID 1 Sound UUID blub und soi weiter... und alles was übrigbleibt und nicht mit Asset oder Inventare verknüpft sind fliegt......

Also das wäre meine Idee... an hand meiner ersten suchanfragen in der MysqlDatenbank... (phpmyadmin)

und wenn eine UUID alleine nur zu finden ist ... dann ist es müll ...

aber ich weiss ja nicht was ihr für ideen dazu haben könntet :-)

lg
Zitieren
#8
(19.11.2018, 02:45)brenner23 schrieb: Kann man das mit einem Neustart gleichsetzen ???
-Wir Sichern alle unsere IARs
-Dann unsere Sims als OAR...
Dann Stichtag Grid Plattmachen .....
und wir laden alles wieder hoch ???

Ja.

(19.11.2018, 02:45)brenner23 schrieb: Ich sehe schon Objecte die Weiss sind weil die Textur von Resident.name@unbekanntes grid hat...und auch Sounds und animationen nicht alle mehr dasein werden....

Im OAR sind alle Assets enthalten, die statisch auf dem Land verbaut sind. Problematisch sind Scripte, die per UUID zur Laufzeit Assets laden. Wenn man die nicht irgendwo mit auf der Region ablegt, muss man hoffen, dass ein aktiver Avatar die noch im Inventar hat und wieder importiert, oder sie zufällig mit einer anderen Region mitkommen.

=> Tipp: Dynamisch geladene Texturen, Animationen usw. in eine Box packen und irgendwo dezent auf der Region abladen.

Das Problem gibt es aber immer, wenn man eine Region von einem Grid in ein anderes transferiert.

(19.11.2018, 02:45)brenner23 schrieb: Ich dachte eher an eine lösung ... MysqlDatenbank ...

Das ist jetzt nicht ironisch gemeint: Wenn du da eine Lösung findest, löst du damit eins der ganz großen Probleme von OpenSim. Bisherige Ansätze scheiterten z.B. an folgenden Problemen:

- Das Grid weiß nicht, was auf den Regionen noch benötigt wird. Nur, wenn ein Avatar auf der Region rumläuft, die Region das Asset nicht mehr im eigenen Cache hat, und das Asset im Viewer des Avatars angezeigt werden soll, dann fragt die Region das Asset aus dem Grid ab. Es kann also sein, dass ein Asset monatelang nicht abgerufen aber trotzdem noch benötigt wird.

- Wenn die Datenbank selber schon riesengroß ist, muss der Suchaufwand ungefähr linear mit der Datenbankgröße wachsen. Alleine schon quadratisches Wachstum würde die Suche aus Zeit- und Kostengründen recht bald unmöglich machen.
Zitieren
#9
(19.11.2018, 20:44)Mareta Dagostino schrieb: ...
- Wenn die Datenbank selber schon riesengroß ist, muss der Suchaufwand ungefähr linear mit der Datenbankgröße wachsen. Alleine schon quadratisches Wachstum würde die Suche aus Zeit- und Kostengründen recht bald unmöglich machen.
Danke Mareta für deine korrekte Darstellung des Asset-Dilemmas, aber in diesem letzten Punkt muss ich dich doch korrigieren ... der Suchaufwand steigt leider nicht linear - das wäre schon schlimm genug - sondern einige Abhängigkeiten führen dazu, dass wir es in den Tabellen mit Kreuzprodukten zu tun bekommen und die die wachsen im Quadrat an. Mit anderen Worten wir landen auch schon bei einem eher kleinen Grid für dei Garbage-Collection in Bereichen jenseits von Gut und Böse was den Verarbeitungsaufwand dieser Suche anginge.
Wer nicht weiss wohin er will, der kommt leicht woanders hin.
Zitieren
#10
Genau das meinte ich ja, da habe ich mich wohl ungünstig ausgedrückt. Danke @Anachron für die Klarstellung!
Zitieren


Möglicherweise verwandte Themen…
Thema Verfasser Antworten Ansichten Letzter Beitrag
  OpenSim Datenbank Knight81 3 7.526 16.08.2012, 11:14
Letzter Beitrag: Klarabella Karamell

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste