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 MattRyan
Date Tue, 15 Aug 2017 20:37:23 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 MattRyan:
https://wiki.apache.org/jackrabbit/Composite%20Blob%20Store?action=diff&rev1=7&rev2=8

Comment:
Added motivation section.

  = Composite Blob Store =
  
  NOTE:  (Thomas Mueller): Motivation is missing (what problems do we want to solve).
+ NOTE:  (Matt Ryan): Added motivation section below, is this sufficient or is more needed
here?
  
  
  NOTE:  The current status of this component is a '''proposed feature'''.
@@ -10, +11 @@

  == Overview ==
  The composite blob store is a multi-source blob store - a logical blob store consisting
of at least two delegate blob stores.  The union of all the data in all the delegate blob
stores is presented to a user of the composite blob store as a single logical "view" of the
data being stored.
  
+ == Motivation ==
+ A composite blob store offers flexibility in storage deployments that can address a number
of user scenarios.  Some of these user scenarios are already identified as existing customer
use cases for binary management in Oak; see UC2, UC9, and UC14 in [[JCR Binary Usecase]].
 These and other possible use cases are outlined in the "Use Cases" section below.  Speaking
generally, some problems that might be addressable by a composite blob store include:
+  * Enabling and/or simplifying development system / production system blob store sharing
scenarios.
+  * Storing blobs closer to the users that use them most, in geo-distributed environments.
+  * Allowing the selection and use of different storage classes for different blobs based
on frequency of access (including auto-archival).
+  * Offering greater control within Oak to manage geo-redundancy and high availability, including
on an object-by-object basis.
+ 
  == 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.
+ Configuration specifies which delegate blob stores comprise the composite blob store, in
some order of preference.  The exact order is defined using a strategy pattern implementation
(see "Delegate Traversal" below) which can be customized by end users.  In the case of conflicting
delegates where there are multiple matches, the first matching delegate will generally be
the one used, although the traversal strategy implementation can provide different conflict
resolution behavior.
  
  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 ===
+ NOTE:  (Matt Ryan): I'm including this here for consideration as a possible future feature.
 In today's implementation, binaries are usually created without providing any node information
- the node doesn't even exist at the time the binary is created.
+ 
+ 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.
+ 
  Storage filters operate on any combination of the following:
   * JCR path
   * JCR node type

Mime
View raw message