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 22:05:39 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=10&rev2=11

Comment:
Simplified write and read algorithms; removed most references to storage filters and cold
storage delegates.

  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:
+ 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.  Some of
these may require additional features beyond those in the defined scope for composite blob
store today.
+ 
+ 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).
@@ -31, +33 @@

  
  ==== Intelligent Delegate Traversal Strategy ====
  
- ===== Delegate Search Order =====
- Basically, the following order is followed.  Specifics for writes and reads are enumerated
below with some special cases.
-  * Delegates with storage filters take highest precedence.
-  * Delegates without storage filters take next precedence.
-  * Read-only delegates always take lower priority to read-write delegates for reads.
-  * Delegates for cold storage reads are always evaluated after every other option is exhausted.
-    * Note that for now writes to cold storage aren't in scope.  This may be done via an
entirely different process.
-    * Cold storage data stores are possible future and don't currently exist.
- 
  ===== Writes =====
- ====== Storage Filters ======
- It is possible, but not required, to configure a delegate with storage filters.  Delegates
that have storage filters always have write precedence over delegates that do not have storage
filters - meaning writes always happen to delegates with filters if the filters match what
is being written.
- 
  ====== Read-Only Delegates ======
  A delegate may be specified as a read-only delegate, in which case it will not accept any
write requests.  If it would otherwise have been chosen for a write request, the request will
defer to the next delegate in the traversal that matches the request, if any.
  
  ====== Delegate Write Preference ======
- The composite blob store fulfills write requests by deferring the write to delegate blob
stores.  This is a bit more complex and requires further explanation.
+ The write algorithm is fairly simple:  Excluding delegates that are read-only, iterate through
delegates to select the first that can accept the write, and perform the write.  Return the
result of this write as the result of the composite blob store write.
  
+ Note that any other versions of the blob in other delegate blob stores may continue to exist,
but would not be used as the most recently written one would be returned for most read requests.
 If other versions end up abandoned they should eventually be garbage collected by the standard
data store garbage collection task.
- 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:
-  * Search for a matching blob through each delegate, excluding those that are cold-storage
and those that are read-only.  Start with delegates that have filters.  If any have filters
that match the blob, and if a match is found, update the blob.
-  * If no match is found, search again this time using delegates that do not have filters.
-  * If no match is found, search again this time using delegates that have filters that do
not match the object.
-    * Configuration change can cause this situation - a blob may originally have been written
to a blob store, and afterward configuration changes such that the blob would not have been
written to that blob store originally.  See "Reading from Non-matching Delegates" below for
more.
-    * If this case occurs, the code should also asynchronously remove the blob from the incorrect
location once it has been written to the correct location.
-  * If no match is found, treat the write as a create.  Repeat the search for a delegate,
excluding cold-storage and read-only delegates, starting with delegates that have filters.
 If any have filters that match the blob, write the blob to that delegate.
-  * If no delegates match, select the first delegate without filters, if any.
-  * If the algorithm fails to select a valid delegate, an error response should be generated
indicating the problem.
  
  ===== Reads =====
  The composite blob store fulfills read requests by deferring the read to delegate blob stores.
  
  ====== Delegate Read Preference ======
+ The read algorithm is also fairly simple:
+  * Excluding delegates that are read-only, iterate through delegates and select the first
that can satisfy the read request.
+  * If no delegate can satisfy the read request, iterate through read-only delegates and
select the first that can satisfy the read request.
+  * Return the result of the delegate read, or an appropriate "not found" error message if
no delegate has a match.
- The full algorithm looks like this:
-  * Search for a matching blob through each delegate, excluding those that are cold-storage.
 Start with delegates that have filters.  If any have filters that match the blob, and if
a match is found, return the blob.
-  * If no match is found, search again this time using delegates that do not have filters.
-  * If no match is found, search again this time using delegates that have filters that do
not match the object.
-    * Configuration change can cause this situation - a blob may originally have been written
to a blob store, and afterward configuration changes such that the blob would not have been
written to that blob store originally.  See "Reading from Non-matching Delegates" below for
more.
-    * If this case occurs, the code should also asynchronously move the blob from the incorrect
location to the correct location.
-  * 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.
  
