CODE EXCEPTIONS

RDBMS alternatives called NoSQL

MongoDB is the leading open-source NoSQL data store, driving the market evolution. It was designed from the ground up to specifically address these new workloads and computing environments,completely changing how data is modeled, stored and accessed.

Built to handle large data sets, MongoDB’s use of multiple servers means you have all the resources you need to add compute, memory and storage capacity. As your data set gets bigger, there is no need to upgrade to expensive high-end hardware. This also means you can incrementally adopt newer and faster compute platforms without throwing out the models you had before.

MongoDB easily supports high transaction rate applications because as more servers are added, transactions are distributed across the larger cluster of nodes, which linearly increases database capacity. With this model additional capacity can be added without reaching any limits.

MongoDB o!ers a data model and query API that is more agile and better suited to modern development stacks and methodologies than traditional data stores. Rich objects are stored in hierarchical documents rather than rows split across multiple tables. These expanded data models result in expanded documents, rather than new rows, tables and columns. As a result, transactions remain simple even as data models evolve. If, for example, ten new #elds are added to a document, the query  time to fetch the document does not increase.

Documents in MongoDB use a “exible schema and can change dynamically with the continual development of your application. There is no need to develop a rigid schema that requires transformations of data and management of schema migrations in production. If your application data changes, fields can be added to objects without recon#guring your database.

Cloud ready
MongoDB was designed to run on commodity hardware, virtualized infrastructures, andthe cloud. Capacity can be added through additional virtual servers/machines on demand, scalable database on whatever infrastructure is present. This means that cloud and hypervisor-based environments are just as suitable as dedicated hardware. Additional virtual servers can be used to compensate for the varying performance and capacity of individual server nodes.

There are no limits to where you can run your application. Your developers, QA, staging, and production environments can use the same code without worrying about sharing proprietary or expensive hardware platforms.

By scaling across multiple servers, MongoDB ensures that your application will grow and run without bound in cloud and virtualized environments. And because MongoDB’s data model matches today’s data requirements, your developers will be more productive than with competing solutions.

MongoDB is not a key/value store, it’s quite a bit more. It’s definitely not a RDBMS either. I haven’t used MongoDB in production, but I have used it a little building a test app and it is a very cool piece of kit. It seems to be very performant and either has, or will have soon, fault tolerance and auto-sharding (aka it will scale). I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.

The real thing to point out is that if you are being held back from making something superawesome because you can’t choose a database, you are doing it wrong. If you know mysql, just used it. Optimize when you actually need to. Use it like a k/v store, use it like a rdbms, but for god sake, build your killer app! None of this will matter to most apps. Facebook still uses MySQL, a lot. Wikipedia uses MySQL, a lot. FriendFeed uses MySQL, a lot. NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

MongoDB is best suitable to store unstructured data. And this can organize your data into document format. These RDBMS altenatives called NoSQL data stores (MongoDB, CouchDB,Voldemort) are very useful for applications that scales massively and require faster data access from these big data stores