+1 <br><br>spitting up the asset tabel is brilliant. <br>loading an iar or oar of a few 100mb wich was previously saved on the same grid would than not increase the database with the few 100mb but just a few 100k :)<br><br>
Op zaterdag 3 maart 2012 schreef Justin Clark-Casey (<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>) het volgende:<br>> Hi folks.  As we know, the space required for asset storage in OpenSimulator grows continuously over time.<br>
><br>> I think this is inevitable in a web-like virtual world - distributed garbage collection is practically impossible. However, the current OpenSimulator asset service stores much more data than it needs to since it fails to identify assets that are exact duplicates of each other.<br>
><br>> Previous work in places such as OSGrid, which now uses Dave Coyle's Simple Ruby Asset Service (SRAS) [1], reveals that preventing duplicate assets has a significant effect on storage requirements (I can't remember the exact figures but I think that it's >30%).<br>
><br>> Therefore, I propose to introduce a new core asset service (xassetservice) that will implement asset de-duplication via asset data hashing.  This has already been shown to work by SRAS.  I regard this feature as critical for future plans to extend IAR loading and to improve the 3-months-out-of-the-box OpenSimulator experience.  It does not aim to replace external projects such as SRAS for heavy users.<br>
><br>> I already have a working implementation in the xassetservice git branch (configuration instructions at [2]).  This should not be used in way except for testing - it is still in the prototype stage and can change at any time.  Only a MySQL implementation exists right now.<br>
><br>> The plan would be to have xassetservice exist alongside and independent of the existing asset service.  Only one service can be used at a time and this is determined via config files.  After considerable testing, xassetservice would become the default asset service for new OpenSimulator installations.  The existing asset service would continue alongside for a very, very, very long time.<br>
><br>> Since asset datasets are so large and critical there would be no automatic migration between assetservice data and xassetservice.  Instead, there would be an external migration tool.<br>><br>> I may also take this opportunity to implement other asset service features, such as data storage on disk instead of database (possibly nicking stuff from kcozen's previous patch for this) and maybe compression (though I'm currently thinking that the cons of this outweight the pros).<br>
><br>> More detail is at [3].  Comments or alternative implementation suggestions from developers, etc., are welcome.<br>><br>> [1] <a href="https://github.com/coyled/sras">https://github.com/coyled/sras</a><br>
> [2] <a href="http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service#Testing">http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service#Testing</a><br>> [3] <a href="http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service">http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service</a><br>
><br>> --<br>> Justin Clark-Casey (justincc)<br>> <a href="http://justincc.org/blog">http://justincc.org/blog</a><br>> <a href="http://twitter.com/justincc">http://twitter.com/justincc</a><br>> _______________________________________________<br>
> Opensim-dev mailing list<br>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br><br>-- <br>Groningen en Hannover Opensims:  
<span style="color:rgb(50,61,86);font-family:'Trebuchet MS',Helvetia,Tahoma,Verdana,Arial,sans-serif;font-size:16px;text-align:left;background-color:rgb(255,255,255)">secondlife://meverhagen.nl:8002:Hannover ZW/ </span><br>