jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "DataStore" by ThomasMueller
Date Mon, 21 Sep 2009 09:08:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "DataStore" page has been changed by ThomasMueller:
http://wiki.apache.org/jackrabbit/DataStore?action=diff&rev1=43&rev2=44

  == File Data Store ==
  
  The file data store stores each binary in a file. The file name is the hash code of the
content. When reading, the data is streamed directly from the file (no local or temporary
copy of the file is created). The file data store does not use any local cache, that means
content is directly read from the files as needed. New content is first stored in a temporary
file, and later renamed / moved to the right place.
+ 
+ Because the data store is append-only, the FileDataStore is guaranteed to be consistent
after a crash (unlike the BundleFsPersistenceManager). It is usually faster than the database
data store, and the preferred choice unless you have strict operational reasons to put everything
into a database.
  
  ==== Configuration ====
  
@@ -173, +175 @@

  
  == Future ideas ==
  
- Theoretically the data store could be split to different directories / hard drives. Content
that is accessed more often could be moved to a faster disk, and less used data could eventually
be moved to slower / cheaper disk. That would be an extension of the 'memory hierarchy' (see
also http://en.wikipedia.org/wiki/Memory_hierarchy). Of course this wouldn't limit the space
used per workspace, but would improve system performance if done right. Maybe we need to do
that anyway in the near future to better support solid state disk.
+ Theoretically the data store could be split to different directories / hard drives. Currently
this can be done manually moving directories to different disks and by creating softlinks.
Content that is accessed more often could be moved to a faster disk, and less used data could
eventually be moved to slower / cheaper disk. That would be an extension of the 'memory hierarchy'
(see also http://en.wikipedia.org/wiki/Memory_hierarchy). Of course this wouldn't limit the
space used per workspace, but would improve system performance if done right. Maybe we need
to do that anyway in the near future to better support solid state disk.
  
  Other feature requests:
   * A replicating data store

Mime
View raw message