+ Read-only delegates take lower precedence to writable delegates, as writable delegates may
contain more up-to-date information which would be preferred.
- ====== Reading from Non-matching Delegates ======
- The final read step is necessary to handle situations where blobs are temporarily located
in the "wrong" blob store - in other words, when a blob is located in a delegate where it
would not be written according to configuration.  The most obvious case where this could occur
is in the case of configuration change.  A delegate D may be configured with certain storage
filters, causing Blob B to be written there.  Then the configuration is changed such that
if B were being written now it would not have been written to D.  This final step allows B
to be found in D even though it doesn't match the storage filters.
- 
- When this situation is encountered, the composite blob store should also initiate an asynchronous
background job to move the blob from it's current location to the proper one - the location
where it would be found if it were being created now - on read requests, or for write requests
should write to the correct location and remove the blob asynchronously in the background
from the current location after the write is done.
  
  ==== Read-Only Delegates ====
  The composite blob store supports the notion of a read-only delegate blob store.  One or
more of the delegate blob stores can be configured in read-only mode, meaning that it can
be used to satisfy read requests but not write requests.  An example use case for this scenario
is where two content repositories are used, one for a production environment and one for a
staging environment.  The staging repository can be configured with a composite blob store
that accesses to the production storage location in read-only mode, so tests can execute in
staging using production data without modifying production data or the production store.
@@ -99, +67 @@

  
  === Curation ===
  
- Curation is the process of evaluating the blobs in a blob store to determine if that blob
store is still the correct location for blobs to reside. In the case of the composite blob
store, a reason to curate data may be to gradually move data for which the determination of
"correct" location can change over time.  For example, a change to a JCR property may cause
a blob to belong in a different delegate blob store than where it was originally stored. 
Or a configuration change may mean that blobs need to move to different locations.
+ Curation is the process of evaluating the blobs in a blob store to determine if that blob
store is still the correct location for blobs to reside. In the case of the composite blob
store, a reason to curate data may be to gradually move data for which the determination of
"correct" location can change over time.
  
- The composite blob store should do on-demand curation, meaning that it will initiate a background
move of an object whenever one is requested that is not in the correct location.  However,
doing ongoing or background processing of the entirety of all blob stores to evaluate whether
each is in the correct location is not in the scope of the composite blob store.  However,
it may be prudent to add common curators to the same package in Oak in future efforts.
+ Since writes and reads use the same order of delegate preference, reads will come from the
most recently written location, so if a blob can be found it will always be the most up-to-date
version of it.  Any other blobs, if not referenced anywhere else in the system, will eventually
be garbage collected.
+ 
+ It would be possible to add custom curators, but for now those are rejected features (see
below).
  
  === Rejected Features ===
-  * For the initial implementation of composite blob store, the concept of [[Composite Blob
Store Storage Filters|storage filters]] was considered but rejected.
+  * For the initial implementation of composite blob store, the concept of [[Composite Blob
Store Storage Filters|storage filters]] was considered but rejected for Oak 1.8.
-  * There are currently no cold storage blob stores, so the concept of [[Composite Blob Store
Cold Storage Delegates|cold storage delegates]] was also rejected.
+  * There are currently no cold storage blob stores, so the concept of [[Composite Blob Store
Cold Storage Delegates|cold storage delegates]] was also rejected for Oak 1.8.
+  * Background curation is rejected for Oak 1.8.
  
  == Use Cases ==
+ === Staging Environment ===
+ The composite blob store can be used to address a production/staging deployment use case,
where one Oak repository is the production repository and another is the staging repository.
 The production repository accesses a single blob store.  The staging repository uses a composite
