1.19.3. Content Addressable Value storage (CAS) support

eXo JCR supports Content-addressable storage feature for Values storing.

Note

Content-addressable storage, also referred to as associative storage and abbreviated CAS, is a mechanism for storing information that can be retrieved based on its content, not its storage location. It is typically used for high-speed storage and retrieval of fixed content, such as documents stored for compliance with government regulations.

Content Addressable Value storage stores unique content once. Different properties (values) with same content will be stored as one data file shared between those values. We can tell the Value content will be shared across some Values in storage and will be stored on one physical file.

Storage size will be decreased for application which governs potentially same data in the content.

Note

For example: if you have 100 different properties containing the same data (e.g. mail attachment), the storage stores only one single file. The file will be shared with all referencing properties.

If property Value changes, it is stored in an additional file. Alternatively the file is shared with other values, pointing to the same content.

The storage calculates Value content address each time the property was changed. CAS write operations are much more expensive compared to the non-CAS storages.

Content address calculation based on java.security.MessageDigest hash computation and tested with MD5 and SHA1 algorithms.

Note

CAS storage works most efficiently on data that does not change often. For data that changes frequently, CAS is not as efficient as location-based addressing.

CAS support can be enabled for Tree and Simple File Value Storage types.

To enable CAS support, just configure it in JCR Repositories configuration as we do for other Value Storages.


<workspaces>

        <workspace name="ws">

          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">

            <properties>

              <property name="source-name" value="jdbcjcr"/>

              <property name="dialect" value="oracle"/>

              <property name="multi-db" value="false"/>

              <property name="update-storage" value="false"/>

              <property name="max-buffer-size" value="200k"/>

              <property name="swap-directory" value="target/temp/swap/ws"/>

            </properties>

            <value-storages>

<!------------------- here ----------------------->

              <value-storage id="ws" class="org.exoplatform.services.jcr.impl.storage.value.fs.CASableTreeFileValueStorage">

                <properties>

                  <property name="path" value="target/temp/values/ws"/>

                  <property name="digest-algo" value="MD5"/>

                  <property name="vcas-type" value="org.exoplatform.services.jcr.impl.storage.value.cas.JDBCValueContentAddressStorageImpl"/>

                  <property name="jdbc-source-name" value="jdbcjcr"/>

                  <property name="jdbc-dialect" value="oracle"/>

                </properties>

                <filters>

                  <filter property-type="Binary"/>

                </filters>

              </value-storage>

            </value-storages>

Properties:

digest-algo: Digest hash algorithm (MD5 and SHA1 were tested);

vcas-type: Value CAS internal data type, JDBC backed is currently implemented org.exoplatform.services.jcr.impl.storage.value.cas.JDBCValueContentAddressStorageImp;l

jdbc-source-name: JDBCValueContentAddressStorageImpl specific parameter, database will be used to save CAS metadata. It's simple to use same as in workspace container;

jdbc-dialect: JDBCValueContentAddressStorageImpl specific parameter, database dialect. It's simple to use the same as in workspace container;