Getting the Most from DocumentDB
It's been common, if inconsistently applied, knowledge for many years that relational databases are a less-than-ideal fit for some types of software problems. Indeed, entire categories of software development tooling, such as object-relational mappers (ORMs), exists to bridge the gap between highly normalized relational data and in-memory, object-oriented representations. In practice, ORMs can create as much complexity as they alleviate, so developers began looking at the relational database itself as ripe for potential disruption.
Thus came the rise of NoSQL and databases that eschew the traditional rows/columns/tables/foreign keys metaphor for other choices like JSON document stores, graph databases that represent data and relationships as nodes with connecting edges, key/value stores that act as a glorified hashtable, and others. The wide range of options meant you could choose the right tool for your particular needs, instead of trying to squeeze a relational database square peg into your application's round hole. Solutions like MongoDB, Cassandra, Redis, and Neo4j rose to prominence and became de facto industry standards for developers interested in leveraging the power and flexibility NoSQL.
While NoSQL was a boon to software developer productivity, the initial product offerings did little to alleviate the administrative burden of managing your database. Server provisioning, backups, data security at-rest and in-transit... all these challenges (and many more) remained as developers adopted NoSQL in greater numbers. Fortunately for them and all of us, the rise of the cloud and managed database service offerings like Azure DocumentDB brought us the best of both worlds: fast, flexible, infinitely-scalable NoSQL with most of the administrative headaches assumed by a dedicated team of experts from Microsoft. You focus on your data and your application, and rely on a 99.99% SLA for the rest!
In this "Introduction to Azure DocumentDB" course, you’ll learn how to use Azure DocumentDB (DocDB) in your applications. You'll create DocDB accounts, databases, and collections. You'll perform ad-hoc and application-based queries, and see how features like stored procedures and MongoDB protocol support can help you. You'll also learn about ideal DocDB use cases and the pricing model. By the end of this course, you’ll have a solid foundation to continue exploring NoSQL and DocumentDB.
An Introduction to Azure DocumentDB: What You'll Learn
|Lecture||What you'll learn|
|Intro||What to expect from this course|
|DocumentDB Overview||A high-level overview of the DocumentDB feature set|
|Overview of Managing DocumentDB||A discussion of DocumentDB features for managing resources, data, scalability, configuration, and so on|
|Creating an Account||Creating a top-level DocDB account in the Azure portal|
|Creating a Collection||Creating and configuring a DocDB collection in the Azure portal|
|Importing Data||Discussion and demonstration of moving data into a DocDB collection|
|Overview of Developing with DocumentDB||A discussion of DocumentDB features from a development point of view|
|SQL Queries||How to author queries in the Azure portal|
|Programming with DocumentDB||Reading and writing data in code, using the .NET SDK|
|Stored Procedures||Authoring DocDB stored procedures and executing them using the DocDB REST API|
|MongoDB Protocol Support||Configuring and using DocDB's MongoDB protocol support|
|Use Cases||A brief discussion of scenarios well-suited for DocDB use|
|Pricing||A review of the DocDB pricing model, and discussion of cost estimation and Total Cost of Ownership|
|Ecosystem Integration||A short review of DocDB integration with other Azure services|
|Summary||Course wrap up|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Let's switch gears and see DocumentDB in action. We'll begin with creating a top level DocDB account in the Azure portal. To follow along with this and subsequent demos, you'll need to log in to an active Azure subscription at portal.azure.com.
Okay, welcome back. So let's switch gears for a moment and take a look at the Azure portal and see what it looks like to create a DocumentDB account. To do that, we'll start at the upper left-hand side and click on New and we could navigate through the menu, but the easiest thing to do is simply to type DocumentDB in the search box which will give us a nice list. Click on DocumentDB and then Create. So we're prompted to first provide a name for our DocumentDB account. This name needs to be global and unique across Azure. This is a publicly addressable name so I'll give it a name like ca test2. Yeah, there it is, okay. So we have the choice of DocumentDB API support or MongoDB. We'll demonstrate MongoDB support a bit later in a different demo. For now, I'm going to stick with the standard DocumentDB support. I'll use an existing resource group. A resource group is just a logical container for any Azure resource so I'll use an existing one and I'm going to pick the location to be the Eastern United States since that's where I'm currently located. So I'm going to click Create here and this will take a few moments, but Azure will spin up an account for me so that I can start using it, adding collections and data.
Okay, so through the magic of video splicing, we've transported ourselves forward in time and our new DocDB account has been created so the easiest way to find that will be to type up at the top ca test2, that's it. Not cat test2, there we are. All right, ca test2, we'll pull that up and yes, we get the top level view of our DocDB account. So a couple of things to note in here. Of course, we don't have any data or collections or databases, that sort of thing, yet in our account. An account again recall is just a top level logical container for data in DocDB, but it is a nice high-level place where you can set some overarching properties and some configuration that applies within the scope of that entire account. So just real briefly on that, a couple of things, the first thing you can do is you can if you click on the replicate data globally tab, this is the place where you can configure geo-replication of your DocDB data across multiple regions. Right now you can see highlighted I have just the East US region where my data exists, but if I wanted to I could click on some of these others and replicate my data in those locations as well and again, this is all I have to do to establish this low latency geo-replication using DocDB. It's very, very handy. I don't have to do anything else after I configure this and click save. Of course, I do have to pay for all of those other locations where my data will be copied and where it will exist, but assuming that that's something that I need to do for my application to support the behavior of my application or if I wanna support some disaster recovery kind of scenarios, then it's very, very easy for me to configure that within DocDB.
Recall also that we've talked a little bit about the configurable consistency settings in DocDB. Under the default consistency tab here, I can specify the account-wide default consistency level for all requests that occur within the scope of this account. The default is session consistency, but there are also available strong bounded staleness and eventual consistency models. And again, we discussed those in other parts of the course so go back to those if you need a refresher or certainly there are some links to some additional information on some of those things from inside the portal here as well. A couple other quick things. If you click on the firewall tab, you have the ability within DocDB within an account in DocDB to enable IP access control and this is exactly what it sounds like. It allows you to specify a list of IP addresses which are able to connect and interact with your DocDB data. This is an optional feature. You certainly don't have to use it, but it's an additional security safeguard if you choose to use it. Finally, one other thing to make note of. The access keys that are used to configure connection strings to programmatically access data in DocDB, those are accessed under this keys tab and there are two sets. There are read and write keys and then there are also read-only keys and so you have the ability for example if you have an application which needs read-only access to your DocDB data then you can click on these read-only keys and use those keys, provide those keys, to those applications and that will prevent writes from occurring from those locations. You also have the ability to regenerate these keys on demand and as needed from this tab.
About the Author
Josh Lane is a Microsoft Azure MVP and Azure Trainer and Researcher at Cloud Academy. He’s spent almost twenty years architecting and building enterprise software for companies around the world, in industries as diverse as financial services, insurance, energy, education, and telecom. He loves the challenges that come with designing, building, and running software at scale. Away from the keyboard you'll find him crashing his mountain bike, drumming quasi-rythmically, spending time outdoors with his wife and daughters, or drinking good beer with good friends.