Of course, the larger the website or the application, the more likely the cache is stored on multiple nodes instead of just one.
When there’s inconsistency across cached nodes
Cache coherence vs consistency update#
Should a user have the misfortune of choosing to access obsolete data between the time the message has been sent by the server to update the cache and the time when that message is received by the cache and acted upon, the result can be data that is obsolete, incorrect or both.ģ.
Delays can be affected both by available processing speed as well as by network throughput. Once again, however, this change requires processing power, and it takes time. (In the latter case, the next time the value is requested, it will be accessed from the primary database and then from the cache thereafter.) Under normal circumstances, this communication happens relatively quickly and the cached item is either updated or removed in order to maintain cache consistency. Each time a value is updated in the primary database, a message is sent to the cache, instructing it either to update the changed value or to remove it entirely. This problem overlaps a little with the previous problem. When there’s a delay in updating cached results Of course, if a user attempts to access obsolete data during this gap, that gamble is lost.Ģ. The challenge comes in finding the sweet spot, a kind of Goldilocks area that lies between checking for updates too frequently or not enough. The same processor may simultaneously be handling numerous other functions or transactions, some of them as important, if not more so, than updating the cache. However, each check comes at the cost of processor resources. This is influenced by how frequently the application checks the cache. The problem arises during the gap between when the data in the primary database is changed and when the cache is adjusted to reflect said change. If the data isn’t in the cache, the application queries the primary database and deposits the result in the cache on the way back to the user. This strategy is known as the cache-aside pattern. Assuming the item exists in the cache, it will be returned far more quickly than it would from the primary database. When changes to the primary database aren’t reflected in the cacheīecause accessing data via a cache is, by definition, faster than accessing the data via the primary database, if a specific item is requested, the cache will be consulted first.
In fact, there are three pitfalls that can derail it:ġ. Although this may seem like a straightforward goal, it’s easier in theory than in practice. Of course, these advantages rest on the fundamental assumption that the data in the cache-or caches-always maintain the same values as the source data. While each call to the primary database can be expensive in terms of both time and processing power, a call to a cache can be lightning-quick and have no impact on the primary database. Why do we bother with caches in the first place? The principal advantage of an enterprise cache is the speed and efficiency at which data can be accessed. In fact, one of the greatest challenges in managing the operation of an enterprise database is maintaining cache consistency. If you believe Ralph Waldo Emerson, a foolish consistency may be the hobgoblin of little minds, but when it comes to implementing a scalable, successful enterprise-level caching strategy, there’s nothing foolish about consistency.
Cache coherence vs consistency how to#
A primer you need to understand what application caching is, why and when it’s needed, and how to get the best performance from your applications.
0 kommentar(er)
