What is NoSQL after all?
This name was first coined in 1998 by Carlo Strozzi for its lightweight open source relational database which simply didn't expose an SQL interface.
The First and OnlyNoSQL.
There are, since then, many Non-Relational, Distributed, open source, database efforts.
In 2009, Eric Evans reintroduced the term as a RDBS anti-pattern in an event to discuss all those databases that not only don't use SQL language but in fact are not Relational at all.
It was the no:sql(east) 2009 conference.
From then on, the most common interpretation of "NoSQL" is "non-relational".
Let's go and more technically define NoSQL.
- NoSQL systems are designed for clusters, so they tolerate hardware failures by keeping backup copies of the data on separate physical servers.
- NoSQL systems avoid going to disks when answering complex queries. Frequently, they have pre-sorted the data and loaded it into the RAM of several servers in a cluster.
- NoSQL systems perform write, delete, and update functions to unstructured data, much as relational systems work on structured tables.
- Queries are directed by MapReduce style guidance systems to the data and an associated processor.
- NoSQL systems are being built by Web site developers or cloud service providers, not by database architects and administrators.
- What NoSQL lacks in precision it makes up for in speed.
- NoSQL systems could perhaps be better called Distributed Database Management Systems (or DDBMSes).
- Instead of having tables with columns and rows like you would find in a traditional RDBMS, many NoSQL databases are based on hash table structure.
- Recently, column-oriented NoSQL databases have started to show up as well.
- NoSQL systems are being considered schema free, which means we can simply start working and create the data structure on the fly.
What prevails in NoSQL system:
- Massive scalability
- Low latency
- Ability to grow on demand
- An easier programming model
Do it the right way!
Notice that in modern life, most of the data you are using every day is unstructured. It is really a matter of recognizing it: Relational Databases are not the right answer for that. NoSQL is!
The NoSQL universe
According to the implementation characteristics, NoSQL databases could be categorized:
Hadoop / HBase; Cassandra; Hypertable; Cloudera; Amazon SimpleDB
MongoDB; CouchDB; Terrastore; ThruDB; OrientDB; Jackrabbit; Lotus Notes; RavenDB; Citrusleaf; SimpleDB; Keyspace
AllegroGraph; Core Data; Neo4j; Sones; DEX; InfoGrid; FlockDB; HyperGraphDB; Bigdata; Infinite Graph; OpenLink Virtuoso; VertexDB
BigTable; CDB; Citrusleaf; membase; Velocity; Memcachedb; Redis; Tokyo Cabinet; Tuple space; Cassandra; Dynamo; Hibari; Project Voldemort; Paxos algorithm; Keyspace; NMDB; Berkeley DB
OpenQM; Rocket U2; OpenInsight
Db4o; GemStone/S; InterSystems Caché; JADE; JOOB; Objectivity/DB; ZODB
BigTable; Mnesia; Hbase; Hypertable
In the Documents category of NoSQL databases, two of them have become trends in the field:
CouchDB and MongoDB
This guide will, from now on, be focused on how to install and put them both into work quickly.
Click on the corresponding logo to access the guide of your choice.
OK, now You have one of these cool NoSQL systems installed. And You probably want to start using it governed by an application.
Let me give a piece of advice: "The greatest enemy to human potential is Your Comfort Zone".
Must I remember You THIS?
Objects, Schemas and Valuable Data
There is a similar misconception between practicing "Agile Development" meaning undocumented or non-managed development. The fact that NoSQL deals with unstructured data, doesn't mean You can't Plan it Up front.
Objects weren't made for SQL schemas. In fact, objects shouldn't be mapped to a SQL schema.
Doing that way, we're forced to create "relationships", when we just need properties for our objects.
Non-relational databases are better suited for objects.
Maps, Hashes and Associative Arrays are undoubtedly the best object serialization formats.
NoSQL systems will let us store our objects in a data store designed for storing objects.
Unstructured data modeling strategy, basically consists on listing your data needs considering: High value data and Low value data.
To accomplish this You will probably need a Data mining Tool. At this point I recommend Voyeur as a Good online alternative, which let's You for instance, make your data mining from an existing Web page.
Keeping in mind that word frequency is just one more reference for decisions.
It's hard to define what a "High value data" is, it should perhaps be called "Most Valuable Data".
A suggested way
At this point, unless you are familiar and have deeply understand the NoSQL's unstructured nature, the worst thing to do, is: use one of the many Rails NoSQL ORMs plug-In ignoring the new paradigm bringing things back to Your Comfort Zone.
Doing that You will be treating unstructured non-relational data using an Object Relational Mapper.
The risk here is: continue thinking in the relational way outside the Object Mapping technique.
ORMs may be worthless if you don't understand what they're doing.
I'm thoughtful about Object Unstructured Mapping necessity nowadays.
I strongly recommend You instead, to stay cool and make a few more experiments before start using NoSQL in your next Rails Application.
NoSQL and Ruby
Using NoSQL with plain Ruby code, is a Piece of Cake. You can grab information from here:
Getting started with Ruby and CouchDB and MongoDB Ruby Tutorial
NoSQL Ruby and Web Applications
Coming soon... (no, not Rails yet)
NoSQL and Ruby on Rails Applications