Matt Benjamin (LinuxInsider):

That said, NoSQL is not for everyone. The power and sophistication of SQL databases are the foundation for a wide range of reporting and data access technologies, from application frameworks to report generation systems. It will be some time before NoSQL equivalents for such integration technologies can be put in place.

☞ www.linuxinsider.com

I’m not even sure NoSQL databases will need to get to that level.

The Unix tools success was based on some brilliant simple rules:

• write programs that do one thing and do it well
• write programs to work together
• write programs to handle text streams, because that is a universal interface

In my opinion NoSQL databases should follow closely this philosophy (nb some of them have already departed from the last rule and ignored the importance of protocols).

Original title and link: NoSQL Databases and The Unix Philosophy (NoSQL databases © myNoSQL)

Last week most read posts about NoSQL databases

1. Node.js, Unix, and MongoDB: The New LAMP. Some are saying this is the new LAMP. Do you agree?
2. MongoDB and Scala Presentation: a presentation on using MongoDB from Scala
3. Graph Databases: More than An Introduction: a very informed and detailed presentation about graph databases from Marko Rodriguez
4. MongoDB and Security via Diaspora: judging by Diaspora’s code, MongoDB can still see injection attacks.
5. Graph Databases: What Are They and Where do They Fit: why would developers choose a graph database over a tradition database?

My favorites from last week in NoSQL databases

• Hadoop Cluster Configuration Tips
• Document databases: 11 Document-oriented Applications
• NoSQL: Do You Need to Associate Your Product with it?
• Redis at GitHub
• RavenDB: Index Replication to Relational Databases
• Membase Releases the 4th Beta, Featuring Memcached Buckets

Original title and link: NoSQL Databases in Review 30 (NoSQL databases © myNoSQL)

Mohammad Abdurraafay in a post about Apple Core Data:

My take on Core Data is, because it’s just not being Open Sourced, it’s not filed under NoSql. Otherwise, it’s the only NoSql on the best mobile platform, i.e. iOS and probably the first.

☞ posts.mohammadabdurraafay.com

This seems to be a reoccurring theme for existing storage solutions and not only. And I bet things will get more intense in the near future.

Indeed there are various arguments that can be used to associate your product with NoSQL databases: the data model, the processing model, the lack of SQL, etc. You have a key-value store (e.g. BerkleyDB) it is NoSQL. You have an object database or its new reincarnation as graph database, then you have a NoSQL database. Your product deals with BigData, then it is NoSQL.

But the real question is: if your product is already filling a market need and is well positioned, why would you try to place it under a buzzword umbrella?

Original title and link: NoSQL: Do You Need to Associate Your Product with it? (NoSQL databases © myNoSQL)

Last week most read posts about NoSQL databases

1. MongoDB and MySQL Benchmarks: A very interesting benchmark this time with many things to be learned.
2. To Lose or Not to Lose Data… There is No Question: Learn how not to lose your data.
3. Xeround: MySQL Elastic, Always-on Storage Engine for the Cloud: an interesting new option for running a scalable, elastic MySQL in the cloud. But there are quite a few questions about it.
4. Redis: Implementing Auto Complete or How to build Trie on Redis: Using Redis sorted sets to implement trie or more practical, an auto complete feature for your app.
5. CouchDB: The File system for the internet: is CouchDB message a bit confusing?

My favorites from last week in NoSQL databases

• Cassandra: Tunning for Performance: title says it all
• MongoDB Trick: List Commands: a nice trick for always remembering all commands available in MongoDB
• MySQL: An Online Schema Change Tool from Facebook: interesting tool coming (again) from Facebook
• Neo4j Gets Geo Support: afaik the first graph database to get Geo support.
• Hadoop Used to Find the 2 Quadrillionth Digit of PI: how to use Hadoop in a different way

Original title and link: NoSQL Databases in Review 29 (NoSQL databases © myNoSQL)

Jeff Darcy (@Obdurodon) has two great posts (☞ here and ☞ here) about what makes/keep your data safe or not so safe (nb we had a similar, but brief attempt when writing about file system durability). These two posts could easily result in a list of DOs and DONTs to keep around:

DONT’s or How you can lose data

• don’t provide full redundancy at all levels of your system
• be careless about non-battery-backed disk caches
• be careless about data ordering in the kernel
• be careless about your own data ordering
• don’t provide any reasonable way to take a backup

DOs or How to keep your data safe

Make sure that you took care of all the above points. Jeff also presents some approaches for ensuring data protection:

• immutable and/or append-only files, based on log structured filesystem
• copy on write

It’s worth noting also that, especially in a distributed environment, these approaches can be combined. For example, VoldFS itself uses a COW approach but most of the actual or candidate data stores from which it allocates its blocks are themselves more log-oriented. As always it’s horses for courses, and different systems – or even different parts of the same system – might be best served by different approaches. That’s why I thought it was worth describing multiple alternatives and the tradeoffs between them.

You surely can say he’s obsess with data safeness — this is not a bad thing, but rather something all of us should always keep in mind — , as recently we’ve learned from him what is needed to secure data in NoSQL databases.

Original title and link for this post: To Lose or Not to Lose Data… There’s No Question (NoSQL databases © myNoSQL)

Nitin Borwankar, Couch DB, VP of business development:

the goal here is to make couchdb the file system for the internet

via ☞ Chris Hardcastle

Sometimes I’m getting confused: is CouchDB for mobiles^[1], or is CouchDB for scalable bigdata apps^[2], or is CouchDB for disconnected web applications, or is CouchDB for Geo applications?

While I’m not saying that it should do only one thing, the message sounds a bit confusing when compared with other NoSQL databases: Cassandra, HBase: BigData for big boys, Riak: Amazon-style scalable key-value store, Membase: the persistent memcached, Redis: the smart data type, super fast key-value store.

Original title and link for this post: CouchDB: The File system for the internet (published on the NoSQL blog: myNoSQL)

Last week most read posts about NoSQL databases

1. CouchDB: Sell it to Your Boss: some good answers to what and why CouchDB, use cases, and a decent dose of buzzwords to help you sell CouchDB to your boss.
2. Redis: A Concurrency Benchmark: A very interesting benchmark of Redis behavior with varying client concurrency. This benchmark also uncovered a bug in Redis 2.0.0, which got fixed days later in Redis 2.0.1
3. Using Object Database db4o as Storage Provider in Voldemort: Learn what is needed to develop of backend storage for Project Voldemort, using db4o as an example and comparing it with the BDB current implementation.
4. Redis Snippet for Storing the Social Graph: a good code snippet showing how Redis can be used to store social graph relationships.
5. Why NoSQL does not Impress Me: a couple of good, but also bad points about NoSQL databases and their adoption.

My favorites from last week:

• BigCouch: Java Map-Reduce with CouchDB
• 3 Reasons to Use MongoDB
• NoSQL Databases Bring Stored Procedures Back In Fashion
• CouchDB for Android. iPhone Next?
• Extensive Riak Benchmarking at Mozilla Test Pilot

Original title and link for this post: NoSQL Databases in Review 28 (published on the NoSQL blog: myNoSQL)