MongoDB Applied Design Patterns By Rick Copeland
A couple of weeks ago, I reviewed the book, MongoDB: The Definitive Guide by Kristina Chodorow. As a total novice in the world of NoSQL and MongoDB, I found Kristina Chodorow's book to be a fantastic, robust, in-depth primer on MongoDB and the philosophy of NoSQL databases. Of course, as a beginner, the book left me with a thousand questions. Luckily, MongoDB Applied Design Patterns by Rick Copeland, picks up, in some ways, where Chodorow left off.
| |
|
|
||
| |
 |
|
||
| |
|
|
A NoSQL database isn't simply "another database;" not in the way that Microsoft SQL Server is "another database" when compared to MySQL. A NoSQL database, specifically MongoDB in this case, is a completely different beast. It requires a different application architecture and a necessitates thinking differently in terms of data integrity and data storage.
It's also seemingly not intended to be a small database. Both the books that I have read on MongoDB (as well as several articles) have made it very clear that if you're dealing with NoSQL, you're doing so because scalability, replication, sharding, distributed processing, optimization - these are all part of your long-term plan. If you're dealing with NoSQL, you will be a database administrator (DBA) - at least part of the time.
But, honestly, that future intimidates me. For now, I just want to understand NoSQL and MongoDB at the application level. And, that's exactly what Rick Copeland does: he spends the first half of the book talking about the differences between relational databases and document databases; then, he spends the second half of the book looking at real world problems and how they can be approached using MongoDB.
When building a new application, often one of the first things you'll want to do is to design its data model. In relational databases such as MySQL, this step is formalized in the process of normalization, focused on removing redundancy from a set of tables. MongoDB, unlike relational databases, stores its data in structured documents rather than the fixed tables required in relational databases. For instance, relational tables typically require each row-column intersection to contain a single, scalar value. MongoDB BSON documents allow for more complex structure by supporting arrays of values (where each array itself may be composed of multiple subdocuments) ...
... MongoDB's rich document model leaves open to you: the question of whether you should embed related objects within one another or reference them by ID. Here, you'll learn how to weigh performance, flexibility, and complexity against one another as you make this decision.... Unfortunately for us, it also complicates our schema design process. There is no longer a "garden path" of normalized database design to go down, and the go-to answer when faced with general schema design problems in MongoDB is "it depends."
From the book, you definitely get the sense that NoSQL database design is far more of an art than a science. In fact, it seems that some of the choices Copeland makes in his real-world examples go against some of the advice that Chodorow made in her book. But, Copeland makes a good case for his decisions, often in terms of mimicking Transactional behavior, leveraging atomic actions, accounting for failure, and optimizing for read-performance.
Right now, I'm in full-on absorption mode, trying to soak up and make sense of as much of this NoSQL information as I can. So, sorry if my NoSQL book reviews don't seem so compelling. That said, I really did enjoy Rick Copeland's book; and, I found him answering, or at least addressing, many of the SQL-to-NoSQL transitional questions that I have floating around in my head. Definitely a recommended read, especially if you're familiar with the MongoDB syntax, but are not sure where to go next!
Reader Comments
Hey Ben,
Another little fun exercise is the mongoDB courses offered by the guys over at MongoDB (http://education.mongodb.com). They're 10 weeks long and contain different course material and some homework. Then at the end of it there's a final exam, just to test your knowledge of what you've learned. I did the Python course and the DBA course. It really just gives you a better understanding of mongoDB and how they approach various projects. If you have the time (it did take about 4-5 hours of my time a week per course) but I think it was worth it to get just a quick general overview of everything. Plus the homework forces you to actually review the material and see what you've learned.
@Gareth,
Your timing is spot-on. I was just looking at this over the weekend. They have a Java course starting on the 7th. I honestly don't know much about Java itself; but, I know ColdFusion and can load the Java MongoDB driver. I wonder if they would let me do the course in CF. I watched their video and it sounds like they give you a lot of the files, to let you concentrate on the MongoDB aspects.
In the Python version, how much did they give you? And, was it such a significant amount that you think I could handle it in CF?
@Ben,
I'm not sure that you would actually want to do it in CF for this course as you would be translating a good bit of the language to CF. They give you the code for certain things and then your task is to do something with MongoDB using the language. Like you mention, it's more of a "use this language as a stepping stone to learning how you would use mongoDB with it". So one of the assignments, they gave you a blog written in Python accessed via the Bottle framework and you had to get it to return a blog posting. Nothing too crazy (insert code here type of stuff) and it was only one or two lines of actual code. I'd never used Python before the class, but tinkering around with it a little for the MongoDB course was a nice intro (as it mainly all just worked). I'd actually recommend just taking the class and setting up the environment in whatever language they give you (I saw that they're offering a node.js version now) and give it a whirl. I'm sure you'd do fine in whatever language they offer (it may take you *slightly* longer than others as you'll be playing around with a little syntax) but it's definitely nothing that should cause you hours of grief. And the other side of it is that you're just getting a "I completed this course" certificate at the end of it, so if you stop after 7 weeks, you're not *really* losing anything and gaining the knowledge of whatever you've learned up to that point :) There's also a few weeks of command line work also, so it's definitely not all "programming language" work. Either way, I'd definitely recommend taking the class.
@Gareth,
That's really great insight. Maybe I will do the Node.js one, then. It will give me a little more time to clear my plate. Also, the Java driver requires SO much ceremony you actually start to lose the forest for the trees; I can understand a one-level document but, the second you need to nest a document, Java explodes with verbosity to the point where you can't even really read the code.
I don't know too much with Node.js, but I have done some tinkering.
Thanks for the feedback!
@Ben,
Hey, no problem. I hear you on setting stuff up. Python was extremely simple (and mongoDB come to think of it). Drop it into a folder, boom, off you go :) I'm guessing once you've got node installed it will be just using the npm to manage everything. Anyway, good luck, and enjoy.
@Gareth,
Fingers crossed! Super exciting!
You guys present there are performing an excellent job.http://www.chat-liste.com/erotik-chat.html
The blog is unique that's providing the nice material. Please post more interesting articles here.
The blog is unique that's providing the nice material. Please post more interesting articles here.