TInniam V Ganesh:

However when there is a need to scale the application to be capable of handling millions of transactions the NoSQL model works better. There are several examples of such databases – the more reputed are Google’s BigTable, HBase, Amazon’s Dynamo, CouchDB & MongoDB.

BigTable is available only to Google’s employees, Amazon’s Dynamo only to Amazon employees, CouchDB is not scalable per se, MongoDB scaling architecture is young and complicated. How about this list: Cassandra, HBase, Hypertable, Riak, Project Voldemort, Amazon SimpleDB, Hibari(?), MongoDB?

Original title and link: When NoSQL makes better sense than MySQL (NoSQL databases © myNoSQL)

via: http://gigadom.wordpress.com/2011/03/01/when-nosql-makes-better-sense-over-mysql/

My ideal database would borrow from RDBMS (like SQL Server), Document databases (like MongoDB), Graph Databases and Semantic Web Triple Stores; it would be the perfect hybrid of all of these and it would configure itself to be as efficient as possible answering queries.

That’s exactly the definition of polyglot persistence.

Every application could benefit of using different data models. The data ingestion module being a document store, a reporting module using relational data, another a graph model, etc.

But if all these models would exist in the same tool that will be a mammoth. It will be a tool good for everything, best at none — doesn’t that sound familiar in a way? Too heavy, too complicated, not agile.

Think of programming languages and multi-paradigms: object-oriented, functional, logic, etc. I’d love to be able to use any of them. But having a single language supporting all of these, I don’t know.

What I’d like is to have the option. And good, or even better, standardized inter-communication. Differently put, what I don’t want is a monolith, nor a highly heterogeneous environment.

Original title and link: Why do we need so many different databases? (NoSQL databases © myNoSQL)

via: http://blog.abodit.com/2011/03/the-learning-database-or-why-do-we-need-so-many-different-databases/

[SQL Azure] Federations bring great benefits of NoSQL model into SQL Azure where it is needed most. I have a special love for RDMSs after having worked on 2, Informix and SQL Server but I also have a great appreciation for NoSQL qualities after having worked on challenging web platforms. These web platforms need flexible app models with elasticity to handle unpredictable capacity requirements and needed the ability to deliver great computational capacity to handle peaks and at the same time deliver that with great economics. NoSQL does bring advantages in this space and I’d argue SQL Azure is inheriting some of these properties of NoSQL through federations.

The way I read it: “we’ve scaled SQL Server as much as we could. Now we need to look at how other scalable distributed systems are built to get us over the deadends we’ve hit”.

Original title and link: The NoSQL Gene in SQL Azure Federations (NoSQL databases © myNoSQL)

via: http://blogs.msdn.com/b/cbiyikoglu/archive/2011/03/03/nosql-genes-in-sql-azure-federations.aspx

Extensive comparison of the upcoming Database.com and Microsoft’s SQL Azure:

Salesforce.com will unbundle its underlying relational database engine from Force.com when the firm releases Database.com’s commercial version in 2011. In the meantime, developers can testdrive Database.com with a free Force.com developer account, which includes a Database.com database having:

• Three enterprise user accounts
• 100,000 rows of storage per month
• 150,000 transactions per month

According to the article, Database.com will support ACID transactions (Apex code), triggers and stored procedures (Apex code), relationships, a query language, full-text search. Looks like a relational database in the cloud, but it doesn’t necessarily need to be underneath.

Original title and link: Preliminary Comparison of Database.com and SQL Azure Features and Capabilities (NoSQL databases © myNoSQL)

via: http://oakleafblog.blogspot.com/2010/12/preliminary-comparison-of-databasecom.html

Options of running RDBMSs in the cloud:

