Views
Version Store
From alfrescowiki
NOTE: This functionality is available since Alfresco 3.0.
Contents |
Project Overview
The design of the underlying Alfresco DM version store has not changed since the original releases of Alfresco ECM. The store is also known as the "lightWeightVersionStore". The primary goal for this project is to refactor the storage mechanism and implement a "lighter" version store ! This should increase performance and reduce disk usage (both in terms of DB metadata and lucene index size, if indexing is configured). A secondary goal is to also provide a migration path for existing version metadata. There are no immediate plans to change the version store API as part of this refactor.
Version API
The current API remains unchanged. In summary, the API methods include:
- createVersion
- getVersionHistory
- getCurrentVersion
- deleteVersion
- deleteVersionHistory
- deleteVersion (since 3.1)
- restore
- revert
- getVersionStoreReference
- registerVersionLabelPolicy
Version Model / Store
Previous model
This model is used in Alfresco 1.x, 2.x (and also Labs 3a).
Refer to version_model.xml
The previous model caused a large increase in the number of nodes/properties, when creating each "version" node and associated model structure. For example, each versioned property was exploded into a separate 'ver:versionedProperty' node.
The 'workspace://lightWeightVersionStore' uses the version1 store implementation.
New model
This model is used in Alfresco 3.x (since Labs 3b).
Refer to version2_model.xml
The new model creates a version copy of the existing the node. The node's properties and child associations are versioned as standard properties and child associations within the version store (they are no longer exploded out into a separate meta model). Note: the auditable properties (creator, created, modifier, modified) are treated as a special case.
The 'workspace://version2Store' uses the version2 store implementation.
Performance and Sizing
The primary goal for this phase is to refactor the storage mechanism to decrease version store size (DB size and lucene index size, if configured) and increase version store performance.
Lucene indexing
Lucene indexing is not configured by default for the version store(s) (for releases 2.1.6, 2.2.2, 3.1.1, 3.2.0 and higher). For example:
<!-- -->
<!-- Generic factory for making indexers and searchers for a given protocol or store -->
<!-- -->
<bean id="indexerAndSearcherFactory" class="org.alfresco.repo.service.StoreRedirectorProxyFactory">
<property name="proxyInterface">
<value>org.alfresco.repo.search.impl.lucene.LuceneIndexerAndSearcher</value>
</property>
<property name="defaultBinding">
<ref bean="admLuceneIndexerAndSearcherFactory"></ref>
</property>
<property name="redirectedProtocolBindings">
<map>
<entry key="workspace">
<ref bean="admLuceneIndexerAndSearcherFactory"></ref>
</entry>
<entry key="avm">
<ref bean="avmLuceneIndexerAndSearcherFactory"></ref>
</entry>
</map>
</property>
<property name="redirectedStoreBindings">
<map>
<entry key="workspace://lightWeightVersionStore">
<ref bean="admLuceneUnIndexedIndexerAndSearcherFactory"></ref>
</entry>
<entry key="workspace://version2Store">
<ref bean="admLuceneUnIndexedIndexerAndSearcherFactory"></ref>
</entry>
</map>
</property>
</bean>
Unit Tests
Examples of unit tests that exercise the VersionService include:
- org.alfresco.repo.version.VersionTestSuite
- org.alfresco.repo.coci.CheckOutCheckInServiceImplTest
- org.alfresco.repo.model.ModelTestSuite (>= 3.3) or org.alfresco.repo.model.ml.MultilingualTestSuite (<= 3.2)
- org.alfresco.repo.cmis.rest.test.AspectTest (>= 3.3) or org.alfresco.repo.cmis.rest.test.CMISTest (<= 3.2)
- org.alfresco.repo.lock.LockBehaviourImplTest
- org.alfresco.repo.rule.RuleServiceCoverageTest
Upgrade and Migration (from 2.x to 3.x)
NOTE: If you're installing a new instance of Alfresco 3.x then this section does not apply.
IMPORTANT: Labs releases and associated upgrades are unsupported, other than via the community. However, if you're attempting to upgrade an existing (pre-Labs 3b) system then please refer to the General Upgrade Process. As with any upgrade, it is important that a full backup is taken prior to upgrade. You should also test that you can restore your system from your backup, and this should also allow you to test the upgrade (on your restored/test copy of the system).
The migration will occur automatically during startup of the upgraded system. Any existing version history metadata will be automatically migrated from the old store (workspace://lightWeightVersionStore) to the new version store (workspace://version2Store) when the upgraded server is restarted. Depending on the amount of version data, this may take some time. Note: For Alfresco 3.1 or 3.2, frozen node associations (ver:versionedAssoc), if any, will not be migrated. This is fixed for upcoming Enterprise 3.3.
The migration occurs in two phases. The primary phase is to migrate (ie. "copy") the version data to the new version store. This is applied as synchronous patch during startup. The patch will provide estimates as to the approximate time of completion. The secondary phase is to purge (ie. "delete") the old version data from the old version store. This is done asynchronously in the background after startup. The background delete will also provide estimates as to the approximate time of completion. The upgrade log will show, for example:
.... INFO [admin.patch.PatchExecuter] Applying patch 'patch.migrateVersionStore' (Migrate from lightWeightVersionStore to version2Store). INFO [repo.version.VersionMigrator] Completed migration of <...> old version histories (to new version store) in <...> secs .... INFO: Server startup in <...> ms .... INFO [repo.version.VersionMigrator] Completed background deletion of <...> migrated version histories (from old version store) in <...> secs ....
Future Ideas
- Copy-On-Write and/or Lazy Versioning
- Background and/or JIT Migration
Remarks
(nick heylen) If you look at the current version store, all versioned documents are stored at the same level under the lightWeightVersion store. I mean, if you have 100000 versioned documents there are 100000 entries at the root level of the version store. Doesn't this also cause performance issues? Maybe this should be changed also? p.s. same problem with the archive and multilingual store.
(janv) Thanks for the feedback. This should not cause performance issues, since we directly access a version history entry (via node uuid).
