WINDOWS AZURE STORAGE SERVICES A brief comparison and overview of storage services offered by Microsoft.

DATA STORAGE  “We need a database therefore we need SQL Server.”

CLOUD = THINKING BUSINESS  Perhaps the most unique aspect to designing and architecting applications for the cloud is that it requires developers to think like businessmen. Each technical choice often has direct costs associated with it when developing for the cloud. The choice in data storage can have a huge impact on the cost of running an application.

AZURE SQL  No physical administration.  Scalability service plans for multiple needs and budgets.  Elasticity.  SQL Data Sync. (Migrations)  Most SQL Server 2014 Transact-SQL statements are fully supported in Microsoft Azure SQL Database.  Datatypes, operators, string, arithmetic, logical, cursor functions, and the other Transact-SQL elements that most applications depend upon.  Partially or unsupported functions are usually related to differences in how SQL Database manages the database (such as file, high availability, and security features) or for special purpose features such as service broker.

AZURE SQL PRO’S  Relational.  Schema.  ACID Transactions.  (Atomicity, Consistency, Isolation, Durability)  Familiarity with Microsoft SQL (SQL Server Management Studio).  Indexing.  Good when your data is holds complex relationships that are important to uphold.

AZURE STORAGE

BLOB STORAGE  Stores file data.  A blob can be any type of text or binary data, such as a document, media file, or application installer.  Good for Big data such as Logs and other large datasets.  Block blobs : Good choice for documents., media, backups.  Page blobs : Optimised for representing IaaS disks and supporting random writes.

QUEUE STORAGE  Provides reliable messaging for workflow processing and for asynchronous communication between components of cloud services.

FILE STORAGE  In Preview.  Offers shared storage for legacy applications.  Many legacy applications rely on file shares, a dependency that has complicated moving these applications to the cloud. File storage offers cloud-based file shares, so that you can migrate legacy applications to Azure quickly and without costly rewrites.

TABLE STORAGE  NoSQL key-attribute data store.  Allows for rapid development and fast access to large quantities of data.  No relationship or linkage between entities.  Schema-less design.  Easy to adapt your application data as the needs of your application evolve.  Low in cost!

TABLE STORAGE  A collection of properties and their values comprise an entity.  Two entities in the same table can contain different collections of properties and types (schema-less).  You can store any number of entities in a table, and a storage account may contain any number of tables (up to the capacity limit of your account).  An entity is analogous to a row and property is analogous to a column.

TABLE STORAGE

TABLE STORAGE: KEYS  PartitionKey and RowKey properties work together as an index for your table.  You must consider how your data will be queried.  PartitionKey is also used for physically partitioning the tables, which provides for load balancing and scalability.  RowKey is used to differentiate between entities with the same PartitionKey.

TABLE STORAGE: KEYS

TABLE STORAGE: PARTITION KEY  PartitionKeys example:  Consider a table that contains information about food and has PartitionKeys that correspond to the food types, such as Vegetable, Fruit and Grain.  In the summer, the rows in the Vegetable partition might be very busy (becoming a so-called “ hot ” partition ).  The service can load balance the Food table by moving the Vegetable partition to a different server to better handle the many requests made to the partition.  If you anticipate more activity on that partition than a single server can handle, you should consider creating more-granular partitions such as Vegetable_Root and Vegetable_Squash. This is because the unit of granularity for load balancing is the PartitionKey.  All the rows with the same PartitionKey value are kept together when load balancing.  You could even design your table so that every single entity in the table has a different partition.  Note the naming.

TABLE STORAGE: PARTITION KEY  PartitionKeys example:  Query a specific vegetable:  Query all vegetables ( prefix search ):  Prefix search can is very usefull in both PartitionKeys and RowKeys.  Naming is important!

TABLE STORAGE: ROW KEY  In combination with PartitionKey it can define uniqueness within a table for each row.  Can be used to help with sorting as RowKey acts is part of an index. (Could use combination of values)  If table contains more than one type, RowKey should contain type for better querying.

TABLE STORAGE: EXAMPLE

SELECTING PARTITION KEY 1.First determine the important properties for your table. These are the properties frequently used as query filters. 2.Pick the potential keys from these important properties. 3.It is important to identify the dominant query for your application workload. From your dominant query, pick the properties that are used in the query filters. 4.This is your initial set of key properties. 5.Order the key properties by order of importance in your query. 6.Do the key properties uniquely identify the entity? If not, include a unique identifier in the set of keys. 7.If you have only 1 key property, use it as the PartitionKey. 8.If you have only 2 key properties, use the first as the PartitionKey, and the second as the RowKey. 9.If you have more than 2 key properties, you can try to concatenate them into two groups – the first concatenated group is the PartitionKey, and the second one is the RowKey. With this approach, your application would need to understand that the PartitionKey. (Example: seperaed by ‘_’)

DOCUMENT-DB  Document-orientated, schema-free NoSQL data store.  Fully-managed database-as-a-service.  Still in preview.  Elastic SSD storage.  Stores data as Json.

DOCUMENT-DB

 Database Account:  One or more Capacity Units.  Unique DNS.  Database:  Logical container of users and collections.  Partitioned across collections.  Collection:  Container of Json Document.  Scope for transaction and queries.  Document:  CRUD-able objects within a collection.  No enforced schema or specialised data types.

DOCUMENT-DB  Users:  Logical namespace for scoping permissions.  May represent people OR roles.  Permissions:  Authorization token associated with a user.  Controls access to specific resources.  SPs, Triggers and UDFs:  Application logic to run directly within the transaction of the database.  Written entirely in JavaScript.  Attachments and Media:  Allows storage of binary blobs/media.  May be within DocumentDB or in a remote media store (attachment).

DOCUMENT-DB

 Ad hoc queries with SQL Syntax.  JavaScript execution within database.  Express application logic as stored procedures, triggers, and user defined functions (UDFs) using standard JavaScript.  Tuneable consistency levels.  For queries and read operations, DocumentDB offers four distinct consistency levels: strong, bounded-staleness, session, and eventual. These granular, well-defined consistency levels allow you to make sound trade-offs between consistency, availability, and latency.

DOCUMENT-DB  DocumentDB automatically indexes all JSON documents added to the database, then lets you use familiar SQL syntax to query them without specifying schema or secondary indices up front.  Programming against DocumentDB is simple, approachable, open, and does not require custom encodings or extensions to JSON or JavaScript.  OneNote uses DocumentDb, maybe AppCampus will take a bite too?

DOCUMENT-DB: EXAMPLE