Voice of the DBA

Tag: NoSQL

  • The Relational Database is the Default

    It seems that I regularly meet people in the SQL community that are asked about moving their datastore to a NoSQL type of database. In a mature system, that might be a conversation worth having, especially if there are issues with handling the workload. I doubt there are many type of workloads that I would think are worth moving, but perhaps some exist. However, the discussion about moving is one you can have, given your understanding of the deficiencies you see in your datastore.

    Often I often find is a different story for new applications.  Often I hear about developers becoming enamored with a datastore, a simpler one than SQL Server or some other RDBMS, and look to MongoDB, Cassandra, Hadoop, Neo4J, etc. as the shiny, new, exciting choice. They think NoSQL offers an easier way to build their application, where they can throw and grab JSON through an API, while changing their minds on the ways in which they need to handle data.

    They approach a new application like a startup would, using some exciting technology that has just proven to be successful by some hot company in the news. They look forward to developing an application that other developers will be jealous of next year. Or they just want to use something new that’s being written about on blogs and spoken about at conferences. Or they just want to do something more interesting on the next project. All these might be great approaches, and certainly are ways that make one’s job more engaging.

    However. Just as this piece notes, choosing a new datastore because it’s new and exciting, and not because it fits the data model is a mistake. The data model matters, often because this is the permanent output of your software application. The data will live on and needs to meet current and future needs, separate from the amazing Node.JS framework of the week that your users love. Actually, users don’t love your framework. They love your work. Whether it’s MVC, Angular, Django, or Dapper, most clients could care less. Any language/framework/platform can build an application that works well for clients. Your application just has to work.

    Relational databases work really, really, really well. They handle most problem domains well, with protection against common consistency errors, and they have plenty of features that help you build a solid data model. There are tips and tricks to migrate your schema to some new form if you need to. However, if you need to migrate your schema every few days, you haven’t really thought about the schema. As the article notes, you need a schema. On read, on write, or both, you’re not getting away with ignoring schema.

    And by the way, if you keep your schema in Python or C# or some other language, you’re likely creating a set of “legacy code” that will haunt you for years and is much harder to manage than database schema migrations. Maybe it feels less risky, but it’s probably way less fun to work on.

    Databases are a pain to work with. I get that. It’s so much more cumbersome than refactoring C# classes on the fly. Databases have a different job, and they do it well. If you have a good reason to choose some other datastore that’s related to your problem domain and data model, then go ahead and choose something else. If you don’t, then use SQL Server (or PostgreSQL, Oracle, etc.). Most of you won’t, so just stick with relational databases. You might not thank me, but your organization and future developers will.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • This Made Me Laugh: SQL v NoSQL

    It’s a humorous history lesson on SQL (and product promotion), but it opens like this:

    battle

    SQL awakens to fight the dark forces of NoSQL

    From there it looks at the beginnings of SQL and the growth of NoSQL, going through a few sections, like

    newhope

    Part 1: A New Hope

    and

    strike

    Part 2: NoSQL Strikes Back

    before moving to

    return

    Part 3: Return of the SQL

    They finish with the idea that SQL is the most important, and common, tool for data analysis. In this era of Python and R, many may disagree, but I think they’re overall right.

    Perhaps this last part proves that?

    yoda

    Master Data Scientist Yoda

    It’s an interesting read, and I may have to watch some Star Wars this weekend.

  • The Full Court CosmosDB Press

    This year at the PASS Summit, Dr. Rimma Nehme (b|t) will give another keynote address. She has spoken at a number of previous Summits, and is a very popular speaker. This time her topic is CosmosDB, which is where she’s been working at Microsoft for some time. I was lucky enough to see Dr. Nehme at Build 2017 talk some CosmosDB, and I’m sure she’s got more to say this now.

    Actually, I’ve been a bit surprised by all of the writing about CosmosDB that I see taking place. Perhaps it’s that the CosmosDB Twitter account is very active, but it seems that so many .NET developers and other non-SQL Server professionals are talking about how they are building projects and platforms on CosmosDB. I follow plenty of SQL people, but it seems there is a tremendous amount of activity on CosmosDB (and R/Data Science), more than I see with plain old SQL Server (POSQL?).

    When I first saw DocumentDB, the forerunner of CosmosDB, I thought it was a good platform for some workloads. Certainly the heavy write a document, read the same thing of the XBOX profiles and some of their games seems like a good use of the technology. When they added MongoDB, I was slightly more interested, but still not a lot. I really haven’t seen many workloads that seem to exceed what SQL Server can do in a relational platform. At least, not if you write efficient code and buy enough hardware. The change to CosmosDB, however, was really interesting. Allowing graph APIs, key values, and documents in one service is something I am sure is attractive to many developers. Especially the heavy use of JSON, which seems to be a format many developers prefer over datasets.

    I know Microsoft would like more people to use CosmosDB as it’s completely a PaaS, pay-as-you-go service, and that could easily increase their revenue if they can get many people using the product. The have invested quite a bit into the platform, with latency guarantees, multiple consistency models, and plenty of scalability. It’s certainly on my list of topics to dig more into how CosmosDB works and where it might be applicable to solving data problems.

    I think there are applications where a CosmosDB datastore will work well, but I wonder if this is more of just a front end, gather data service, that will require additional databases behind the service were data can be combined and aggregated for other reporting. I don’t know that querying your graph tables alongside key-values and documents will be as easy as it might be in a relational system, but hopefully we’ll see some people (perhaps me) experimenting and reporting back on the complexities and advantages of such a datastore.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Losing Rows

    There has been a lot of hype in the last 3-4 years around NoSQL databases. Note that NoSQL isn’t Not SQL, but rather Not Only SQL, implying that the SQL language still has a place here. In fact, a number of companies that make NoSQL products have layered a SQL-like interpreter or interface on their products to allow familiar SQL language querying.

    One of the big reasons companies look at NoSQL is that the various types of databases have lent themselves to scaling easier than traditional RDBMS systems. In the CAP Theorem, these systems tend to be more in the AP range, sacrificing some consistency for scale and performance. That seems crazy to RDBMS people, but if you really think about your application, consistency that is delayed on the order of seconds or less isn’t that bad in most applications. Even seconds might not matter in many reporting scenarios.

    The thing is, databases aren’t perfect, and that goes for NoSQL systems. I ran across a post where MongoDB sometimes loses consistency within a single node. Now, this isn’t within a single document, so changes there are transactionally handled well (as we RDBMS people think of them), but for a query, you could have rows drop out and reappear according to some criteria, sometimes within a few minutes or seconds of each query.

    That is disturbing. In fact, I’d be terrified of this, mostly because I’d spend a lot of time trying to explain why and getting yelled out. Do you know how many times I’ve had business people run a report and then someone else run the report a minute later and try to compare things? If I had whole documents dropping out of one or the other, that would be maddening.

    Now, there are ways to fix this in a MongoDB database, and I’m not disparaging MongoDB over this. It’s a fine system and there are some good applications built on MongoDB that work well. There are some fine applications running on Neo4j, and on Couchbase, and other NoSQL systems. Some of these database work better than an RDBMS in managing particular workloads and problem domains. Some applications and workloads would do well with a NoSQL or a traditional relational database.

    The important thing to understand is how your system works. Your organization should understand what allows a database to scale and what doesn’t, what things limit HA/DR capabilities, which items might impact consistency across nodes or systems. In the SQL Server world, if you use Availability Groups, you should certainly understand what consistency means for the different databases in the same AG.

    NoSQL databases aren’t better or worse than relational databases by themselves. Finding a good fit for a particular database platform and your application requires some knowledge and planning. Ensuring a successful application is often less about the technology, and more about the people that architect and code the solution. Worry more about the latter than the former and you should be successful at building software.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.7MB) podcast or subscribe to the feed at iTunes and Mevio .