NoSQL (nonrelational) storage

The NoSQL arena has many options, ranging from simple object storage to complex document and
graph-based data stores.

Azure Storage has several component features that provide the flexibility to store and retrieve large
amounts of unstructured data such as documents and media files with Azure Blobs, structured
NoSQL-based data with Azure Tables, reliable messages with Azure Queues, and Server Message
Block (SMB) protocol file shares with Azure File Service. The following is a brief look at how to
differentiate each of these component features:

 Azure Blob Storage is designed to store data in essentially any format. Blobs (which stands for
“Binary Large Object” and is somewhat of a misnomer, given that text is equally at home in a
blob) are analogous to files on a server or client machine. Blobs can hold text, images, media,
comma-separated-value (CSV) files, databases—virtually anything. Like Azure Tables (described next), blobs are triple redundant, meaning their contents are always replicated to two other physical stores in Azure, thus minimizing the possibility of data loss in the event of hardware failure.

 Azure Tables provides a simple but performant key/value store. Azure Tables lets an application
store properties of various types, such as strings, integers, and dates. An application can then
retrieve a group of properties by providing a unique key for that group. Although complex
operations such as joins aren't supported, tables offer fast access to typed data. They're also very
scalable, with a single table able to hold as much as a terabyte of data. And, matching their
simplicity, tables are usually less expensive to use than relational storage. You should consider Azure Tables if you need to create an Azure application that needs fast access to typed data, maybe lots of it, but does not need to perform complex SQL queries on this data. For example, imagine that you're creating a consumer application that needs to store customer profile information for each user, and you expect to have a large number of users, but you won't do much with this data beyond storing it and retrieving it in simple ways. This is the kind of scenario for which Azure Tables makes sense.

 Azure Queues is a service for storing large numbers of messages that users can access from anywhere in the world via authenticated calls by using HTTP or HTTPS. A single queue message
can be up to 64 KB in size, and a queue can contain millions of messages, up to the total capacity
limit of a storage account. Common uses for Queues storage include creating a backlog of work
to process asynchronously and passing messages from an Azure Web role to an Azure Worker
role.

 Azure Files provides file storage accessible through the SMB protocol using a \\Server\share format. Applications running in Azure can use it to share files between VMs using familiar file
system APIs like ReadFile and WriteFile. In addition, the files can also be accessed at the same
time via a REST interface, which allows you to access the shares from on-premises when you also
set up a virtual network. Azure Files is built on top of the Blob service, so it inherits the same
availability, durability, scalability, and geo-redundancy that’s built in to Storage.

There are several common scenarios for which Azure Files would be a good storage solution:

 Migrating existing apps to the cloud It’s easier to migrate on-premises applications to the cloud that use file shares to share data between parts of the application. Each VM connects to the file share, and then it can read and write files just like it would against an on-premises file share.

 Shared application settings A common pattern for distributed applications is to have configuration files in a centralized location where they can be accessed from many different VMs. You can store these configuration files in an Azure File share where they can be read by all application instances. You can also manage the settings via the REST interface, which allows worldwide access to the configuration files.

 Diagnostic Share You can save and share diagnostic files such as logs, metrics, and crash dumps. Having these files available through both the SMB and REST interface makes it possible for applications to use a variety of analysis tools for processing and analyzing the diagnostic data.

 Dev/Test/Debug When developers or administrators are working on VMs in the cloud, they often need a set of tools or utilities. Installing and distributing these utilities on each VM is time consuming. With Azure Files, developers or administrators can store their favorite tools on a file share and connect to them from any VM. Azure DocumentDB is a NoSQL document database service designed from the ground up to natively support JavaScript Object Notation (JSON) directly inside the database engine. It’s the right solution for applications that run in the cloud when predictable throughput, low latency, and flexible query are crucial.

A common problem for developers is that application schemas constantly evolve. DocumentDB automatically indexes all JSON documents; adds them to the database, including all fields; and lets
you use familiar SQL syntax to query them without specifying schema or secondary indices up front.

Other data options include a wide range of relational and nonrelational applications from other vendors, including IBM and Oracle, as well as popular open-source packages such as MongoDB and others. The Azure Marketplace provides a convenient way for architects and applications developers to find and try out different options.

Source of Information : Microsoft Enterprise Cloud Strategy