nosql databases: All content tagged as nosql databases in NoSQL databases and polyglot persistence
Marting Fowler and Pramod Sadalage in an infographic promoting their upcoming book (PDF):
Polyglot persistence will occur over the enterprise as different applications use different data storage technologies. It will also occur within a single application as different parts of an application’s data store have different access characteristics.
There are over 2 years since I’ve begun evangelizing polyglot persistence. By now, most thought leaders agree it is the future. Next on my agenda is having the top relational vendors sign off too. Actually, I’m almost there: Oracle is promoting an Oracle NoSQL Database and Microsoft is offering both relational and non-relational solutions with Azure. They just need to say it.
Original title and link: The Future is Polyglot Persistence ( ©myNoSQL)
A great post by Olivier Mallassi on a topic that comes up very often: how do data grids and NoSQL databases compare?
- Data Grids enable you controlling the way data is stored. They all have default implementation (Gigaspaces offers RDBMS by default, Gemfire offers file and disk based storage by default….) but in all cases, you can choose the one that fits your needs: do you need to store data, do you need to relieve the existing databases….
- In order to minimize the latency, data grids enable you to store data synchronously (write-through) or asynchronously (write-behind) on disk. You can also define overflow strategies. In that case, data is store in memory up to a treshold where data is flushed on disk (following algorithms like LRU …). NoSQL solutions have not been designed to provide these features.
- Data grids enable you developing Event Driven Architecture.
- Querying is maybe the point on which pure NoSQL solutions and data grids are merging.
- Data grids enable near-cache topologies.
Taking a step back you’ll notice that there are actually more similarities than differences. While Oliver Mallasi lists the above points as features that prove data grids as being more configurable and so more adaptable, some of these do exist also in the NoSQL databases taking different forms:
- pluggable storage backends. Not many of the NoSQL databases have this feature,but Riak and Project Voldemort are offering different solutions that are optimized for specific scenarios.
- replicated and durable writes. Not the same as synchronous vs asynchronous writes, but a different perspective on writes.
- Notification mechanisms. Once again not all of the NoSQL databases support notification mechanisms, but a couple of them have offer some interesting approaches:
- Most of the NoSQL database have local per-node caches.
With these, I’ve probably made things even blurrier. But let me try to draw a line between data grids and NoSQL databases. Data grids are optimized for handling data in memory. Everything that spills over is secondary. On the other hand, NoSQL databases are for storing data. Thus they focus on how they organize data (on disk or in memory) and optimize access to it. Data grids are a processing/architectural model. NoSQL databases are storage solutions.
Original title and link: Data Grid or NoSQL? What are the common points? The main differences? ( ©myNoSQL)
Werner Vogels in the post about Amazon DynamoDB:
We had been pushing the scalability of commercially available technologies to their limits and finally reached a point where these third party technologies could no longer be used without significant risk. This was not our technology vendors’ fault; Amazon’s scaling needs were beyond the specs for their technologies and we were using them in ways that most of their customers were not. A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries.
Here is what I wrote about the history behind NoSQL databases:
Providing decent solutions, up to a point, to a wide range of problems and covering more scenarios than alternative storage solutions existing at that time, made relational databases the de facto storage for the last 30 years. But during the last years, more and more problems crossed the boundaries of what could have been considered decent solutions leading to the need for specialized, better than good enough alternative solutions. And thus NoSQL databases.
It feels rewarding to get such confirmation from people that are at the forefront of NoSQL.
Original title and link: The History of NoSQL: This Was Not Our Technology Vendors’ Fault ( ©myNoSQL)