M.E.
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.
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?
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.
Has someone else already solved this type of problem in the literature
and practice?
Your thoughts on that?
Wade
On 3/9/12 1:33 AM, M.E. Verhagen wrote:
this is a bit of an old article:
http://mysqldatabaseadministration.blogspot.com/2008/01/i-will-not-blob.html
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.'
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
