AZURE TABLE STORAGE Ivan BREAKDOWN What is Table

AZURE TABLE STORAGE Ivan

BREAKDOWN What is Table Storage? Why use Table Storage? The Basics Designing a Table Accessing tables with. NET Example

WHAT IS TABLE STORAGE Ø No. SQL Data. Store service for large amounts of unstructured data When would I use it? Ø Datasets that don’t require complex joins, keys or storeprocs Ø Datasets that can be denormalized for fast access Ø Datasets that need to scale big as demand increases

WHY USE TABLE STORAGE? Ø Cheap. From US$0. 12 per GB to as little as US$0. 045 c per GB (R 1. 42 to R 0. 54) Price is based on redundancy and total size. Ø Fast. (With a little forethought). Ø LINQ is supported (somewhat).

THE BASICS Ø Entries into the table have two keys: PARTITION and ROW (and also contain a TIMESTAMP) Ø Row Key is unique, Partition Key groups rows. Ø Query operations are limited. Ø Supported: From, Where, Take (<1000). Ø Not supported: Group. By, Order. By, Math functions, Distinct, Join, Count, Contains… and many more. Ø Very fast to get by Row and Partition key, moderately slow otherwise.

DESIGNING A PARTITION/ROW SCHEMA Be aware of LIMITS so you don’t lose data! Ø Account limit – 20 000 entities/second Ø Partition limit – 2 000 entities/second Read Queries that do a “table scan” count each entity towards this limit whether or not it is returned. Aim to never have to do a table scan. Ø Don’t use Table Storage if you will need to make complex queries. Ø Ideally, only ever query on Partition Key or Row Key (or groups thereof) Ø Create your own indexes by duplicating data.

HOW AZURE STRUCTURES YOUR DATA Partitions served from one partition server Partition server has a rate limit, and speed will be throttled down when it becomes “hot”. For small partitions, sequential partition keys may be served from the same server, allowing faster range lookups (e. g. 0001, 0002, 0003, …).

RULE If the entity has one key property, use it as the partition key. If the entity has two key properties, use one as partition, one as row. If there are more potentially dominant queries, duplicate the data to provide an ad-hoc index.

INSERTING INTO TABLES WITH. NET Cloud. Storage. Account storage. Account = Cloud. Storage. Account. Parse(conn. String); Cloud. Table. Client cloud. Table. Client = storage. Account. Create. Cloud. Table. Client(); Cloud. Table cloud. Table = cloud. Table. Client. Get. Table. Reference(table. Name); Elastic. Table. Entity elastic. Entity = Elastic. Table. Entity. From(data); Table. Operation table. Operation. Context = Table. Operation. Insert. Or. Merge(elastic. Entity); cloud. Table. Execute(table. Operation. Context);

EXAMPLE – LOGGING ACCOUNTS – environments TABLES – products & index tables PARTITION – index value ROW – reverse timestamp+GUID

REFERENCES & QUESTIONS https: //msdn. microsoft. com/en-us/library/azure/hh 508997. aspx https: //msdn. microsoft. com/en-us/library/azure/dd 135725. aspx http: //stackoverflow. com/questions/15809078/design-of-partitioning-for-azure -table-storage http: //www. troyhunt. com/2013/12/working-with-154 -million-records-on. html