Caching and Persistence
Caching can not only be a big boost to performance but can also be essential when setting up Infinite Scale via container orchestration. Persistence is recommended for some services, for example, to manage event data for later processing, or, not limited to but especially when the underlying services are scaled via container orchestration providing consistent data across instantiated services.
Performance: Caching does not need to be persistent and in case of outages, the cache is rebuilt and no information is lost. This is typically used for caching metadata and filesystem access (stat).
Persistence: With this kind of store, saving information temporarily on a persistent media is key. Persistence stores are used, for example, for generated events returning status info to users when requested. If this data gets lost or is not consistently available over the instantiated services, users will be inconsistently informed about state changes that happened.
Scaling: When services are scaled horizontally (instantiated), a common and persistent base for generated data is necessary.
Identifying Caches by their Name
Performance caches can be identified via environment variables ending with
xxx_CACHE_STOREwhich is valid for both local and global ones.
Persistent caches can be identified via environment variables ending with
xxx_STOREwhen using local ones and
OCIS_PERSISTENT_STOREwhen using global ones. Note that no other trailing name components are present when using local ones.
Memory has best performance but is not suitable for all requirements as it has no persistence and is limited to the service on the running server. It can be used for deployments where:
persistence is not a requirement (issue: restart/reboot) and
scaling of services is not required (issue: instantiation).
External products like
nats-jswhich are independent services not related to Infinite Scale. They are usually installed on separate hardware requiring their own performance, availability and scalability measures. These products are connected via a fast network. Infinite Scale connects to these store types and uses their services like a black box.
Local vs Global Configuration
Performance and persistent types can be configured per service individually or via global environment variables. See the Notes for Environment Variables for details with regards to settings precedence.
metadatacaches individually for each service and not via the corresponding global environment variable, all caches must have the same configuration (access to the same cache) to provide consistent results.
Identifying Services that Use Caching
See the Global Environment Variables for services where caching or persistence is used. Search for: