Reputation: 296
According to Wikipedia NoSQL article, there are a lot of NoSQL implementations.
What's the difference between document-oriented and key-value storages (as people mention them most often)?
Upvotes: 8
Views: 3690
Reputation: 1750
Here's a blog post I wrote, Visual Guide to NoSQL Systems, that illustrates the major differences between some of the most popular systems. The biggest difference between them is which of the following two they choose to optimize for: consistency, availability, and partition tolerance.
Upvotes: 13
Reputation: 61
In my opinion I don't really see how Cassandra is not consistent. It can't do consistent updates but I have never worked with a database model where updates are a requirement, as opposed to consistent versioned inserts (sometimes called versioned updates even if they are not really updates.
Also Cassandra can be fully ACID if you make your data model ACID. Instead of using database transaction, do a transaction the way banks do it. There the transaction is not a mulit-data change but a actual data object.
Bank account does not have money in them. They have transactions and your accounts current state is calculated from the transactions. Such transactions are not a database feature, but a part of the data model. They do not need to be instantly available to all nodes in order to be consistent, because they are immutable.
I have not found a case where making data immutable does not solve the consistency problem. This combined with making transactions part of the data model as immutable data (write once read many) the ACID requirements are met.
Atomic - A transaction as a unique immutable object/row becomes atomic without any complex database object to support it.
Consistency - A database operation or transaction can be designed in the data model so that it is consistent. All that is needed is really that it is immutable (never changed after creation)
Isolation - A transaction that does is its own data object should not interfere with others, and are therefore isolated.
Durability - If a transactions immutable data is lost it is equivalent to restoring the database to its previous state. If the data is not lost then it is in its post-transaction state. In either case it fills the durability requirement of ACID.
It is true that several things cannot be achieved in the "bank" data model. Your account info can not have a ACID row with a fixed amount of money. While the transactions themselves are ACID that does not mean that data depending on them can be. This is because a all transactions may not yet be visible from all nodes. They may even be in another banks database. Therefore your account balance can not achieve ACID consistency, but there is no reason for it to have such a requirement as long as all important data has ACID consistency - which it does.
I used the bank database as an example because it is often used as an example on how to do SQL transactions with rollback on account balance - something that NEVER happens in actual implementations... because bank transactions must support asynchronous multi-database transactions, or in other words cross-bank transactions.
You can also relate this to a file-system. Cassandra (for example) can give you a Consistent view of a immutable snapshot of a file. You are not guaranteed to have a view of the latest snapshot - but A snapshot. With this it makes it as consistent as CVS/SVN or CODA.
Upvotes: 2
Reputation: 16174
At one level document and key/value are quite similar - both will return an object when you request a key. In pure key/value that object will be a simple string, although it can be a serialized complex object. A document database extends this with functions to work with this object such as partial update functionality or search indexing.
Beyond that you will need to think about your specific requirements - NOSQL covers a lot of different systems, and unlike SQL databases they all have quite different advantages/disadvantages for a specific scenario.
Upvotes: 2