What Are You For?

http://geek-and-poke.com/2012/06/no.html

NoSQL started out as meaning “No SQL” as in “No Relational Databases”.  It represented a movement to replace RDMBSs like SQL Server, DB2, Oracle, MySQL and Sybase.  Over time, the more adept architects realized that there’s a place for both relational and non-relational technologies. However, NoSQL was a brand at this point, so like KFC, they redefined this as meaning “Not Only SQL”.  This has been a nice turn of events, but it’s still a branding issue.

I believe the NoSQL community needs a new name – a new brand – to say what the community stands for.  In fact, I was on a closing panel at NoSQL Now! that discussed this need.  We didn’t really come up with an answer, but the general consensus was saying you aren’t isn’t nearly as helpful as saying what you are.

So what are those solutions that aren’t relational?  DocBlobGraphEVA?

Podcast: NoSQL and PeopleTalkingTech

I recently talked with my good friend Denny Cherry (@mrdenny | blog) about my experience at the NoSQL Now! conference and working with NoSQL technologies.  Denny’s new podcast series is called People Talking Tech and he has other interesting topics and people coming up soon.

http://peopletalkingtech.com/eposide-001-karen-lopez

My comments focused on how at the NoSQL professionals understand that it means "Not Only SQL" and can’t mean "No SQL" and have much of a future.  Using the right tool for the right job.  Cost, benefit, risk and all.

One of the things we talked about on the closing panel is "how do you find somebody that is a good architect who can tell you which types of technologies you can use for which use cases…"

Even though many people talk about NoSQL needing no architecture, we still need people to help choose when and what NoSQL technologies to use.  Seems to me that having experience working hands-on with relational and NoSQL technologies is going to be hugely valuable in the next couple of years.  If you have relational experience, now is the time to start learning about non-relational ones.

By the way, we talked a bit about database security.  Denny’s new edition of his book Securing SQL Server, Second Edition: Protecting Your Database from Attackers has recently been released.  Check it out.

NoSQL Survival Guide for Devs: How to Talk To your Data Architect

Was I Too Snarky? A Big Data NoSQL Roast

At Enterprise Data World last week I had a chance to defend my crown at the Lightning Talk sessions.  Lightning Talks are 5 minute presentations, usually done to highlight one point or to motivate people to go do something.

Most of my lightning talks, though, are rants on some thing.  Think a 5-minute long roast.  This year, I picked on Big Data and NoSQL names and terms.  While it appears that one person didn’t fully grasp the "roast" part of this rant, I think I did okay. At least most of the laughter wasn’t at me, but with me.

Mark Burnelli, Senior New Editor at SearchDataManagment.techtarget.com wrote an article about my rant:

The humorous verbal shellacking of big data — which generated plenty of audience laughs — came at the hands of Karen Lopez, a senior project manager and principal consultant with InfoAdvisors Inc. Lopez is also proprietor of the popular Datachick Twitter feed and often uses that outlet to post admittedly snarky comments about the world of information management.

Datachick gives ‘big data’ a verbal beat down at Enterprise Data World

I did start my presentation by saying:

By the way, every single one of these rants is totally unfair, cherry picked and irreverent.  I know. It’s shocking.

I will be blogging the entire rant over on Dataversity.net and will post here when it goes live.

Update:

• My blog post with the Big Data rant is now up on Dataversity.
• John Biderman has blogged there about his NoSQL Epiphany.
• Paul Williams coved this rant in is Overview of Enterprise Data World 2012.

I should also mention, to those of you snickering, that I am currently drafting a similar rant for the RDBMS technology/naming/terminology set.  It will also be full of snark.  Shocking, I know.

Monte Carlo-ing Your Eventual Consistency Bets

One of the features of not-only-SQL (NoSQL) data storage systems is the concept of eventual consistency (via Wikipedia):

Eventual Consistency… means that given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system and all the replicas will be consistent.

For those of us coming from a transactional system point of view, eventual consistency can be mind-boggling at first. Thinking about data being presented in an inconsistent manner is usually seen as a data quality failure — something to be avoided. But in non-transactional systems it’s worth the trade-off for speed and scalability. Think about your Facebook page for a minute: how bad would it be if one of your friend’s updates was not visible to you at the same time it was visible to someone else, but eventually you’d be able to see that update?

Paul Cannon has a great write up on using tools to estimate your eventual consistency with Cassandra:

"The best part is that they also provided the world with an interactive demo, which lets you fiddle with N, R, and W, as well as parameters defining your system’s read and write latency distributions, and gives you a nice graph showing what you can expect in terms of consistent reads after a given time.

See the interactive demo here.

This terrific tool actually runs thousands of Monte Carlo simulations per data point (turns out the math to create a full, precise formulaic solution was too hairy) to give a very reliable approximation of consistency for a range of times after a write."

Being able to plan your architecture to best fit the business need is what is important, not necessarily data purity at the cost of speed or reliability.  Again, that sounds weird to a profession that has focused on fighting to keep data integrity on the radar of management, but the best design decisions are made balancing cost, benefit and risk.  Those of us in the data world to understand that eventually consistent is often the best solution.  Even if it feels weird.

Having tools that help us understand how to best architect the trade-offs is the first step in delivering the right data consistency for what the business needs.

Related articles

• Eventually Consistent (queue.acm.org)