Join Chander Dhall for an in-depth discussion in this video DocumentDB overview, part of NoSQL Development with DocumentDB in Azure.
- [Instructor] According to the official documentation, DocumentDB is a fully managed, noSQL database service built for fast and predictable performance. High available, elastic scaling, global distribution and ease of development. As a schema-free noSQL database, DocumentDB provides rich and familiar SQL query capabilities. Yes, you heard me right, SQL query capabilities. This is the best part. DocumentDB guarantees that 99% of your reads are served under 10 milliseconds and 99% of your writes are served under 15 milliseconds.
So imagine a latency of just 10-15 milliseconds and a guaranteed associated with it. That makes it the best managed, noSQL database service out there. And this also makes it a great fit for web, mobile, gaming and even Internet of Things or IOT, and many other applications that need seamless scale and global replication. It's easily scalable, up or down, to meet your application needs. Data is stored on solid-state drives.
It has the ability to store heterogeneous JSON documents and query through familiar SQL-like syntax. If you ever did link in .NET, it also uses a very SQL-like syntax. It's really for a lot of the DBAs who have their existing SQLs killed to feel comfortable querying a noSQL database. It also utilizes highly concurrent, lock-free, log-structured indexing technology which provides automatic indexing of all document content.
Tunable consistency levels. It provides four well-defined consistency levels, which we're going to discuss in detail a little later. There's strong, bounded staleness, eventual and session consistency. And again, this is fully managed. It removes the need for you to have your own team to manage this database. Microsoft Azure makes this a fully managed service. You do not need to manage any of the virtual machines. You do not need to deploy or configure any software, whatsoever, and you can manage the scaling programmatically.
And it also comes with an http RESTful interface. So you can use this with any language that has the ability to make REST calls. Automatic indexing. The default settings automatically index all the documents in the database. Now, of course, it is an operation on top of a regular operation. So you also have the ability to remove it. If you do not want automatic indexing, you can actually make sure that that doesn't happen. If the user does not want to index everything, he can opt out of this.
JSON data is managed in its well-defined database resources. These resources are replicated for high availability and are addressable by their logical URI, provides simple http based RESTful programming model for all resources. Database account is a unique namespace, providing the user access to Azure DocumentDB. Note, in order to create a database account, you must have an Azure subscription. All resources will be modeled and stored as JSON documents, which will be managed as items, which are really JSON documents containing metadata as feeds and feeds are collections of items.
Sets of items will be contained in their respective feeds. Here's a really good resource called Query Playground. You can go to DocumentDB.com/sql/demo and you have something called query on the left-hand side and then results pop up on the right-hand side. And in this case, all we're doing is selecting ID description, tags, and food group from food, where food.foodGroup equals snacks and food.id equals to 19015.
So, if I were to come to the website and I run this, I can see the results are right here. I could change the query to something else. As you can see in this case, I just asked for foodGroup is snacks and ID not equals to empty string. And I was able to get some value back. Now that I know one of the IDs in the database, I can do something like this, and run it. I'm going to get the same exact result back and now you can see I looked for the entire object and I'm getting a lot of data back in this case.
So really what it's doing is looking for foodGroup as snacks and ID to be 8510. And you can see I have the entire object, and this has a lot of things, including ID, description, tags, version, and nutrients, which is really an array of a lot of objects. So, this is a cool playground to see a lot of things. Now you can see, there are certain other kind of properties. And these are properties that DocumentDB adds on its own. So for example, self.
And self is really a link to this particular collection. And then you have etag for your versioning. And then if you had any attachments, they would be in the attachments link. And the link would be attachment slash whatever is the name of the attachment in that case.
- Back-end scaling fundamentals
- Fallacies of distributed computing
- Consistency models
- Data migration
- DocumentDB with .NET and Node.js