Eksporter (0) Skriv ut
Vis alt
EN
Dette innholdet er ikke tilgjengelig på ditt språk, men her er den engelske versjonen.

Migrating Data to Tables and Blobs in Azure

Updated: December 6, 2013

This section provides guidance on migrating your on-premises applications to use the following data management services: Azure Table service and Azure Blob service. For an overview of these data management services, see Overview of Data Management Services in Azure.

The following table compares Table Storage, Blob Storage, and Local Storage (not considered a Data Management Service) to help you decide which storage to use for your scenario.

 

Comparison Criteria Local Storage Table storage Blob storage

Durability

Non-durable.

It can be persisted across recycles of the same application instance, but if the instance fails over to different hardware, the data does not move with the instance.

Durable.

Table storage provides scalable and durable storage for structured data.

Durable.

Blob storage provides scalable and durable storage for unstructured objects such as images, audio and video files.

Data Access

File System API.

You can access local storage by using file system APIs. Therefore, you may be able to run the application with minimal code changes on the Azure Platform.

REST API or Storage Client Library

Table storage can be accessed from anywhere and any client by using the REST API. You can also access Table storage using Storage Client Libraries that provide language specific (such as .NET, Java, Node.js and PHP) wrappers around the REST API.

REST API or Storage Client Library

Blob storage can be accessed from anywhere and any client by using the REST API. You can also access Blob storage using Storage Client Libraries that provide language specific (such as .NET, Java, Node.js, and PHP) wrappers around the REST API.

Concurrency

No.

Local Storage is only accessible from one application instance. It is not shared with other instances.

Yes.

Table storage is shared by any applications that can use REST API to access the storage. Concurrent access to Table storage is supported through ETags.

Yes.

Blob storage is shared by any applications that can use REST API to access the storage. Concurrent access to Blob storage is supported through ETags.

Pricing

Azure Compute account is required.

Local Storage is Included in the price of the Azure Compute account, and limited according to the size of the compute instance. No additional storage account is required.

Table storage requires you to have an Azure Storage Account.

Blob storage requires you to have an Azure Storage Account.

Latency
(access from an Azure Compute instance)

Local storage is on the VM itself, so accessing it is fast compared with accessing an Azure drive.

Slower compared to Local Storage since the data is not stored on the VM itself. Latency increases if the table storage is located in a different data center from the role instance or VM accessing it.

Slower compared to Local Storage since the data is not stored on the VM itself. Latency increases if the BLOB storage is in a different data center from the role instances, VMs, or machines that access the storage.

Scalability

No

Only one application instance can access the local storage. Hence, it does not provide any scalability.

Yes.

Azure Storage System automatically distributes partitions across all the storage nodes based on the usage patterns of the partitions. For example, if there is high traffic to some of your partitions, the system automatically spreads them to separate storage nodes so that the traffic load is spread across many servers.

Yes.

Azure Blob storage supports a massively scalable blob distribution system via the Azure CDN, where hot blobs are served from many servers to scale out and meet the traffic needs of your application. Furthermore, the system is highly available and durable.

High availability/Fault tolerance

No

Yes.

Blobs, tables, and queues stored on Azure are replicated to three locations within the same data center for resiliency against hardware failures. Additionally, your data is replicated across different fault domains to increase availability as with all Azure storage services.

Yes.

Blobs, tables, and queues stored on Azure are replicated to three locations within the same data center for resiliency against hardware failures. Additionally, your data is replicated across different fault domains to increase availability as with all Azure storage services.

Disaster recovery

No

Yes.

Azure blobs and tables are also replicated between two geographically separated data centers on the same continent, to provide additional data durability in the case of a major disaster.

Yes.

Azure blobs and tables are also replicated between two geographically separated data centers on the same continent, to provide additional data durability in the case of a major disaster.

Security

Can only be accessed from the virtual machine on which it exists.

Every request you make to the Azure storage services must be authenticated, unless it is an anonymous request against a public container resource. See Authenticating Access to Your Storage Account for more details.

Every request you make to the Azure storage services must be authenticated, unless it is an anonymous request against a public container resource. See Authenticating Access to Your Storage Account for more details.

Some of the scenarios where you can use data management services of Azure are:

  • Use the service to provide another disaster recovery (DR) location for on-premises data.

  • Share portions of on-premises data with partners without changing on-premises infrastructure.

  • Move data closer to compute nodes in the cloud.

  • Handle peak loads for data access that is known in advance by migrating data to cloud, scaling it out and then letting clients access it.

Authors: Sreedhar Pelluru
Contributors: Rama Ramani

In This Section

Fellesskapsinnhold

Legg til
Vis:
© 2014 Microsoft