-
Type:
New Feature
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 8.10
-
Component/s: Core MarkLogic, Core MongoDB
-
Sprint:nxfit 8.4.8
-
Story Points:13
Caching or not Caching
The initial DBS design does not include any caching and actually at least for standard use cases with MongoDB this does not create any performance issues.
However, recent work have shown that this "no cache" approach has some limitations :
- with the Marklogic backend having cache is critical to be able to get decent performances
- with a big sharded MongoDB cluster, some queries become the bottleneck during the import process
Sharing the cache
Currently, we have tested both Marklogic and sharded MongoDB with ad-hoc cache :
- directly inside the storage adapter: we have different code for MongoDB and Marklogic
- we have no invalidation management
The goal is to have one shared cache implementation, at DBS level.
Cache On/Off
On the contrary of VCS where the caching is a built-in concept, the DBS cache should be configurable :
- define cache size
- enable or disable cache
The underlying idea is that since in most MongoDB use cases the cache is not really required, we may want to disable it.
Invalidations
We need to implement an invalidation system based on Redis: we should be able to reuse some of the code (or at least principles).
- depends on
-
NXP-21013 Fix hotreload crash with mongodb
-
- Resolved
-
- is related to
-
NXP-21663 Fix DBS cache metrics record
-
- Resolved
-
-
NXP-21664 Add approximative size of DBS cache in metrics
-
- Resolved
-
- is required by
-
NXP-21446 Fix DBS cache invalidation when running in cluster mode
-
- Resolved
-
-
NXP-29678 Query failure on duplicate documents returned
-
- Resolved
-
-
NXP-20595 Reduce the number of DBS queries during document creation
-
- Resolved
-