Kelly knew it. The U.S. Navy knows it. You know it.
Keep it Simple, Stupid (KISS)
We have to categorize everything, so we categorized NoSQL implementations. There are several categories, but I will focus on three.
- Distributed Caches
- Key / Value Stores
- Document Databases
If a distributed cache is required, add a distributed cache. If a key / value store is required, add a key / value store. If a document database is required, add a document database.
What if all three requirements must be met?
- A distributed cache is required for high performance.
- A key / value store is required performance and persistence.
- A document database is required for durability and processing.
It’s a problem. Should three different NoSQL implementations be added? Do you add Redis, Riak, and MongoDB?
The result would not be simple, stupid.
No categories. Let distributed caching, key / value storage, and document handling be use cases. The solution is a single NoSQL implementation that supports multiple use cases.
You add a single NoSQL implementation that can be used as a distributed cache, as a key / value store, and as a document database.
Think about it.
A key /value store is more or less a distributed cache with persistence. A document database is more or less a key / value store with document processing.
Start with a distributed cache. Next, add persistence. Finally, add document processing. It makes sense. On the other hand, alternative NoSQL implementations such as MongoDB started with document processing. As a result, they can’t or shouldn’t be used as key / value stores or as distributed caches.
In fact, Viber recently solved this problem. Their previous architecture relied on MongDB for document processing and Redis for distributed caching. Their current architecture relies on Couchbase Server as a single replacement for both MongoDB and Redis. The details can be found here.