Distributed Cache Capabilities - Data Organization

Capability

Description

Weight

Cache Groups

This capability allows caches to be partitioned in groups; this allows cache subdivision that can help the designers to organize the cache allocations across multiple devices. Some caches allows further grouping using group trees.

5

Guideline

Cache groups can be utilized as “tables”. They are very useful to organize the data allocated in the caches. For example, you can use a cache for “Customers” and another one for “Orders”. This type of organization is essential for large caches and should be only ignored if the scenario stores a single type of object (i.e. web session information).

Capability

Description

Weight

Tags support

Supporting tags allows designers to add metadata to the cache items, this feature is usually implemented in conjunction with query trees in order to filter cache items. A cache can allow one or multiple tags per item.

3

Guideline

Adding metadata to a cache item is an interesting feature when the scenario requires rich retrieval models. This is required when you need to use query languages to retrieve items. We recommend limiting the size of the tags and favoring blittable values as they will be indexed. There is an extra hop when reading and writing that can affect performance therefore only used when required.

Capability

Description

Weight

Cache items dependencies

The cache items can be completely independent or in certain technologies can have a dependency on other ones. This is not a relational model as described on other capability but is rather a content dependency that is usually implemented by eviction or notification policies. A cache item with a dependency will relay on the other item to provide the information, it can not leave with the other part.

1

Guideline

The cache item dependency can be very useful when an item is not useful without the other one, for example if you split the orders across single entries, all of them can be related to create an “order”. Do not confuse with relationship models as this applies to completeness rather than relation. This is a faster alternative to relationship models and are usually very fast , as they use tail reference to locate the items.

Capability

Description

Weight

Close-to-caller capability

This feature allows cache to organize data based on taxonomies that can be allocated on different physical repositories. This means that a cache can store certain items on devices near the consumers that need that specific category of items. This allows fast access when distributing across large networks.

2

Guideline

A cache with the ability to configure where the items can be stored (physically) can be an interesting feature if you use multiple geographies. For example if you use session state objects you may want them closer to the web servers but maybe information about products or customer details may be located in a different server array. In certain cache technologies, this will be implemented using local caches on each client. This capability is useful only on large cache deployments.

Capability

Description

Weight

Cache items versioning

This capability allows cache items to be versioned, this means that the cache will store historic information about an item. The cache item is commonly decorated with a version number that increases on each update. There is usually a retention policy and the longer the policy the more space required.

2

Guideline

There are only few scenarios where this capability is useful, one of them is when you need to keep the change history of an item, maybe when storing documents or other type of complex types that requires rollback capabilities. Another scenario is when you need to generate a comparison to analyze what has changed from one version to the other one. Keep in mind that this model has an exponential growth model and can consume a lot of memory, therefore make sure that you run 64bits version of the cache service before using this capability.