Deciding on NOSQL vs RDMS

-
Anybody not living in a cave knows that NOSQL is a current hot topic amount technology solutions. One sadly missing piece is some sort of guide on how to determine if NOSQL or a more traditional RDBMS is a better solution.

To start with, I'll say you should assume that an RDBMS is probably the safest bet. Almost anything you can do with a document store can be done with an RDBMS, with the exception that it may not scale and/or perform as well as NOSQL solution. The big advantages of RDBMS solutions is that they have an enormous ecosystem of tools, documentation, and skilled administrators.

Given the above, why would anyone ever even look at a NOSQL solution? Here are a couple indicators that a NOSQL solution might be a better fit for your problem:

#1 You are storing simple key/value pairs. If your RDBMS "solution" ends up being a single table with a couple key fields and a CLOB with XML in it... you're probably using the wrong tool for the job.
#2 You are storing complex data structures that are non-relational. If you store hierarchal data structures that each "master" has different children on it, you're going to run into problems with an RDBMS.
#3 You need massive scaleability and distribution, and the economics of scaling are important to you. Many RDBMS solutions offer partitioning schemes that offer very good scalability, but the cost (licensing and runtime overhead) of that scalability is often an order of magnitude higher than with a NOSQL solution.

Comments

Gail Gardner said…
Hello,

I followed a comment you made in a debate about databases from another blog. Bloggers need a database of bloggers searchable by niche and by location.

Unfortunately, databases are not my area of expertise so I am seeking a professional opinion on what kind of database expert I should be seeking out to build what we need.

This comment links to a post that contains the data we want to capture. I would truly appreciate your input. Thank you for your time.
July 8, 2011 at 11:22 PM
Mike Mainguy said…
I'm not sure what link you're talking about, but I do appreciate your comment and I have the same frustration with the state of "blog searching". Google is great for general web content, but trying to find topical content in blogs and limiting it to current events is almost impossible.

I think I see an application that needs to be written...
July 10, 2011 at 3:41 PM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more