<br><br><div class="gmail_quote">2012/3/9 Wade Schuette <span dir="ltr"><<a href="mailto:wade.schuette@gmail.com">wade.schuette@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
M.E. <br>
<br>
You provided a link to an excellent article with many great points
and a compelling argument for keeping images in a separate file
system based on both I/O and database considerations. I yield to
overwhelming experience on that.<br>
<br>
So, how best to architect the format, indexing, and evolution of
the many-terabyte file system for the particular situation in hand,
virtual world assets?<br>
<br></div></blockquote><div>Omg many terrabyte file system, that is a lot. Hoever opensim databases quicky grow to multiple gigabytes ...<br><br>And as the opensim worlds are user generated worlds, lots of people do not really care about things like small textures or small meshes. <br>
<br>In the virtual words assets there are a few cases in wich a lot of data has to be pushed. When users are opening their inventory and when they arrive at a region. (in case of events sometimes 20+ people are arriving at the same time)<br>
<br>When the assets are small in size, maybe less than a 100k then it would not be issue if they are stored in a database. But when a database has to push lots of mb's (a heavy textured and meshed sim can be a multiple of 100mb's) than it would probably be better when the assets are fetched from an file somewhere in a file system (maybe even on another server to preserver bandwidth)<br>
<br>I think it would be good when large assets are stored in a filesystem, and there is just a refence to that location.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Given the localization, clustering and clumping nature of related
textures, it makes me wonder if a tree-structured index system,
instead of a relational-database flat-table structure, would make
the most sense -- ie, some language like MUMPS.<br>
<br>
Has someone else already solved this type of problem in the
literature and practice?<br>
<br>
Your thoughts on that?<span class="HOEnZb"><font color="#888888"><br>
<br>
Wade</font></span><div class="im"><br>
<br>
<br>
On 3/9/12 1:33 AM, M.E. Verhagen wrote:
</div><blockquote type="cite"><div class="im">this is a bit of an old article: <a href="http://mysqldatabaseadministration.blogspot.com/2008/01/i-will-not-blob.html" target="_blank">http://mysqldatabaseadministration.blogspot.com/2008/01/i-will-not-blob.html</a>
<div><br>
</div>
<div><span>qoute:
'The concept of databases is generally suited to storing a
very large number of objects that are small in size. Here,
both "very large" and "small" are relative to each industry
and requirements of the system. When you look at overall
picture, file systems are more suited to handling large
objects, especially if the large object consists of an image.'</span></div>
<div><span><br>
</span></div>
<div><span><br>
</span></div>
<br>
<fieldset></fieldset>
<br>
</div><div class="im"><pre>_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</div></blockquote>
<br>
</div>
<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" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><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>