From: Wolfgang M. <wol...@gm...> - 2006-03-29 15:58:14
|
Hi, >I guess because they are all in .dbx files, and those are loaded into mem= ory > at the beginning of a user session, speeds are comparable to retrieval > from the hard disk-based file system (even if they must be swapped to > the hard disk). Actually, caches are filled on demand and the cache for the persistent DOM is relatively small by default (256 pages, 4K each). It should not have such a big effect. I guess loading chunks of data from one huge file and a single data stream is just faster than loading many single files from the CD-ROM's file system. > I am wondering, and here I would be grateful for your advice, whether > it would be useful to add these resources to the database. Would they > use much more space in the database than in the file system (due to > some indexation)? What would the retrieval speeds be (probably, a big > database file would have to be swapped out from memory to the file > system). How would access and search requests to the actual contents > (the XML resources) be affected? A binary resource is stored into a sequence of linked data pages (in dom.dbx) with just a minimal set of metadata attached to it. Reading/writing the resource data is done by the raw-page storage classes, so the processing overhead is really small. The existance of binary pages within dom.dbx should have only minimal effects on the retrieval of XML resources: binary pages are not cached (!) and do not take part in normal XML processing. They just occupy some space within the collection metadata, which has to be loaded into memory in order to locate resources. So far, I did not experience any performance penalty for storing binary data into the database, though the size of my images did not yet exceed 100 MB (in a few thousand jpg and gif files). The main benefit of storing binary data in the db is to bypass the CDROM's file system. This could certainly have a positive performance effect, but it has yet to be tested with larger amounts of data. Wolfgang |