To implement a backing store, you provide a supported database product. Scripts are provided to set up the database for your project’s ontology. If the ontology changes, scripts help you adapt the backing store accordingly (though some manual work may be required depending on the nature of the changes). Existing backing store data can be preserved.
Writes to the backing store can be done in either of two ways: Cache-aside, in which the inference agent handles all writes simultaneously, and offers transaction control; or
write-behind, in which the cache agent handles writes to cache then database.
With cache-aside database write strategy, inference agents manage writes to the cache, the local L1 cache, and the backing store, simultaneously, in the post RTC phase. (The cache agent reads from the backing store, but does not write to it.)
With write-behind database write strategy, the cache management layer handles writes to cache and to the backing store. First it writes data to the cache and then to the backing store.
Writes are managed by the cache agents. For inserts and updates, one write-behind thread is used for each entity type. Deletes are performed by the distributed cache threads (configurable) and are synchronously deleted from the database.
Write operations from multiple writers to the cache are batched. Write-behind batches the writes during the delay period which increases database call efficiency and minimizes network traffic.