blob store to access a staging blob store as well as the production blob store in read-only
mode.  Thus staging can serve blobs out of either blob store but can only modify blobs on
the staging blob store.
- === Replication Across Storage Regions ===
- The composite blob store can address [[JCR Binary Usecase]] UC2 by storing blobs close to
users.
- 
- In this example, imagine a company with a main office in the United States and branch offices
in Tokyo and Paris.  Here there is a single Oak repository configured using a composite blob
store with three delegates.  The default delegate blob store is in the AWS "us-west-2" region,
in Oregon in the United States, presumably near the main office.  Two other delegate blob
stores are configured, one in the AWS "ap-northeast-1" region (Tokyo), and one in the AWS
"eu-west-2" region (London).  When blobs are stored in Oak, if the "officeLocation" property
is set on the stored blob, that will be used to determine where to store the blob.  Any blobs
stored with "officeLocation" set to any value besides "Tokyo" or "Paris", or blobs stored
without this property set, will be stored in the default delegate blob store.  
  
  {{{
-                          +-----+
-                          | Oak |
-                          +--+--+
-                             |
-            +----------------+----------------+
+ +-----------------+        +-----------------+
+ | Production Env  |        |   Staging Env   |
+ | +-------------+ |        | +-------------+ |
+ | |     Oak     | |    +-----+     Oak     | |
+ | +------+------+ |    |   | +------+------+ |
-            |                |                |
+ |        |        |  Read- |        |        |
-   officeLocation=Tokyo   default    officeLocation=Paris
-            |                |                |
+ |        |        |  Only  |        |        |
-     +------V------+  +------V------+  +------V------+
-     | S3DataStore |  | S3DataStore |  | S3DataStore |
-     |   (Tokyo)   |  |   (Oregon)  |  |   (London)  |
-     +-------------+  +-------------+  +-------------+
+ | +------V------+ |    |   | +------V------+ |
+ | | S3DataStore <------+   | | S3DataStore | |
+ | +-------------+ |        | +-------------+ |
+ |                 |        |                 |
+ +-----------------+        +-----------------+
  }}}
  
  === Hierarchical Blob Store ===
@@ -144, +113 @@

  |       +-----------------> S3DataStore |
  |       |                 +-------------+
  +-------+
- }}}
- 
- === Staging Environment ===
- The composite blob store can be used to address a production/staging deployment use case,
where one Oak repository is the production repository and another is the staging repository.
 The production repository accesses a single blob store.  The staging repository uses a composite
blob store to access a staging blob store as well as the production blob store in read-only
mode.  Thus staging can serve blobs out of either blob store but can only modify blobs on
the staging blob store.
- 
- {{{
- +-----------------+        +-----------------+
- | Production Env  |        |   Staging Env   |
- | +-------------+ |        | +-------------+ |
- | |     Oak     | |    +-----+     Oak     | |
- | +------+------+ |    |   | +------+------+ |
- |        |        |  Read- |        |        |
- |        |        |  Only  |        |        |
- | +------V------+ |    |   | +------V------+ |
- | | S3DataStore <------+   | | S3DataStore | |
- | +-------------+ |        | +-------------+ |
- |                 |        |                 |
- +-----------------+        +-----------------+
  }}}
  
  === S3DataStore Clustering ===
@@ -195, +146 @@

  +-----------------------------+
  }}}
  
+ === Replication Across Storage Regions ===
+ The composite blob store can address [[JCR Binary Usecase]] UC2 by storing blobs close to
users.
+ 
+ (NOTE:  This use case would rely upon [[Composite Blob Store Storage Filters]] which are
not in scope for this release.)
+ 
+ In this example, imagine a company with a main office in the United States and branch offices
in Tokyo and Paris.  Here there is a single Oak repository configured using a composite blob
store with three delegates.  The default delegate blob store is in the AWS "us-west-2" region,
in Oregon in the United States, presumably near the main office.  Two other delegate blob
stores are configured, one in the AWS "ap-northeast-1" region (Tokyo), and one in the AWS
"eu-west-2" region (London).  When blobs are stored in Oak, if the "officeLocation" property
is set on the stored blob, that will be used to determine where to store the blob.  Any blobs
stored with "officeLocation" set to any value besides "Tokyo" or "Paris", or blobs stored
without this property set, will be stored in the default delegate blob store.  
+ 
+ {{{
+                          +-----+
+                          | Oak |
+                          +--+--+
+                             |
+            +----------------+----------------+
+            |                |                |
+   officeLocation=Tokyo   default    officeLocation=Paris
+            |                |                |
+     +------V------+  +------V------+  +------V------+
+     | S3DataStore |  | S3DataStore |  | S3DataStore |
+     |   (Tokyo)   |  |   (Oregon)  |  |   (London)  |
+     +-------------+  +-------------+  +-------------+
+ }}}
+ 

Mime
View raw message