Using Read-through Cache & Write-through Cache
Author: Iqbal Khan
With the rapid growth of high-transaction web apps, service-oriented architecture (SOA), grid computing, and other server applications, traditional data storage often struggles to keep up. The reason is that data storage systems cannot scale out like application architectures that can scale out by adding more servers.
In these situations, in-memory distributed cache offers an excellent solution to data storage bottlenecks. It spans multiple servers in a cluster to pool their memory together and keep the cache synchronized across all nodes. This cluster can scale out indefinitely, just like the application servers. This reduces the load on the underlying data storage, eliminating it as a scalability bottleneck.
There are two main ways people use a distributed cache:
- Cache-aside: This is where the application is responsible for reading and writing from the database, and the cache doesn't interact with the database at all. The cache is "kept aside" as a faster and more scalable in-memory data store. The application checks the cache before reading anything from the database and updates the cache after making any updates to the database. This way, the application ensures that the cache is kept synchronized with the database.
- Read-through / Write-through: This is where the application treats cache as the main data store and reads data from it and writes data to it. The cache is responsible for reading and writing this data to the database, thereby relieving the application of this responsibility.
Benefits of Read-through Cache & Write-through Cache over Cache-aside
Cache-aside is a very powerful technique and allows you to issue complex database queries involving joins and nested queries, and manipulate data any way you want. Despite that, Read-through / Write-through has various advantages over cache-aside as mentioned below:
- Simplify application code: In the cache-aside approach, your application code continues to have complexity and direct dependence on the database, and even code duplication if multiple applications are dealing with the same data. Read-through / Write-through moves some of the data access code from your applications to the caching tier. This dramatically simplifies your applications and abstracts away the database even more clearly.
- Better read scalability with Read-through Cache: There are many situations where a cache-item expires, and multiple parallel user threads end up hitting the database. Multiplying this by millions of cached items and thousands of parallel user requests, the load on the database becomes noticeably higher. But Read-through keeps cache item in the cache while it is fetching the latest copy of it from the database. It then updates the cache item. The result is that the application never goes to the database for these cache items and the database load is kept to a minimum.
- Better write performance with Write-behind: In cache-aside, the application updates the database directly in a synchronous manner. Whereas Write-behind caching lets your application quickly update the cache and return. Then it lets the cache update the database in the background.
- Better database scalability with Write-behind: With Write-behind, you can specify throttling limits so the database writes are not performed as fast as the cache updates, and therefore the pressure on the database is not much. Additionally, you can schedule the database writes to occur during off-peak hours, again to minimize pressure.
- Auto-refresh cache on expiration: Read-through allows the cache to automatically reload an object from the database when it expires. This means that your application does not have to hit the database in peak hours because the latest data is always in the cache.
- Auto-refresh cache on database changes: Read-through cache automatically reloads an object from the database when its corresponding data changes in the database. This means that the cache is always fresh, and your application does not have to hit the database in peak hours because the latest data is always in the cache.
Read-through / Write-through is not intended to be used for all data access in your application. It is best suited for situations where you're either reading individual rows from the database or reading data that can directly map to an individual cache item. It is also ideal for reference data that is meant to be kept in the cache for frequent reads, even though this data changes periodically.
Implementing a Read-through Cache
A Read-through provider in NCache is a custom class IReadThruProvider in .NET that fetches data from the source (e.g., SQL Server) when not found in cache. NCache calls LoadFromSource automatically. To use it, implement the provider, deploy it using the NCache Management Center or Command Line tool, and enable it in cache settings.
public class SampleReadThruProvider : IReadThruProvider
{
public void Init(IDictionary parameters, string cacheId)
{
// Initialize resources if needed
}
public ProviderCacheItem LoadFromSource(string key)
{
var value = Database.GetData(key);
return new ProviderCacheItem(value);
}
public IDictionary<string, ProviderCacheItem> LoadFromSource(ICollection<string> keys)
{
var result = new Dictionary<string, ProviderCacheItem>();
foreach (string key in keys)
{
result[key] = new ProviderCacheItem(Database.GetData(key));
}
return result;
}
public ProviderDataTypeItem<IEnumerable> LoadDataTypeFromSource(string key, DistributedDataType dataType)
{
ProviderDataTypeItem<IEnumerable> dataTypeItem = null;
switch (dataType)
{
case DistributedDataType.List:
dataTypeItem = new ProviderDataTypeItem<IEnumerable>(
new List<object> { Database.GetData(key) });
break;
case DistributedDataType.Dictionary:
dataTypeItem = new ProviderDataTypeItem<IEnumerable>(
new Dictionary<string, object> { { key, Database.GetData(key) } });
break;
case DistributedDataType.Counter:
dataTypeItem = new ProviderDataTypeItem<IEnumerable>(1000);
break;
}
return dataTypeItem;
}
public void Dispose()
{
// Clean up resources if needed
}
}Init() performs certain resource allocation tasks like establishing connections to the main data source, whereas Dispose() is meant to reset all such allocations.
Implementing a Write-through Cache
A Write-Through provider in NCache is a custom class that implements IWriteThruProvider to persist cache updates (add, update, remove) directly to the database whenever the cache is updated.
To use it, implement the interface, deploy it using the provider in NCache Management Center, and enable it in the cache configuration.
public class SampleWriteThruProvider : IWriteThruProvider
{
public void Init(IDictionary parameters, string cacheId)
{
// Initialize resources if needed
}
public void Dispose()
{
// Clean up resources if needed
}
public OperationResult WriteToDataSource(WriteOperation operation)
{
var product = operation.ProviderItem.GetValue<Product>();
switch (operation.OperationType)
{
case WriteOperationType.Add:
// Add product to data source
break;
case WriteOperationType.Update:
// Update product in data source
break;
case WriteOperationType.Delete:
// Delete product from data source
break;
}
return new OperationResult(operation, OperationResult.Status.Success);
}
public ICollection<OperationResult> WriteToDataSource(ICollection<WriteOperation> operations)
{
var results = new List<OperationResult>();
foreach (var op in operations)
results.Add(WriteToDataSource(op));
return results;
}
public ICollection<OperationResult> WriteToDataSource(ICollection<DataTypeWriteOperation> operations)
{
var results = new List<OperationResult>();
foreach (var op in operations)
{
// Handle Create/Add/Delete/Update for data structures
results.Add(new OperationResult(op, OperationResult.Status.Success));
}
return results;
}
}To learn more about Read-through and Write-through caching, please see the following blogs: