Why to use NoSQL and why do we use DocumentDB

  • Article

Microsoft's planet-scale NoSQL database as a service, Now NoSQL has been a recent phenomenon. Let's have a look on NoSQL before we get started with DocumentDB. It's a recent phenomenon in geological terms but it's quite a mature space and it's growing very fast. NoSQL databases are used in a variety of use cases. All of these use cases share the same traits, at least one or more. For one, we tend to work with data that either has no schema or the schema changes fast. There is usually lots of data, terabytes and petabytes of data in our SQL databases and DocumentDB specifically is great at that. And many of these use cases, especially telemetry, telematics, IoT have high expectations for ingestion rate of the data, millions of requests per second. And at the same time, very low latency for reading data, and writing the data while doing that ingestion.

To get started with DocumentDB, you should go to Azure portal. it's easy to create DocumentDB by going through New > Data + Storage > DocumentDB our NoSQL managed Database as a service. We just need to provide a name and a place in the world where we want to run it, anywhere in across Azure regions. And once we have the DocumentDB account created, we can work with it in any of the languages including .NET, Java, Note, Bison.

Once you're connected to DocumentDB, you can start storing documents, and we store documents in document collections.
And you can create collections using APIs or through the portal. Once you have a collection, you can start storing documents of different shapes and kinds, type and untype. Different types of documents in the same collection. Collections are heterogeneous. Once you have your data stored in a collection you can query it using familiar syntax, SQL, JavaScript, Mongo APIs and etc.

The geo distribution offers other interesting capabilities and side effects, like you can get this very high available solution built this way. By either by provisioning your data in multiple regions and
replicating you can set up the system to automatically failover to another region should an accident occur. Or manually failover if you just want to move data transparently from one region to another with no down time. It's a great credibility.

It allows you to have very interesting scenarios. You can failover programmatically, you can over looks through those geographically as people will wake up in different parts of the world, you can always have your right region in the part of the world where people are and keep failing over your write region from one part of the vault to another while keeping the data available throughout the world. You can replicate your data across all Azure regions and we will still guarantee the same single-digit millisecond latency in each of these regions and the same throughput that we just described.

Another side of DocumentDB is the friendliness, It's the friendliest database out there, it can store documents, it can store key values, it can support different modes of your schema. It offers you familiar syntax, SQL or if you like JavaScript more, for JavaScript you can talk to DocumentDB from any of the .NET, Java, Node, Python. And if you come from MongoDB world, if you are a MangoDB developer you can talk to DocumentDB using MangoDB APIs. Azure supports MangoDB APIs at the particle level.