Database Reference
In-Depth Information
The effect of the cache is visible when you connect to SQL Azure. Considering that connecting to a
SQL Azure database takes up to 250 milliseconds the first time, memory access is significantly faster. The
importance of the cache increases as the number of records increases and the number of databases
increases in the shard.
The cache provided by this library also provides a time to live (TTL) mechanism that implements an
absolute expiration or a sliding expiration scheme. An absolute expiration resets the cache automatically
at a specific time in the future, whereas the sliding setting moves the expiration time if the cache items
are used before expiring. The following code shows how the caching is implemented. Line 1 creates a
CacheItemPolicy
used to define the behavior of the cache. Line 3 implements the sliding window cache,
and line 5 implements the absolute approach:
1)
CacheItemPolicy cip = new CacheItemPolicy();
2)
if (UseSlidingWindow)
cip.SlidingExpiration = defaultTTL;
4)
else
5)
cip.AbsoluteExpiration =
new DateTimeOffset(System.DateTime.Now.Add(defaultTTL));
6)
MemoryCache.Default.Add(cacheKey, dt, cip);
You can enhance this caching technique in multiple ways. For example, the
DataTable
object stored
in the cache can be compressed when it contains many rows. Compression algorithms tend to increase
latency, but the overall performance benefits may be worth a slight delay.
Another way to enhance this caching storage is to create different cache containers, so you can
control at a more granular level which container holds which kind of data. Doing so lets you control a
different setting per container, for example; or you may decide to always compress one cache container
but not another.
Finally, the cache provided in this library isn't distributed; it's local to the machine running the
library. If you need to develop a more robust cache, consider looking into the Windows Server
AppFabric; its caching technology provides enterprise-level capabilities.
3)
■
Note
For more information about the Windows Server AppFabric, visit
http://msdn.microsoft.com/appfabric
.
Updating and Deleting Records in the Shard
At this point, you're ready to see how updates and deletes take place through the shard. Updates and
deletes against the databases in the shard can either be performed for records in a given database or
against all databases. At a high level, here are some guidelines you can use to decide on an approach:
•
Update or delete records in a single database.
You update or delete one or more
records in a database when you already know the database GUID to use. This is
the case when you use the shard to retrieve records, because the database GUID is
provided for all records returned.
•
Update or delete records across databases.
Generally speaking, you update or
delete records across databases in the shard whenever you don't know which
database a record is in, or when all records need to be evaluated.
