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.
Welcome back. Let's take a look at DocumentDB support for the MongoDB application protocol. This allows you to use DocumentDB as a drop-in replacement for MongoDB in MongoDB-enabled applications. Really, all you would need to do is change a connection string in your application and then use DocumentDB instead of MongoDB.
So to do this I'll create a new DocumentDB account, top level account. So I'll click DocDb and New, and then select it in the menu and then click Create. So we're brought to the New Account window where we configure the information for our new account. So I'll just specify something here, mongo-test2. Instead of DocumentDB API support, I'll choose MongoDB. And then, of course, I can pick my standard resource group and location. Now I've already created one of these in my account so I'm actually not going to create another one. Let me click out of here, and instead, I'll navigate over to my existing account. Oh, there we go. Okay. So here's my Mongo-enabled DocumentDB account. The main difference that you're going to see when you start to look around here is that instead of some keys that we had previously we now have configuration settings, connection string information if you will, for connecting to DocumentDB using the standard MongoDB connection string configuration settings. So if you look at this you can see, let me zoom in a bit here, you can see that I have a MongoDB connection string with specific information for connecting to this DocDb account. And there's, you know, there's some additional information like port numbers, et cetera, that you'll need to connect using standard Mongo tools or applications.
So to test this out I'm going to switch into an application called MongoChef and what we're gonna do is we're gonna create a new, from within MongoChef, we're gonna create a new database and a new collection inside of that database and then we'll import some data. And so that should give you some sense of what you can do with DocDb through the lens, if you will, of MongoDB. Essentially, MongoChef uses the MongoDB protocol itself to talk to any Mongo database or any service that understands the Mongo protocol. Typically, of course, that's just going to be a Mongo database, but in DocumentDB's case it also understands, since it also understands MongoDB, then we can talk to it as well, using a Mongo tool.
So from inside MongoChef I'll click Connect and we'll create a new connection. So we'll give it a name and we'll call this, MyDocDBThatLooksLikeMongoDB. All right so the first thing we need is a server name and a port, so if I flip back to my connection settings in DocDB you can see that here's my server name here, so I'll copy and paste that, and I also need a port, and the port, in this case, is 10250. Okay. And we need some authentication information so we need just basic kind of Mongo-enabled authentication so we need a user name and password and then, of course, the database that we're talking to, admin will be fine for that. But we need user name and password, so I'm going to copy those from here. Again, this is all set up for us by DocDb when we designate MongoDB support. Copy and paste my password. Okay. There is my password, okay. The last thing we need to do, because DocDB requires SSL we do need to specify that here in the connection settings for Mongo, and we'll specify that we trust server certificates. So if I test this connection this should be all configured. Yeah, it looks like we're good, everything's okay, everything's green, so it looks like we're good to go, we're talking to our DocDB database. Right, now we'll connect and okay.
Okay, so let's import some data and create a new collection inside our default database. So I'll click on Import. Ah, I need to specify our database first. We'll import into our default database, I wanna use CSV since I have a local CSV file, and again, this is the ZIP code information, postal code information for cities within the United States, this is the CSV file we used in some other demos. So I will specify that and that happens to be in my Downloads folder, so that should be good. Yeah, so this looks like the correct data so I think we're okay here, we have our header information and I think we can keep going. Looks like, I think we probably, we'll just treat this as a string, yeah, we'll just treat everything as a string for now. Okay, so I think we're good, we only have about five or 600 records in this database or in this CSV, so this shouldn't take very long. So let's start our import, we can see that we're currently importing into our database. Okay, so it looks like we're there, we've imported all 599 of our documents, so let's take a look and see what we've got.
We have a new zips collection now, so that's, as expected, if I double-click on that then sure, it looks like we've got lots of documents in there, if I just, if I open one up you can see the information and if I double-click then, oh, I'll right-click and say View JSON, then sure, we can actually see that JSON that corresponds to this particular document. And again, bear in mind that we're using the MongoDB protocol here, we're not talking to DocumentDB using any of its REST APIs or any SDK kind of calls that are specific to DocDB, this is all being done through Mongo, or through the Mongo protocol. So just to prove that data's actually been imported correctly, let's go back to the portal and we'll take a quick look at some of the data that's in here from the portal side. So I'll click on Query Explorer and I'll just say SELECT * FROM c where c.state equals, not sure which states actually get imported, I think Massachusetts is one of the top ones, so let's try that. Yeah, there we are, okay, so we have several documents in here, and you can actually see, those of you who are familiar with Mongo will be familiar with some of the kind of ID specific Mongoisms if you will, some of these properties are specific to a format that MongoDB uses internally to uniquely identify documents. So you can see that that's actually being done as part of that MongoDB protocol support.
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.