Details
-
Improvement
-
Resolution: Incomplete
-
Critical
-
None
-
Cheshire-Cat
-
None
Description
- Moving ns_config managed keys to chronicle. We can evaluate keys on a case by case basis, with highest priority to keys that require high level of consistency (indexing, xdcr).
- We can also consider introduction of a "consistency level" per key, such that we can ease the burden on chronicle and provide an equivalent lower consistency provided by ns_config for those who chooses to not move to Chronicle (fts).
- Need to add chronicle equivalent metaKV APIs for service, with transaction semantics.
- With a possible higher utilization of chronicle, we need to validate and address capacity, scale and latency related requirements. Currently, chronicle makes use of resident memory caching, which can be limiting if we need to manage a large number of keys, support high churn levels, and provide low latency.
- As above requirement is valid, we should be encouraging consumers to revisit their model and examine their keys, and their CRUD patterns to better optimize for smaller size and churn.
Attachments
Issue Links
- relates to
-
MB-46085 [System Test] 14 Index rebalance operations failed due to error "Unable to read index layout from cluster 127.0.0.1:8091. err = response status:500 cause:unexpected end of JSON input"
-
- Closed
-