Eksportuj (0) Drukuj
Rozwiń wszystko
Ta zawartość nie jest dostępna w wymaganym języku. Wersja w języku angielskim znajduje się tutaj.

Migrating Data to Azure Table Storage

Updated: May 6, 2014

Azure Table storage offers a massively scalable non-relational structured storage in the cloud. An Azure table is a collection of entities (rows). An entity can have up to 255 properties (columns) where each property has name, type, and value attributes. Each entity in a table has three reserved properties: PartitionKey, RowKey, and Timestamp. Table storage uses partition key to partition or distribute entities over the Azure Storage nodes. A partition in Table storage contains entities with the same partition key. A row key uniquely identifies an entity within the partition and the timestamp is a read-only system maintained property for tracking changes. Table storage does not require you to define a schema for entities in a table. A table can have entities that contain different set of properties. For a detailed overview of Table storage, see Azure Portal.

Table Storage

Authors: Sreedhar Pelluru
Contributors: James Podgorski
Reviewers: Valery Mizonov, Kun Cheng, Steve Howard

Migration Considerations

Consider various factors such as the following ones when migrating your applications to use the Azure Table storage.

  • What type of data can be stored in Table storage?

  • How can the data stored in Table storage be accessed from the migrated application?

  • Does the storage support high-availability, scalability, disaster recovery, and security requirements of the migrated application?

  • How do you upload any existing data to Table storage?

Data Considerations

The first step to perform in the migration process is to determine whether Table storage is a good fit for storing the data that your on-premises application uses. Table storage is optimized for storing data that meets the following requirements.

  • The data is structured and typically stored in tabular format.

  • The data is non-relational. The data you are planning to store in one table is not related to data in other tables. Azure Table storage does not support storing relational data by using mechanisms such as referential integrity in databases. Table storage is optimized for storing non-relational structured data.

  • The data does not require server-side processing. Ensure that your data does not require any server-side processing such as joins, stored procedures, and triggers, which a relational database supports. Table storage does not support server-side processing. It does support basic operations such as Insert, Update, Delete, and Select with simple server-side filtering by PartitionKey and RowKey.

  • The data is primarily indexed and searched by using a lookup value or key. The partition key identifies the partition and the row key identifies a unique row within the partition. The partition key and row key together uniquely identify an entity in the table. After you determine Table storage is a good fit to store the data, evaluate what part of the data you can use as a partition key for the table. See Designing a Scalable Partitioning Strategy for Azure Table storage.

  • The data can be stored by using the data types that the Table storage supports. The supported data types for Table storage are: String, Byte Array, GUID, DateTime, Int32, Int64, Double, and Boolean.

  • The data does not require cross-partition transactions. Table storage does not support distributed or cross-partition transactions; it supports only entity-group transactions. Therefore, choosing the right partition key and storing related data in the same partition is important. For example, you may want to store information about a customer and the orders he places in the same partition so that you can update both customer information and order information within a single transaction to achieve data integrity.

  • (Optional) The data size can grow to gigabytes/terabytes. The maximum size of an Azure table is 200 TB, which is actually the size limit for the Azure Storage (includes tables, blobs, and queues).

  • (Optional) The data stored in one row can be different in structure and type from the data stored in another row of the table. Azure Table storage does not require you to define a fixed schema for the rows or entities. Hence, you can store different types of data in the same table. For example, you can store order information in one row and customer information in another row of the same table.

Table storage vs. Azure SQL Database

Table storage stores structured data as Azure SQL Database does. Therefore, when migrating applications from on-premises to the Azure Platform, a common question that arises is whether to use Table storage or SQL Database. The main difference between SQL Database and Table storage is: SQL Database is a relational database management system that provides data-processing capabilities through joins, views, and stored procedures, whereas, Azure Table storage is a non-relational data store and does not provide data processing capabilities that the SQL Database supports.

If your application stores and retrieves large data sets but does not require data processing, then the Azure Table is a better choice and if your application requires data processing over large data sets and is relational in nature, then SQL Database is a better choice. There are several other factors you need to consider before deciding between SQL Database and Azure Table storage though. See the comparison table in Overview of Data Management Services in Azure topic for more detailed comparison.

Data Access Considerations

Client applications written in any programming language and running on any operating system can access the Azure Table storage using HTTP(S) REST API. Table storage can also be accessed by using client libraries that target specific operating systems and programming languages. Libraries exist for .NET, Node.js, Java, and PHP, and are available for download on Azure Developer Center. For example, the .NET Storage Client Library provides strongly typed .NET wrappers around the REST API to make the development easier for .NET developers.

If your existing on-premises application uses structured but non-relational data and you consider using the Table storage to store that data on the Azure Platform, you will be expected to rewrite the part of the code that accesses the data by using the Storage Client Library.

Benefits of Table storage

When you store your data in the Azure Table storage, you automatically get several important benefits such as the following ones:

  • Scalability: 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. For more information, read the “Azure Storage Scalability and Performance Targets” article.

  • High Availability/Fault tolerance: Tables stored on Azure are stored in three replicated copies in the same data center for resiliency against hardware failures. Regardless of which storage service you use, your data is replicated across different fault domains to increase availability.

  • Disaster recovery: Azure 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: Every request you make to the Azure storage services must be authenticated unless it is an anonymous request against a public container resource. See “Manage Access to Azure Storage Resources” for more details.

  • Data access from any client, anywhere: Table storage can be accessed using the REST API via HTTP(S). Therefore, any client application on any operating system can access Table storage using REST.

Uploading Existing Data to Azure Table storage

After you redesign your application to take advantage of the massively scalable non-relational Table storage, you might need to transfer existing data from a File System or a SQL Server database to the Table storage. To do so, you can either write code by yourself using the HTTP(S) REST API, or the .NET Client Library for Table storage, or use tools such as the following ones:

See Also

Zawartość społeczności

© 2014 Microsoft