Re: Blobspace versus Unix FileSystem

ptp@fallschurch-acirs2.army.mil (Paul Pryor) writes: >Under Online 4.x, you can not have more than one blob per blob page >in the blobspace. However, you can put more than one blob in a dbspace >page. This have a real big impact on how much disk space you would >allocate when storing blobs, and puts a practical limit on usefulness >of blobspace. I have no idea what options are available under Online >5.x. Can anyone help us out ? There is no change here in 5.0; only one blob is stored on a blob page in blobspace. >We found out that when we decided to move one table's blob data from >the blobspace (average data size was around 120 bytes) into tblspace, >we saved around 30mb of disk space (18,000 blobs). However, I am >concerned about performance impact storing text or binary blobs in >tblspace will have on Online engine. Do any one know ? For blobs that are smaller than one page in size, this is actually preferable than using blobspaces. Multiple blobs _are_ stored on blob pages in tablespace. ..... >On our platform, the Informix page is 2k bytes long, and we can only >specify multiples of the Informix page size for blobspace allocation. >Which means that we can only allocate 2k, 4k, 6k, or 8k.. but not 512, >or even 1024 bytes. Does this restriction exist in Online 5.x ? Yes. >Our blob data size averages around 10k, with a small percentage >approaching 300k or more in size. However, we allocate several >thousand blobs, and I feel that we would save a significant amount >of disk space by switching to unix filesystem, unless newer engines >will let us store more than one blob per blobpage. What is the distribution of blob sizes? The average is 10k, but what size is the largest percentage of your blobs? If you make the blob page size the next increment of 2k above the size of the largest percentage of your blobs you will gain maximum efficiency of space allocation, perhaps at the small expense of performance in reading and writing the blobs. >We are now re-evaluating the issues, and considering the possibility >of storing blobs in the Unix 512 byte block filesystem in order to >reduce wasted space overhead. In addition, we are also going to have >to set up a way to split out several thousand blobs into separate >subdirectories to avoid creating huge flat directory. I would like to >hear about any pros and cons about this approach. The biggest con is >that inodes is a finite resource. We plan to store more than one blob >in an archive, possibly an compressed one, but keep number of files in >an archive reasonably low. This approach will be costly in performance as well as being a maintenance nightmare. >Are there any other approaches that could work well ? Any thoughts >or insights about this subject ? One thought is to create two (or more) blobspaces of different blob page sizes to hold blobs of vastly different sizes. But this has its drawbacks as well, such as denormalization of your schema and implementation of logic to determine into which column to place a data value depending on its size. ___ ___ Senior Consultant / ) __ . __/ /_ ) _ _ __ Informix Software Inc. (303) 850-0210 _/__/ (_(_ (/ / (_(_ _/__) (-' ~/ '(_- 5299 DTC Blvd #740 Englewood CO 80111