Changing the ModelRelational databases have always relied upon some very hard-and-fast, structured rules that govern the conduct of database transactions. These are encoded in the ACID model and require that the database always preserve the atomicity, consistency, isolation and durability of database transactions. Any action that might violate the ACID model is expressly prohibited and there is no wiggle room for the fuzzy situations that might require a variance.
NoSQL turns the ACID model upside down and allows a much more laissez-faire approach to database management: the BASE model. Instead of requiring rigid adherence to the ACID principles, BASE offers three loose guidelines: basic availability, soft state and eventual consistency. It’s fair to say that NoSQL’s BASE approach is the laid-back alternative to the straight-laced ACID model used by relational databases.
If Not Tables, Then What?Instead of using structured tables to store multiple related attributes in a row, NoSQL databases use the concept of a key/value store. Quite simply, there is no schema for the database. It simply stores values for each provided key, distributes them across the database and then allows their efficient retrieval. The lack of a schema prevents complex queries and essentially prevents the use of NoSQL as a transactional database environment.
There are four main types of NoSQL databases:
- The basic key/value store performs nothing other than the function described above – taking a binary data object, associating it with a key, and storing it in the database for later retrieval.
- Document stores go beyond this slightly by imposing a little more structure on the binary object. The objects must be documents, encoded in some recognizable format, such as XML or PDF, but there are no requirements about the structure or content of the document. Each document is stored as the value portion of a key/value store and may be accompanied by metadata embedded in the document itself.
- Columnar databases are a hybrid between NoSQL and relational databases. They provide some row-and-column structure, but do not have the strict rules of relational databases.
- Graph databases store information in multi-attribute tuples that reflect relationships in a different way. For example, a graph database might be used to store the "friend" relationships of a social network, with a record merely consisting of two friends who share a relationship.
NoSQL ArchitectureThe core of the NoSQL database is the hash function – a mathematical algorithm that takes a variable length input and produces a consistent, fixed-length output. The key of each key/value pair being fed to a NoSQL database is hashed and this hash value is used to direct the pair to a particular NoSQL database server, where the record is stored for later retrieval.
When an application wishes to retrieve a key value pair, it provides the database with the key. This key is then hashed again to determine the appropriate server where the data would be stored (if the key exists in the database) and then the database engine retrieves the key/value pair from that server.
As you read the description of this process, you may find yourself wondering “How does the user or application perform more advanced queries, such as finding all of the keys that have a particular value or sorting data by a value?” And, there’s the rub – NoSQL databases simply do not support this type of functionality. They are designed for the rapid, efficient storage of key/value pairs where the application only needs a place to stash data, later retrieving it by the key, and only by the key. If you need to perform other queries, NoSQL is not the appropriate platform for your use.