Database Reference
In-Depth Information
The monitoring provider has also built a portal on which customers can monitor their SLAs.
Customer B, for example, can now use the portal to monitor both its CRM and ERP application database
SLAs. The customer can prepare reports and make them available to the ERP and CRM vendors for
review online, with complete drilldown access to the statements from the same portal.
In this implementation, additional benefits include the following:
•
Improved sharing
. Sharing information with vendors becomes much easier
because drilldown access to issues is provided through a cloud-enabled
portal.
•
Local storage optional.
With the improved solution, customers may decide
to implement the cloud storage only if they're short staffed to handle the
necessary internal database-management activities.
•
External monitoring.
Customers A and B also have the ability to use the
monitoring provider to proactively monitor their ERP products remotely
with specific escalation procedures when the SLAs aren't met. The
monitoring provider can, for example, manage performance issues directly
with the ERP provider.
Other Considerations
This chapter has introduced many important design factors to help you design a solution that uses SQL
Azure. Are few more concepts are worth a glance, such as blob data stores, edge data caching, and data
encryption.
Blob Data Stores
Blobs
are files that can be stored in Windows Azure. What is interesting about blobs is that they can be
easily accessed through REST, there is no limit to the number of blobs that can be created, and each blob
can contain as much as 50GB of data. As a result, blobs can be used as a backup and transfer mechanism
between consumers.
A system can dump SQL Azure tables to files using the Bulk Copy Program (BCP), possibly
compressing and/or encrypting the files beforehand, and store the blobs in Windows Azure.
Edge Data Caching
The chapter briefly mentioned caching earlier, but you should remember that caching may yield the
most important performance gains in your application design. You can cache relatively static tables in
memory, save them as blobs (or a form of in-memory storage) so that other caching systems use the
same cache, and create a mechanism to refresh your data cache using queues in Azure.
Figure 2-17 shows an example of a design that creates a shared cache updated by two ERP systems.
Each ERP systems uses the transparent branching pattern to update shared records in a SQL Azure
database. At this point, however, the edge caches aren't aware of the change in data. At a specific interval
(every 10 minutes, for example) a worker process in Windows Azure picks up the changes and stores
them in blobs. The worker may decide to apply logic to the data and resolve conflicts, if any. Blobs are
then created (or replaced) with the latest cache information that should be loaded. The edge cache
refreshes its internal data by loading the blobs at specific intervals (every 5 minutes, for example) and
