When the world was living in an age of SQL gurus and Database Administrators with expertise in stored procedures and triggers, a few brave men dared to rebel. The reason was "simplicity". SQL was good to use when there was a structure and a fixed set of rules. The common databases such as Oracle, SQL Server, MySQL, DB2, and PostgreSQL, all promoted SQL — referential integrity, consistency, and atomic transactions. One of the SQL based rebels - SQLite decided to be really "lite" and either ignored most of these constructs or did not enforce them based on the premise: "Know what you are doing or beware".

Similarly, NoSQL is all about using simple keys to store data. Searching keys uses various hashing algorithms, but at the end of the day all we have is a simple data store!

With the advent of web applications and crowd sourcing web portals, the mantra was "more scalable than highly available" and "more speed instead of consistency". Some web applications may be okay with these and others may not. What is important is that there is now a choice and developers can choose wisely!

It's interesting to note that "key-value pair" databases have existed from the early 80's — the earliest to my knowledge being Berkeley DB — blazingly fast, light-weight, and a very simple library to use.

Brewer's CAP theorem states that any distributed computer system can support only any two among consistency, atomicity, and partition tolerance.

There is sufficient belief that any database can guarantee any two of the above. However, the essence of the CAP theorem is not to find a solution to have all three behaviors, but to allow us to look at designing databases differently based on the application we want to build!

For example, if you are building a Core Banking System (CBS) , consistency and atomicity are extremely important. The CBS must guarantee these two at the cost of partition tolerance. Of course, a CBS has its failover systems, backup, and live replication to guarantee zero downtime, but at the cost of additional infrastructure and usually a single large instance of the database.

A heavily accessed information web portal with a large amount of data requires speed and scale, not consistency. Does the order of comments submitted at the same time really matter? What matters is how quickly and consistently the data was delivered. This is a clear case of consistency and partition tolerance at the cost of atomicity.

"Basically Available, Soft-state, Eventually-consistent"!!

Just the name suggests, a trade-off, BASE databases (yes, they are called BASE databases intentionally to mock ACID databases) use some tactics to have consistency, atomicity, and partition tolerance "eventually". They do not really defy the CAP theorem but work around it.

Simply put: I can afford my database to be consistent over time by synchronizing information between different database nodes. I can cache data (also called "soft-state") and persist it later to increase the response time of my database. I can have a number of database nodes with distributed data (partition tolerance) to be highly available and any loss of connectivity to any nodes prompts other nodes to take over!

This does not mean that BASE databases are not prone to failure. It does imply however, that they can recover quickly and consistently. They usually reside on standard commodity hardware, thus making them affordable for most businesses!

A lot of databases on websites prefer speed, performance, and scalability instead of pure consistency and integrity of data. However, as the next topic will cover, it is important to know what to choose!

"Atomic, Consistent, Isolated, and Durable" (ACID) is a cliched term used for transactional databases. ACID databases are still very popular today but BASE databases are catching up.

ACID databases are good to use when you have heavy transactions at the core of your business processes. But most applications can live without this complexity. This does not imply that BASE databases do not support transactions, it's just that ACID databases are better suited for them.

Choose a database wisely — an old man said rightly! A choice of a database can decide the future of your product. There are many databases today that we can choose from. Here are some basic rules to help choose between databases for web applications:

So, if you are now convinced (or rather interested to read on about MongoDB), you might wonder where Ruby fits in anyway? Ruby is one of the languages that is being adopted the fastest among all the new-age object oriented languages. But the big differentiator is that it is a language that can be used, tweaked, and cranked in any way that you want — from writing sweet smelling code to writing a domain-specific language (DSL)!

Ruby metaprogramming lets us easily adapt to any new technology, frameworks, API, and libraries. In fact, most new services today always bundle a Ruby gem for easy integration.

There are many Ruby implementations available today (sometimes called Rubies) such as, the original MRI, JRuby, Rubinius, MacRuby, MagLev, and the Ruby Enterprise Edition. Each of them has a slightly different flavors, much like the different flavors of Linux.

I often have to "sell" Ruby to nontechnical or technically biased people. This simple experiment never fails:

When I code in Ruby, I can guarantee, "My grandmother can read my code". Can any other language guarantee that? The following is a simple code in C:

/* A simple snippet of code in C */
for (i = 0; i < 10; i++) {
printf("Hi");
}

And now the same code in Ruby:

# The same snippet of code in Ruby
10.times do
print "hi"
end

There is no way that the Ruby code can be misinterpreted. Yes, I am not saying that you cannot write complex and complicated code in Ruby, but most code is simple to read and understand. Frameworks, such as Rails and Sinatra, use this feature to ensure that the code we see is readable! There is a lot of code under the cover which enables this though. For example, take a look at the following Ruby code:

# library.rb
class Library
has_many :books
end
# book.rb
class Book
belongs_to :library
end

It's quite understandable that "A library has many books" and that "A book belongs to a library".

The really fun part of working in Ruby (and Rails) is the finesse in the language. For example, in the small Rails code snippet we just saw, books is plural and library is singular. The framework infers the model Book model by the symbol :books and infers the Library model from the symbol :library — it goes the distance to make code readable.

As a language, Ruby is free flowing with relaxed rules — you can define a method call true in your calls that could return false! Ruby is a language where you do whatever you want as long as you know its impact. It's a human language and you can do the same thing in many different ways! There is no right or wrong way; there is only a more efficient way. Here is a simple example to demonstrate the power of Ruby! How do you calculate the sum of all the numbers in the array [1, 2, 3, 4, 5]?

The non-Ruby way of doing this in Ruby is:

sum = 0
for element in [1, 2, 3, 4, 5] do
sum += element
end

The not-so-much-fun way of doing this in Ruby could be:

sum = 0
[1, 2, 3, 4, 5].each do |element|
sum += element
end

The normal-fun way of doing this in Ruby is:

[1, 2, 3, 4, 5].inject(0) { |sum, element| sum + element }

Finally, the kick-ass way of doing this in Ruby is either one of the following:

[1, 2, 3, 4, 5].inject(&:+)
[1, 2, 3, 4, 5].reduce(:+)

There you have it! So many different ways of doing the same thing in Ruby but notice how most Ruby — code gets done in one line.

Enjoy Ruby!

Chapter 1, Installing MongoDB and Ruby, describes how to install MongoDB on Linux and Mac OS. We shall learn about the various MongoDB utilities and their usage. We then install Ruby using RVM and also get a brief introduction to rbenv.

Chapter 2, Diving Deep into MongoDB, explains the various concepts of MongoDB and how it differs from relational databases. We learn various techniques, such as inserting and updating documents and searching for documents. We even get a brief introduction to Map/Reduce.

Chapter 3, MongoDB Internals, shares some details about what BSON is, usage of JavaScript, the global write lock, and why there are no joins or transactions supported in MongoDB. If you are a person in the fast lane, you can skip this chapter.

Chapter 4, Working Out Your Way with Queries, explains how we can query MongoDB documents and search inside different data types such as arrays, hashes, and embedded documents. We learn about the various query options and even regular expression based searching.

Chapter 5, Ruby DataMappers: Ruby and MongoDB Go Hand in Hand, provides details on how to use Ruby data mappers to query MongoDB. This is our first introduction to MongoMapper and Mongoid. We learn how to configure both of them, query using these data mappers, and even see some basic comparison between them.

Chapter 6, Modeling Ruby with Mongoid, introduces us to data models, Rails, Sinatra, and how we can model data using MongoDB data mappers. This is the core of the web application and we see various ways to model data, organize our code, and query using Mongoid.

Chapter 7, Achieving High Performance on Your Ruby Application with MongoDB, explains the importance of profiling and ensuring better performance right from the start of developing web applications using Ruby and MongoDB. We learn some best practices and concepts concerning the performance of web applications, tools, and methods which monitor the performance of our web application.

Chapter 8, Rack, Sinatra, Rails, and MongoDB — Making Use of them All, describes in detail how to build the full web application in Rails and Sinatra using Mongoid. We design the logical flow, the views, and even learn how to test our code and document it.

Chapter 9, Going Everywhere — Geospatial Indexing with MongoDB, helps us understand geolocation concepts. We learn how to set up geospatial indexes, get introduced to geocoding, and learn about geolocation spherical queries.

Chapter 10, Scaling MongoDB, provides details on how we scale MongoDB using replica sets. We learn about sharding, replication, and how we can improve performance using MongoDB map/reduce.

Appendix, Pop Quiz Answers, provides answers to the quizzes present at the end of chapters.

This book would require the following:

And other gems, of which I will inform you as we need them!

This book assumes that you are experienced in Ruby and web development skills - HTML, and CSS. Having knowledge of using NoSQL will help you get through the concepts quicker, but it is not mandatory. No prior knowledge of MongoDB required.

In this book, you will find several headings appearing frequently.

To give clear instructions of how to complete a procedure or task, we use:

Instructions often need some extra explanation so that they make sense, so they are followed with:

book = {
name: "Oliver Twist",
author: "Charles Dickens",
publisher: "Dover Publications",
published_on: "December 30, 2002",
category: ['Classics', 'Drama']
}

function(key, values) {
var result = {votes: 0}
values.forEach(function(value) {
result.votes += value.votes;

});
return result;
}

$ curl -L get.rvm.io | bash -s stable

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title through the subject of your message.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.