• Install and Manage – in this “traditional” model the developer or sysadmin selects their DBMS, creates instances in their cloud, installs it, and is then responsible for all administration tasks (backups, clustering, snapshots, tuning, and recovering from a disaster. […]
• Use a Cloud-Managed DBaaS Instance – in this model the cloud provider offers a DBMS service that developers just use. All physical administration tasks (backup, recovery, log management, etc.) are performed by the cloud provider and the developer just needs to worry about structural tuning issues (indices, tables, query optimization, etc). […]
• Use an External Cloud-Agnostic DBaaS Solution – this is very much like the cloud-based DBaaS, but has a value of cloud-independence – at least in theory. In the long run you might expect to be able to use an independent DBaaS to provide multi-cloud availability and continuous operations in the event of a cloud failure.

I guess these are equivalent to applying Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Database-as-a-Service (DaaS) (nb: this can be seen as a more specialized PaaS) models to persistency. And the same approach applies to NoSQL databases, as these models are orthogonal the the persistency problem.

cloudbzz.com

Original title and link: SQL and NoSQL In the Cloud (NoSQL databases © myNoSQL)

via: http://www.cloudbzz.com/sql-in-the-cloud/

Monty Taylor:

Point being - when I rant about the suitability of NoSQL solutions, I’m mainly complaining that in many cases it seems to me that they’re using them because they’re popular or trendy and not because they are or are not actually suited to the task at hand.

The other way around is even more valid and I’d say it applies more often: RDBMS was used in some many cases just because it was around for such a long time.

Original title and link: Suitability of NoSQL Solutions (NoSQL databases © myNoSQL)

via: http://inaugust.com/post/93

A paper comparing MySQL and Neo4j coming from the Dept. of Computer and Information Science of University of Mississippi:

The evaluation methodology designed to compare MySQL and Neo4j involves objective benchmarks and subjective com- parisons based on system documentation and experience. The objective tests include processing speed based on a pre- defined set of queries, disk space requirements, and scalabil- ity. Subjective tests include maturity/level of support, ease of programming, flexibility, and security.

I’ve seen a MySQL and Neo4j benchmark before.

Original title and link: A Comparison of a Graph Database and a Relational Database (NoSQL databases © myNoSQL)

via: http://cs.olemiss.edu/~ychen/publications/conference/vicknair_acmse10.pdf

Interesting (and I think unique) feature added to RavenDB:

RavenDB is a great database for storing documents, and the ability to create indexes on top of documents make extracting information out of the indexes very easy. There are situations, especially for reports, when you still want to use a relational database. The Index Replication Bundle is meant to handle just those scenarios. It is capable of replicating an index a table in a relational database.

Original title and link: RavenDB: Index Replication to Relational Databases (NoSQL databases © myNoSQL)

via: http://ayende.com/Blog/archive/2010/09/22/ravendb-replicating-to-a-relational-database.aspx

A very entertaining article getting most of the things right:

So clever programmers looked at this ridiculous edifice and realized the real problem: the data store and the use-case were mismatched. So they threw away ORM, SQL, and RDBMS, and wrote lovely new key-value stores, or object stores, or document stores, or searchable indexes, or any of a half-dozen other data structures that more closely matched what they were trying to do.

[…]

Is your data really just a giant hash lookup? Then a key-value store is what you want. Do you primarily access your related data via a single key? Then a document store is for you. Do you need full-text searching? Then, dear god, use a text-indexing engine, not an RDBMS. Do you need to answer questions about your data that you can’t predict in advance? Then make sure your data also ends up in an RDBMS. Maybe not in real-time, maybe summarized rather than in raw form, but somehow.

The only part I don’t agree with is the part saying that ORM has been created to deal with SQL. The reason behind ORMs is object-relational impedance mismatch:

I want to be very, very clear about this: ORM is a stupid idea.

The birth of ORM lies in the fact that SQL is ugly and intimidating (because relational algebra is pretty hard, and very different to most other types of programming). Our programs already have an object-oriented model, and we already know one programming language — why learn a second language, and a second model? Let’s just throw an abstraction layer on top of this baby and forget there’s even an RDBMS down there. […]

You’ve stored your data in a way that doesn’t match your primary use-case, accessible via a language that you are not willing to learn. Your solution is to keep the store and the language and just wrap them in abstraction?

And the end of the post is fantastic:

So go forth, use your OMADS, keep an RDBMS in your back pocket, and stop being so mean to poor old SQL.

via: http://seldo.com/weblog/2010/07/12/in_defence_of_sql