Image Format for Large Storage in relation to Nature of Storage system
===

Now, I have read these questions which may have a relation with this question: <a href="http://stackoverflow.com/q/1961191/431620">http://stackoverflow.com/q/1961191/431620</a>, <a href="http://stackoverflow.com/q/4580862/431620">http://stackoverflow.com/q/4580862/431620</a>, <a href="http://serverfault.com/q/95444">http://serverfault.com/q/95444</a>. <br><br>
The following things i have found out, before i ask my question: 
<pre>
1. Facebook uses <b>Haystack</b> (something CLOSED-SOURCE to the open-source world) <br>which is very efficient. Its a form of File system storage, engineered for speed<br> and large metadata management.<br>2. Any Operating System has a file limit in directories and may start to perform <br>extremely poorly when this limit is being exceeded.<br>3. Most NoSQL developers, have found it easy to use <b>CouchDB / CouchBase Server</b><br> to handle images as it handles it as an attachment, glued to a document (record<br> in the database). However, still, this is file system storage.<br>4. HDFS, NFS, ZFS, are all File systems that may make it easy to handle large<br> distributed data. However, at applications like facebook, they could not help<br>5. Any proper form of caching is very essential to highly Image dependent<br> applications<br>6. Some PHP developers (mostly) have used MySQL to keep image meta-data while<br> creating folders and sub-folders (matching the meta-info) on the file system.<br> Each image will have a random hash name in relation to the meta-data in the <br>database to enable fast location on the file system
</pre>

After understanding these statements and many more others, i have come to realise that its very expensive to keep billions of constantly growing number of Images on the file system. If any one were to use Cloud storage like `Amazon S3`, it would kill the business because of the high image traffic as well as storage from your application. <br><br> I have evaluated the use of <a href="http://www.couchbase.com/">CouchBase Server</a>, managing images as attachments. However, for an image growing application, this is also a file system storage and i wonder how Couch base would behave if, hundreds/thousands of people are accessing images at the same time. I could use <a href="https://cloudant.com/">Cloudant/Big Couch</a> which has auto-sharding/load balancing. The main point remains that the NoSQL solution would as well be keeping images on the file system and when the images are being requested for at a high concurrent rate, this might bring the whole service down (images can be heavy).<br><br><b>My Thinking </b><br><br> I am thinking of managing my images as <a href="http://en.wikipedia.org/wiki/Scalable_Vector_Graphics">`SVG`</a> format. This is because, i think that i can treat this SVG data as text in my storage. Now, most NoSQL databases have a size limit on the document (record) size atleast not greater than 4MB (not sure). This presents a problem, because SVG file can even reach 6-10MB depending on the image. So, i think i cannot use Couch base server for SVG storage. Besides, the nature of the application is such that, the image data keeps growing and never archived/ never removed: and couch base is not good for such data (highly persistent and unchanging data).<br><br>This brings me back to RDBMS (especially Oracle) which are known for good text compression. If i get SVG data plus its meta data and store it as a `CLOB` in an Oracle Database, i have a feeling that this could work. I have heard that an Oracle Table can even grow to terabytes, probably with partitioning or some-kind of fragmentation. But the whole point is that, for an oracle table to reach 20GB, containing text, i think this would be a lot of data.<br> Now, my questions arise from all the above findings:<br><br>1. Why do developers keep choosing File System storage of images as opposed to SVG, which in my (probably naive) thinking, is that SVG can be handled as Text, hence can be compressed, encrypted, digested, split, easilly stored e.t.c. ? <br><br>2. What complexities are there when an application works with images entirely as SVG, serving SVG to browsers instead of actually image files ? <br><br> 3. Which is technically more memory disturbing to a Webserver: Serving images read from file system (.png, .jpg, .gif) and serving images as SVG (probably from a Database, or from a middle tier) especially under heavy loads, an example scenario of Facebook ? <br><br>4. SVG seems to not loose quality when rendered under different "Zooms" or Resolutions, why still, haven't developers worked with SVG alot in image dynamic applications ? i mean, is there any known loss of quality in converting from PNG, JPG or GIF to `SVG` ? <br><br> 5. Is my view of using RDBMS like Oracle/MySQL Cluster very naive, for storing highly persistent meta-data as well as the persistent SVG data ? 
<br><br> Please highlight, and give your suggestions about large image storage formats. Thanks