Bu içerik dilinizde bulunmamaktadır ancak İngilizce sürümüne buradan bakabilirsiniz.

1 / 1 bunu faydalı olarak değerlendirdi - Bu konuyu değerlendir

Considerations for Migrating to Windows Azure Caching

Authors: Jaime Alva Bravo, Sreedhar Pelluru
Contributors: Jason Roth

Windows Azure Caching service provides a cache-aside distributed, in-memory, application cache service for Windows Azure applications. It increases application performance by temporarily storing information from other backend sources in RAM memory. Applications can access data from in-memory cache much quicker than from backend stores such as Windows Azure SQL Database instances. This also reduces the costs associated with database transactions in the cloud. See Windows Azure Caching service documentation for more details.

Migration Considerations

If your on-premises application uses Windows Server AppFabric Caching, migrating to Windows Azure Caching is straight forward. If it does not use Windows Server AppFabric Caching, refactor your application to use Windows Azure Caching. The following table describes types of data that are most suitable to be stored in Windows Azure cache.

Data Type	Description
Reference	Reference data is a version of source data that changes infrequently or not at all. It is either a direct copy of the original data or it is aggregated and transformed from multiple data sources. Reference data is refreshed periodically, usually at configured intervals or when data changes. Because reference data does not change frequently, it is an ideal candidate for Caching. Instead of using computing resources to re-aggregate and transform reference data each time it is requested, reference data can be saved to the cache and reused for subsequent requests. Caching reference data across multiple applications or users in this way can help increase application scale and performance. Examples of reference data include flight schedules and catalogs. For example, consider a catalog application that aggregates product information across multiple applications and data sources. The most common operation on the catalog data is a shared read: browsing. A catalog browse operation iterates over lots of product data, filters it, personalizes it, and presents the selected data to several users.
Activity	Activity data is generated as part of a business transaction by an executing activity. The data originates as part of the business transaction. Then, at the close of the business transaction, the data is retired to the data source as historical or log information. Examples of activity data include purchase orders, application session states, or an online shopping cart. Consider the shopping cart data in an online buying application. Each shopping cart is exclusive per each online buying session and is its own individual data collection. During the buying session, the shopping cart is cached and updated with selected products. The shopping cart is visible and available only to the buying transaction. Upon checkout, as soon as the payment is applied, the shopping cart is retired from the cache to a data source application for additional processing. After the data source application processes the business transaction, the shopping cart information is logged for auditing and historical purposes. While the buying session is active, the shopping cart is accessed both for read and write activities but is not shared. The exclusive access and close proximity to the activity data makes it appropriate for distributed Caching.
Resource	Both reference (shared read) and activity (exclusive write) data are ideal for caching. But not all application data falls into these two categories. There is also data that is shared, concurrently read and written into, and accessed by lots of transactions. Such data is known as resource data. Examples of resource data include user accounts and auction items. For example, consider an auction item. The auction item includes the description of the item and the current bidding information (such as the current bid, and who bid). The bidding information is volatile, unique to each bid, and concurrently accessed by many users for read and write operations. As this sample shows, resource data is a candidate for Caching because the business logic can be cached close to the resource data.

Data Type

Description

Reference

Reference data is a version of source data that changes infrequently or not at all. It is either a direct copy of the original data or it is aggregated and transformed from multiple data sources. Reference data is refreshed periodically, usually at configured intervals or when data changes.

Because reference data does not change frequently, it is an ideal candidate for Caching. Instead of using computing resources to re-aggregate and transform reference data each time it is requested, reference data can be saved to the cache and reused for subsequent requests. Caching reference data across multiple applications or users in this way can help increase application scale and performance.

Examples of reference data include flight schedules and catalogs. For example, consider a catalog application that aggregates product information across multiple applications and data sources. The most common operation on the catalog data is a shared read: browsing. A catalog browse operation iterates over lots of product data, filters it, personalizes it, and presents the selected data to several users.

Activity

Activity data is generated as part of a business transaction by an executing activity. The data originates as part of the business transaction. Then, at the close of the business transaction, the data is retired to the data source as historical or log information.

