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 "Composite Blob Store" by ThomasMueller
Date Tue, 15 Aug 2017 07:13:31 GMT
Dear Wiki user,

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

The "Composite Blob Store" page has been changed by ThomasMueller:
https://wiki.apache.org/jackrabbit/Composite%20Blob%20Store?action=diff&rev1=5&rev2=6

  = Composite Blob Store =
+ 
+ NOTE:  (Thomas Mueller): Motivation is missing (what problems do we want to solve).
+ 
  
  NOTE:  The current status of this component is a '''proposed feature'''.
  
@@ -9, +12 @@

  
  == Technical Details ==
  Configuration specifies which delegate blob stores comprise the composite blob store, in
order of preference.  Configuration may also indicate "storage filters" - criteria that are
evaluated by the composite blob store to determine whether a delegate is a preferred location
for a blob.  In the case of conflicting delegates where there are multiple matches, the first
matching delegate is the one used.
+ 
+ NOTE:  (Thomas Mueller): What storage filter to use if the binary was created without node
(which is actually the normal case). What if the storage filter changes? Store it in multiple
locations? That would require more space which needs to be avoided (to save cost).
  
  === Storage Filters ===
  Storage filters operate on any combination of the following:
@@ -45, +50 @@

  
  From the user point of view, a blob store write can be either a create or an update.  The
Oak Backend interface doesn't distinguish between creates or updates.  In the case of the
composite blob store there is an important distinction.
  
+ NOTE:  (Thomas Mueller): The DataStore API doesn't allow updates.
+ 
  When a write is requested, the composite blob store must first determine if the blob exists
in a delegate already.  Therefore all delegates have to be traversed looking for a matching
blob before a write is performed.  If a match is found, the write is treated as an update;
if no match is found, the write is treated as a create.
  
  The full algorithm looks like this:
@@ -70, +77 @@

  * If no match is found, search again this time using delegates that are cold-storage delegates
that have filters.
  * If no match is found, search again this time using delegates that are cold-storage delegates
without filters.
  * If no match has been found by this point, return a "not found" response.
+ 
+ NOTE:  (Thomas Mueller): Bloom filters should be mentioned (are they used, if yes how, if
not why not). What about storing the (original) location in the binary reference (as a hint
to speed up reading).
  
  The response to a read request is the result of the first successful read from a delegate.
 In this way the top priority result is always selected.
  

Mime
View raw message