Sinatra step 8

A) What is MongoDB? How does it relate to MongoHQ?

MongoDB bridges the gap between key-value stores (which are fast and highly scalable) and traditional RDBMS systems (which provide rich queries and deep functionality).

MongoDB (from "humongous") is a scalable, high-performance, open source, document-oriented database. Written in C++, MongoDB features Document-oriented storage, Full index support, replication and high availability, auto-sharding, Querying, Fast in place updates, Map/reduce, Grids, commercial support.

MongoHQ. A cloud-based hosted database solution for MongoDB allows you to easily and quickly create and interact with MongoDB instances.

Reference:

The Best Features of Document Databases, Key-Value Stores, and RDBMSes (2010), Retrieved on 23^rd May 2010 from, http://www.mongodb.org/

B) What is Mongomapper?

MongoMapper is a Ruby wrapper library which aims to make using MongoDB much easier and friendlier than the default Ruby driver provided by XGen. When it makes sense to do so, MongoMapper tries to stick closely with the familiar syntax of ActiveRecord.

Because of the way MongoDB stores data, there are two key concepts when working with MongoMapper: the Document, and the EmbeddedDocument.

The Document is essentially a record with fields, just as you’d expect.

An Embedded Document is exactly like a Document, except that it is injected into a Document and still retains all of its information.

Because of the way MongoMapper works, all of this is transparent to you. With MongoMapper, when you retrieve a record with an embedded document attached to it, the embedded document’s information is retrieved along with it, which is where MongoMapper truly shines. By embedding when it makes sense to do so, you are able to retrieve all of the typical join information in one speedy query.

References:

Junemaker (January 1^st, 2010), MangoMapper Retrieved on 23^rd May, 2010 from,

http://wiki.github.com/jnunemaker/mongomapper/home/7

C) What is the relation between MongoDB and Mysql?

“Interesting about MongoDB is its approach to Durability, Data Consistency and Availability. It is very relaxed and will not work for some applications but for others it can be usable in current form. Let me explain some concepts and compare it to technologies in MySQL space.

First MongoDB is best compared no to MySQL Server but MySQL Cluster, especially in newer versions which implement "sharding". Same as commit to NDB Storage engine does not normally mean commit to disk, but rather commit to network it does not mean commit to disk with MongoDB, furthermore MongoDB uses Asynchronous replication, meaning it may take some time before data will be at more than one node. You can also use getLastError() to ensure data is propagated to the slave. So you can see it as a hybrid between MySQL Cluster and innodb_flush_log_at_trx_commit=2 mode. The second difference of course the fact MongoDB is not crash safe - similar to MyISAM database will need to be repaired if it crashes. Still I find behavior somewhat similar - you're not expected to run MySQL Cluster without replication, MongoDB is practically the same.

Second - if we look at Replication Sets we find them very similar to MySQL Cluster though designed to work with Wide area network and so Async replication. There is voting required to pick the master node in case of node failure and at least 3 servers is recommended, where you can have some voting servers only cast their votes and hold no data. The other different is there is only one master rather than multiple. This is because doing master with asynchronous replication requires conflict resolution which can be tricky in general sense and MongoDB wants simplicity of operation for developers and administration.

Third if we look at how failover happens - same with NDB (native API) it is handled on driver level. When you connect to replication set you connect to set of server not one of them and if one server fails driver fails over to different master. Things are again tuned to deal with Asynchronous Replication. Consistency is maintained but at expense of certain changes may be thrown away/ "rolled back" in case of fail over.” (Peter, 2010)

Reference:

Peter (1st May, 2010), Mongo DB Approach to Availability, Retrieved on 24th May 2010, from http://swik.net/mongodb+MySQL