Re: Store images in Database or FileSystem

[Jean-Marc Desvaux]

Hector,

ADF handle both.

You are right about content stored in the database will be slower and won't be cached.

A general rule could be to store in the Database (LOBs) when the content is not application interfaces images etc... Examples : employee ID pictures, documents etc...

And for more or less static files used by your ADF application pages, you can store in a file system or a jar file for better performance (thanks to caching mainly) :

http path for application images that have chances to change and that are used by all applications and jar file(s) for icons and other images that are not meant to change apart when from when deploying a new app version.

Another solution is to have a proper Content server that you can integrate with ADF (APIs + Security) and that can provide the necessary caching and performance. But that will be more complex to manage and should be considered only as part of a content management strategy, with a wider scope than just your ADF apps.

-Jean-Marc

[Mohammad Al Banna]

I came across the two scenarios when working on two different ADF projects.

These rules apply to both scenarios:

   -You have to consider JVM heap size for file Upload

   -You might think of having two network cards on your weblogic server  (one for inbound and the other for outbound traffic).In both cases you are streaming either to file system or to Database

   -And you need to set uploaded-file-temp-dir, max memory and max disk in Trinidad config file.

Something must be highly considered is your Database Storage and Backup Strategies, in which it will be effected with media stored at DB.

Also passivation/activation for session state when using DB as Storage. 

On Thu, Jun 6, 2013 at 7:48 PM, Hector Gonzlaez <hgste...@gmail.com> wrote:

Hello All,

Many times I have this kind of conversation, Do we have to store images in Database or it is better to leave them on FileSystem

I think if we are dealing with a Multimedia solution, then we have to store every Song, Movie, Picture, etc in the Database, otherwise we have to storage them on FileSystem

As far as I know, in terms of performance it is not recommended, to storage in Databases multimedia files, when it is not a Multimedia solution, but it is easier to Backup DB then multiple files on FileSystem.

In the other hand when an image is stored on DB we need to extract it either on memory or FileSystem, then display it.

I would like to discuss a little bit about this and the way ADF handle these two scenarios.

Thanks,

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mohammad Al Banna]

I am talking about the server that will run your application, you could consider having two network cards on that machine,

 one for clients using the application, the second for media retrieval from database. you could coordinate with your network admin to make the proper rout for network traffic. (either in RAC or single DB).

Passivate/Activation process occurs inside ADF application life cycle, in which it preserve the current session state and queries executed when AM switch the DB connection to another user session. When working with large LOB fields it will passivate lob data to ps_txn table in which it will grow rapidly. ofcourse you can overwrite this behavior. When using file system as storage media data will not be passivated which mean faster session state retrieval

this is my understanding, if I am wrong correct me!

On Tue, Jun 11, 2013 at 2:26 AM, Hector Gonzlaez <hgste...@gmail.com> wrote:

mj.albanna,

You take a very good recommendation: to take care of Inbound request while the multimedia information is being served.

I have an Oracle RAC with 4 nodes, each of one 4 cores & 16 GB RAM and

One Cluster with 4 nodes, each box also 16GB RAM.

I am sure then Oracle should have a sort of  Sizing guide for handle JVM memory, have you seen it?

Thus I will have Oracle RAC, I could not see yet, "Also passivation/activation for session state when using DB as Storage."  Could you be a little bit more specific with you idea.

I really thank you for your words.

[Chad Thompson]

On Thursday, June 6, 2013 11:48:57 AM UTC-5, Hector Gonzlaez wrote:

Hello All,

Many times I have this kind of conversation, Do we have to store images in Database or it is better to leave them on FileSystem

I think if we are dealing with a Multimedia solution, then we have to store every Song, Movie, Picture, etc in the Database, otherwise we have to storage them on FileSystem

As far as I know, in terms of performance it is not recommended, to storage in Databases multimedia files, when it is not a Multimedia solution, but it is easier to Backup DB then multiple files on FileSystem.

In the other hand when an image is stored on DB we need to extract it either on memory or FileSystem, then display it.

 I'm not certain that ADF handles files / images differently than other approaches, but I'll note a few things:

* In general, it's best in applications (like ADF apps) that you want to cluster to be heavily dependent on filesystems - you'll quickly run into the issue of 'which filesystem', as nodes in a cluster will be running on different file systems.  So as a general rule, images that are part of your app (like those you include with af:image) will likely be part of your code base (Git / SVN) unless there is a strong need to change the images.

* Images that are part of a runtime (upload, etc.) should be stored in a database (or WebCenter Content!) to serve as a 'canonical' version with caching strategies applied to serve images from filesystems or even Content Delivery Networks.  (Storing images in a database or content mgmt system will also give you some ability to recover crashed servers and/or spin up new ones - there's also the oft-employed solution of having a shared directory on an NFS mount or something similar shared across servers that could work for your scenario - but be aware of the pros and cons of relying on networked file systems and have a good backup plan in place.  Talk to your operations group if you have one.)

Shorter advice:  it's good to use a filesystem for serving 'static' content, it's not good to trust it.

Shorter advice #2:  Don't serve multimedia from a 'single server' solution - long downloads can block web servers from creating child processes slowing things down for everyone.  Use CDNs where you can - Amazon's "Cloud Front" (for example) can be set up to serve multimedia content more efficiently (and faster!) with streaming distributions than you can off of a local filesystem.