I have to admit I learned quite a lot from this book. It is full of detail, plenty of examples, and even a sample application - building a blog publishing system with PHP & Mongodb.
What I liked:
The layout of the book is exactly how you'd want a technical book to be. The intro chapter answers some of your nagging questions such as How is data stored in a non-relational database? Why would you use a NoSQL database? What are it's use cases? From there the chapters take you by the hand, installing, querying, developing, and finally administering. So the book is easy to navigate.
As a DBA I wanted to know about replication, so I jumped right to chapter eleven. You learn about the oplog which is like the binlog in mysql, an ongoing log of changes to the database. The slaves then fetch and apply these changes themselves. Single master & single slave, single master & multiple slaves, multi master replication and cascading are all topologies that MongoDB supports.
There's of course also a whole chapter on general database administration of MongoDB, including full coverage of backups and so on. There's also a whole chapter on sharding, which is the process of scaling your database horizontally so you can handle more reads and writes.
What I didn't like:
The author seemed to make some sweeping statements that bothered me quite a bit. I won't go as far as to say there was a lack of relational database knowledge, but it was implied: "Improving performance with a relational database is usually straightforward: you buy a bigger, faster server." Well no actually, that's not really how you improve performance. As a long standing DBA with a decade and a half of experience I can tell you the best way to get orders of magnitude performance improvements is to look at how you are using resources, and use he more efficiently. In affect tuning developers code, and teaching them how to write optimal code, how to think about resources, and how to build test cases to benchmark.
Another one that was illustrative: "developers always have to work against the flow". Well I'm of two minds here. Yes they have to work against the flow, and constraints and structure is built into the database for a reason. So you have useful data at the end of the day, year, or decade of collecting it. On the other hand what I think they quote above is getting at is, the way data in an application is stored in memory, ie data structures, is very very different from how it is stored in databases. Do we have an alternative to this, and when and how might we use that?
I would have liked to see more comparisons, weighing the pros and cons of traditional rdbms's and then NoSQL solutions, and how they measure up. Since MongoDB is so new, inevitably folks considering the technology are somewhat versed already in relational databases, and are asking will MongoDB work. I would have also liked some business case studies, for instance a discussion of the recent FourSquare outage, what went wrong with MongoDB, and why.
On balance this is a really great book, well written, and easy to read. It will definitely address all of your beginning questions as both a DBA and a Developer, and send you off in the right direction to get started with MongoDB!