A SQL DBA tries NoSQL – Part 1 – A Learning Plan

By | February 1, 2017

I’m a relational DBA looking to get a grasp of some of the NoSQL database technologies knocking about.

There are so many implementations that it’s hard to know where to start. MongoDB or Neo4J or Cassandra? I don’t want to fall down the rabbit hole of of one particular technology only to find that it’s solely used by the developer’s mother, or that it falls by the wayside next year (RethinkDB *)

First thing’s first – what are the most popular new technologies out there? There’s a lot of possible metrics for this, DB-Engines is as good as any when we’re thinking of usefulness to our careers.

The good news for me is that my main expertise is in the Top Three. Well, I’m not interested in Relational DBMS for this purpose, so I’ve decided to exclude those and focus on the top-of-the-pops for some of the other categories presented: Document Store, Wide Column Store, Key-Value Store, Search Engine, Graph DBMS.

In terms of categories, I’m ignoring Time-Series (InfluxDB), Content Store (Jackrabbit), RDF (Jena), Object-Oriented (DB4o). Why? Because their top DB is way down the list, well-outside the top 20. I could also ignore Graph DBs because it’s #1 is outside the top 20 (actually it’s 21 at time of writing). But I’m not a total empty vessel – an employer once asked me to take a look at some alternative graph offerings. That’s good enough for me to pull them into my list – one commercial enterprise I know was thinking about them!

Here is the DB-Engines top 30, excluding Relational Engines. There’s no easy way to filter out “all but one” using their site, so you’re welcome.

For my own personal “to-do” list of databases to take a look at, I’m going to add a few that are way down the list, because I’d like to have at least two per “type”, and for some – they’ve come up in work conversation, albeit with developers moon-lighting in mobile apps – again, a little familiarity gives me some notion that they are being used at least by someone in the city in which I’m likely to work.  So here’s my target list of technologies to get familiar with:

As it happens, I’ve worked extensively with one of these, but the others are fresh and new. Now, when I say I worked extensively with a technology – I didn’t do much in the way of hands-on administration or scripting. I worked on export and transformation of data from an RDBMS, providing large data-sets to another team who specialized in ingesting the data into the non-relational technology. I had to talk with those guys, trouble-shoot our interfaces, work late and joke around with them, good times.

I’d never seen the technology so I approached it the way most do, I guess. I carved out some time to download the software and work through some tutorials on installation, maintenance, import of data, and usage of same. That was enough for me to:

  • maintain a shared solution for the secure and stable flow of data from RDBMS to non-RDBMS system
  • decipher the complaints of the developers when half the data goes “missing in transit”
  • bring coffee and sympathy to the non-RDBMS admin when his replication…ahem..doesn’t


That’s the level I want to approach with my target list. I’m looking forward to playing with new DB toys, but I don’t have time to mess about with thirteen technologies. I’ll get my hands dirty with MongoDB, Cassandra, Redis, ElasticSearch and Neo4J.
For the rest, I’ll browse a few articles. Then set myself up as a consultant (joking).

So there’s a learning plan. But before I actually dive into one of these things, there’s something I need to take care of. “Document”, “Wide Column”, “Graph”, “Search”, “Key-Value” – can I define the main characteristics and differences between each of these terms? Well, yes, kind-of. Hey, I’ve picked up a few things over the years. But then again, no – they haven’t put food on my table, so I’m not exactly on firm ground here.

So I’m starting with a basic overview, in the next post in this series.

(*) A note on my reference to ReThinkDB. I don’t mean it as a slant on the technology. The link in the first paragraph is to one of the most honest and illuminating articles I’ve read on a group of people trying to make something really good.

One thought on “A SQL DBA tries NoSQL – Part 1 – A Learning Plan

  1. Pingback: A SQL DBA tries NoSQL – Part 3 – Redis (Key-Value) – Database Diaries

Leave a Reply

Your email address will not be published. Required fields are marked *