nosql databases: All content tagged as nosql databases in NoSQL databases and polyglot persistence
Monday, 5 March 2012
Victims of the SQL Hammer
The first thing you need to realize is that you’re a victim of the SQL hammer. If having a hammer means everything is a nail, then it’s the same for SQL. Imagine, for instance, that Google’s search engine (which is trying to deliver information that is personal and relevant to you) was built by a group of SQL engineers. First, they would have designed a global data schema for all the information on the planet. Then they would have used the extract, transform and load (ETL) process and data-cleansing tools to bring all the information on the planet into their global SQL database. Finally, they would write reports such as: “Places to camp in France,” or “Chinese restaurants in Hickory, N.C.” After 10 years and tens of millions of dollars, the team would probably have given up. Fortunately, Google didn’t take that approach.
As much as I support the NoSQL space, I’ve already seen victims of the NoSQL hammer in only 2 and a half years. Both the hammer and new shiny toy syndroms are as present. One could even say that you cannot have the one without the other.
Original title and link: Victims of the SQL Hammer (©myNoSQL)
Scaling Filesystems vs. Other Things
Before moving back to NoSQL databases, I wanted to stay in the land of file systems for a conversation between Jeff Darcy and David Strauss about the usage of file systems for large scale and high availability:
As I see it, aggregating local filesystems to provide a single storage pool with a filesystem interface and aggregating local filesystems to provide a single storage pool with another interface (such as a column-oriented database) aren’t even different enough to say that one is definitely preferable to the other. The same fundamental issues, and many of the same techniques, apply to both. Saying that filesystems are the wrong way to address scale is like saying that a magnetic #3 Phillips screwdriver is the wrong way to turn a screw. Sometimes it is exactly the right tool, and other times the “right” tool isn’t as different from the “wrong” tool as its makers would have you believe.
Original title and link: Scaling Filesystems vs. Other Things (©myNoSQL)
via: http://pl.atyp.us/wordpress/index.php/2012/01/scaling-filesystems-vs-other-things/
Monday, 27 February 2012
Taking a Step Back From ORMs and a Parallel to the Database World
Jeff Davis:
So, my proposal is this: take a step back from ORMs, and consider working more closely with SQL and a good database driver. Try to work with the database, and find out what it has to offer; don’t use layers of indirection to avoid knowing about the database. See what you like and don’t like about the process after an honest assessment, and whether ORMs are a real improvement or a distracting complication.
I know a lot of applications using ORMs that worked perfectly fine. And I know applications that had to go around the ORMs or even got rid completely of them.
Here is a parallel to think about: ORM vs SQL is similar to always using a relational database versus using the storage solution that better fits the problem—as in using a NoSQL database or going polyglot persistence. An ORM comes with the advantage of keeping you inside a single paradigm (object oriented) at the cost of not being able to (easily) use the full power of the underlying storage.
Original title and link: Taking a Step Back From ORMs and a Parallel to the Database World (©myNoSQL)
via: http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/
Thursday, 9 February 2012
The Future is 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)
Monday, 6 February 2012
Data Grid or NoSQL? What are the common points? The main differences?
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:
- CouchDB:
_changesfeed with filters - Riak: pre-commit and post-commit hooks
- HBase coprocessors
- CouchDB:
- 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)
Thursday, 2 February 2012
The time for NoSQL is now
Andrew C. Oliver:
The transition to NoSQL databases will take time. We still don’t have TOAD, Crystal Reports, query language standardization and other essential tools needed for mass adoption. There will be missteps (i.e. I may need a different type of database for reporting than for my operational system), but I truly think this is one technology that isn’t just marketing.
This coming from someone that was happy to discover back in 1998 all the knobs in Oracle.
Original title and link: The time for NoSQL is now (©myNoSQL)
What does DynamoDB mean for the enteprise world?
Tim Moreton1:
I expect not much in the short term, until some key issues are solved. First, the sources and consumers of data are still on-site. These guys are tackling a specific technical limitation, not necessarily looking to re-architect their wider systems, which are often complex and inter-dependent. Second, security and regulatory concerns may need addressing. Third, the TCO needs to stack up. A quick and dirty back of the envelope calculation suggests that although it’s free to get started with DynamoDB, for the sort of deployment sizes we’re seeing, DynamoDB works out considerably more expensive than alternatives like Acunu deployed on hardware (even after accounting for typical full costing for outsourced data centers).
Keeping my eyes on all things NoSQL for more than 2 years, I’d say that NoSQL databases in general do not mean much for the enterprise world2. Yet.
-
Tim Moreton: CEO Acunu ↩
Original title and link: What does DynamoDB mean for the enteprise world? (©myNoSQL)
via: http://www.acunu.com/blogs/tim-moreton/welcome-party-dynamodb/
Wednesday, 1 February 2012
Why NoSQL Databases Are Not Just For Google and Amazon?
Oren Eini1:
Why the history lesson, you ask? Why, to give you some perspective on the design choices that led to the victory of the relational databases. Space was at a premium, the interaction between the user and the application closely modeled the physical layout of the data in the database. That made sense, because there really were no other alternatives given the environment that existed at the time.
In my company, we are using RavenDB as the backend database for everything from a blog, our ordering and purchasing systems, the daily build server and many more. The major advantages that we found weren’t the ability to scale (although that exists), it is the freedom that it gives us in terms of modeling our data and changing our minds.
The Googles, Facebooks, and Amazons told the story of this was not our relational database vendors’ fault. Jan Lehnardt2 said a while back that NoSQL is about choice. I said that NoSQL databases are a departure from having just good enough solutions. And Oren Eini is emphasizing the benefits of other data models.
Original title and link: Why NoSQL Databases Are Not Just For Google and Amazon? (©myNoSQL)
via: http://java.dzone.com/articles/why-nosql-not-just-google-and
Thursday, 26 January 2012
The History of NoSQL: This Was Not Our Technology Vendors’ Fault
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)
Friday, 20 January 2012
Reinforcing Couchbase's Commitment to Open Source
Bob Wiederhol, the CEO of Couchbase:
We’re 100% committed to open source and all of our code is available under the Apache 2.0 license.
Is.
Original title and link: Reinforcing Couchbase’s Commitment to Open Source (©myNoSQL)
via: http://blog.couchbase.com/couchbase-commitment-to-open-source-and-couchdb
Tuesday, 10 January 2012
NoSQL Databases’ Adoption in the Enteprise World
There are two guaranteed ways that NoSQL databases will penetrate the enterprise world. I’m not referring here to small departamental experiments, but big budget and long-term penetration.
The first way is by seemless integration with Hadoop[1]. It’s a fact that Hadoop isn’t anymore just a tool for startups or internet companies. It is seeing widely adoption and with the release of Hadoop 1.0.0—which changes the way Hadoop’s maturity in perceived—things will only get better. Being able to augment a Hadoop-centric architecture will definitely be a huge adoption driver.
The second way is by being first class citizens of widely adopted frameworks. In the Java world that could be JEE and Spring—there’s is already Spring Data and the Enterprise integration patterns Spring framework Spring Integration which features Redis and MongoDB. In the Python world that could be Django—Django played nice with NoSQL databases and even considered including support for NoSQL databases in the trunk. In Ruby, that could be Ruby on Rails which has almost always adopted the latest technologies. And the list could go on[2]. Keep in mind though that extensions and plugins are just the first step, but they do not represent first class citizenship.
Original title and link: NoSQL Databases’ Adoption in the Enteprise World (©myNoSQL)
Friday, 6 January 2012
NoSQL Applications Panel Video
Hey, it looks like the NoSQL applications panel I’ve moderated at QCon SF 2011 went live minutes ago on InfoQ. Featuring Andy Gross (Basho), Frank Weigel (Couchbase), Matt Pfeil (DataStax), Michael Stack (StumbleUpon), Jared Rosoff (10gen), and yours truly.
Drop everything and start watching it now! I promise you’ll love every second of it[1].
-
It misses my opening jokes though ↩
Original title and link: NoSQL Applications Panel Video (©myNoSQL)
Most Popular Articles
- Translate SQL to MongoDB MapReduce
- Tutorial: Getting Started With Cassandra
- CouchDB vs MongoDB: An attempt for a More Informed Comparison
- Cassandra @ Twitter: An Interview with Ryan King
- A Couple of Nice GUI Tools for MongoDB
- NoSQL benchmarks and performance evaluations
- Ehcache: Distributed Cache or NoSQL Store?
- Document Databases Compared: CouchDB, MongoDB, RavenDB
- Quick Review of Existing Graph Databases
- NoSQL Data Modeling