Examples of activity data include purchase orders, application session states, or an online shopping cart. Consider the shopping cart data in an online buying application. Each shopping cart is exclusive per each online buying session and is its own individual data collection. During the buying session, the shopping cart is cached and updated with selected products. The shopping cart is visible and available only to the buying transaction. Upon checkout, as soon as the payment is applied, the shopping cart is retired from the cache to a data source application for additional processing. After the data source application processes the business transaction, the shopping cart information is logged for auditing and historical purposes.

While the buying session is active, the shopping cart is accessed both for read and write activities but is not shared. The exclusive access and close proximity to the activity data makes it appropriate for distributed Caching.

Resource

Both reference (shared read) and activity (exclusive write) data are ideal for caching. But not all application data falls into these two categories. There is also data that is shared, concurrently read and written into, and accessed by lots of transactions. Such data is known as resource data.

Examples of resource data include user accounts and auction items. For example, consider an auction item. The auction item includes the description of the item and the current bidding information (such as the current bid, and who bid). The bidding information is volatile, unique to each bid, and concurrently accessed by many users for read and write operations. As this sample shows, resource data is a candidate for Caching because the business logic can be cached close to the resource data.

If your on-premises application uses Windows Server AppFabric Caching, be aware of some of the differences between Windows Server AppFabric Caching and Windows Azure Caching and accommodate for features that your on-premises Caching solution uses but Windows Azure Cache does not support. See Differences between Caching On-Premises and in the Cloud article for more details

The most important difference between Windows Server AppFabric Caching and Azure Caching is that Windows Azure Caching offers you a distributed in-memory cache solution without requiring you to set up any infrastructure or administration, other than provisioning your cache. With the on-premises solution of Windows Server AppFabric, you have to obtain machines, install Windows Server on each machine, and then create and manage the cache cluster across those machines. In the cloud solution, Windows Azure handles most of the administration tasks for using Caching.

Windows Azure Caching is deployed as a service alongside other application code in your Web or Worker roles or you can choose to have worker roles specifically dedicated to the cache. The cache is distributed across the compute resources you select and integrated into the Windows Azure SDK. Once deployed in Web or Worker roles, there is no additional charge for caching above and beyond normal Cloud Services rates which vary by the type of role and the role size.

Windows Azure Caching

Windows Azure Caching provides the ability to host Caching within your Azure roles. In this model, the cache is part of your cloud service. One role within the cloud service is selected to host Caching. The running instances of that role join memory resources to form a cache cluster. This private cache cluster is available only to the roles within the same deployment. There are two main deployment topologies for this type of Caching: dedicated and co-located.

In the dedicated topology, you define a role that is dedicated to Caching. This means that all of the role's available memory is used for the Caching and operating overhead. In the co-located topology, the role that hosts Caching also hosts other web role or worker role functionality. The memory and resources of the role are shared between caching and non-caching application code and services. In both cases, you only pay for the Compute services required for the running role instances. For more information, see Windows Azure Caching Overview.

Following are some benefits of Caching:

You pay only for the Compute instances that host the cache. There is no separate cost associated with the cache.
Caching supports advanced features, such as regions, notifications, and multiple named caches.
Caching on roles should have improved performance because the cache cluster is dedicated to the cloud service and is located closer to role instances.
Caching allows you to maintain high availability for cached objects by using the High Availability feature. Cached objects are replicated within the same cloud service deployment for resiliency against hardware failure. Backup copies are also placed across different fault domains to increase availability. See High Availability (Windows Azure Caching) for more details.
Windows Azure Caching supports the Memcache protocol to enable customers with existing Memcache implementations to easily migrate to Windows Azure. If an application already uses Memcache, there is no necessity to replace this code with new code. See Memcached Wrapper for Windows Azure Caching for more details.

It is possible to migrate from Windows Server AppFabric Caching to Azure Caching with minimal code changes. See Migrate from AppFabric Caching to Windows Azure Caching for details.

Topluluk İçeriği

Ekle

Considerations for Migrating to Windows Azure Caching

Migration Considerations

Windows Azure Caching

See Also

Other Resources

Topluluk İçeriği