Table Storage
- The Azure Table storage service stores large amounts of structured data.
- The service is a NoSQL data store which accepts authenticated calls from inside and outside the Azure cloud.
- Azure tables are ideal for storing structured, non-relational data.
- Common uses of the Table service include:
ü Storing datasets that don't require complex joins, foreign keys, or stored procedures and can be de-normalized for fast access
ü Quickly querying data using a clustered index
ü Accessing data using the OData protocol and LINQ queries with WCF Data Service .NET Libraries
ü We can use the Table service to store and query huge sets of structured, non-relational data, and your tables will scale as demand increases.
Table Service Concepts
The Table service contains the following components
·
- URL format: Code addresses tables in an account using this address format:
- http://<storage account>.table.core.windows.net/<table> We can address Azure tables directly using this address with the OData protocol.
- Storage Account: All access to Azure Storage is done through a storage account.
- Table: A table is a collection of entities. Tables don't enforce a schema on entities, which means a single table can contain entities that have different sets of properties. The number of tables that a storage account can contain is limited only by the storage account capacity limit.
- Entity: An entity is a set of properties, similar to a database row. An entity can be up to 1MB in size.
- Properties: A property is a name-value pair. Each entity can include up to 252 properties to store data. Each entity also has 3 system properties that specify a partition key, a row key, and a timestamp. Entities with the same partition key can be queried more quickly, and inserted/updated in atomic operations. An entity's row key is its unique identifier within a partition.
Benefits of Azure Table Storage
1. Table storage offers highly available, massively scalable storage, so that your application can automatically scale to meet user demand.
2. Table storage is Microsoft’s NoSQL key/attribute store – it has a schema less design, making it different from traditional relational databases.
3. Using Azure Table Storage, Single Primary key lookup is required for semantics feature
4. Automatic mass scale by partition and consistent performance even at large scale.
5. As per user experience direct serialization; no ORM necessary; simplified design model by removing relational model.
6. The Storage table Type variability in a single table.
7. As per cost, No space overhead cost, pay for what is used.
Estimate Capacity in Table Storage
1. How to estimate the amount of storage consumed per Table:
The following is the breakdown:
12 bytes overhead for each Table, which includes the Last Modified Time and some system metadata.
The table name is stored as Unicode so take the number of characters and multiple by 2.
2 How to estimate the amount of storage consumed per entity:
4 bytes + Len (PartitionKey + RowKey) * 2 bytes +
For-Each Property (8 bytes + Len(Property Name) * 2 bytes + Sizeof(.Net Property Type))
For-Each Property (8 bytes + Len(Property Name) * 2 bytes + Sizeof(.Net Property Type))
- 4 bytes overhead for each entity, which includes the Timestamp, along with some system metadata..
- The number of characters in the PartitionKey and RowKey values, which are stored as Unicode (times 2 bytes).
- Then for each property we have an 8 byte overhead, plus the name of the property * 2 bytes, plus the size of the property type as derived from the list below.
Limitation of Table Storage
ü Table names must be unique within an account.
ü Table names may contain only alphanumeric
characters.
ü Table names cannot begin with a numeric
character.
ü Table names are case-insensitive.
ü Table names must be from 3 to 63 characters
long.
ü Some table names are reserved, including
"tables". Attempting to create a table with a reserved table name
returns error code 404 (Bad Request).
Max up to 500 TB size of a single table
Only 1 MB per entity
can store
As per Table Transaction
ü Table single entity AddObject request = 1
transaction
ü
Table Save Changes (without SaveChangesOptions.Batch) with 100
entities = 100 transactions
ü
Table Save Changes (with SaveChangesOptions.Batch) with 100
entities = 1 transaction
ü
Table Query specifying an exact PartitionKey and RowKey match
(getting a single entity) = 1 transaction
ü
Table query doing a single storage request to return 500
entities (with no continuation tokens encountered) = 1 transaction
ü
Table query resulting in 5 requests to table storage (due to 4
continuation tokens) = 5 transactions

Thank you. Well it was a nice to post and very helpful information on Azure Online Training Bangalore
ReplyDelete