Voice of the DBA

Tag: NoSQL

  • NoSQL is Not the Answer

    The NoSQL Logo

    There’s a lot of talk and press around NoSQL databases, which are a class of systems that are different from relational databases (RDBMS). Most of us are familiar with the competitive RDBMS’s to SQL Server; systems like Oracle, DB/2, MySQL, PostgreSQL, and a few more. NoSQL systems are less well known, going by names like Cassandra, MongoDB, and the best known system used by Google, BigTable.

    It seems there are a lot of ranting and raving about which system is better, and even some comparisons that look at performance in different ways that we use systems. I found a SQL Server v MongoDB comparison recently. It seems to show that SQL Server lags way behind MongoDB in terms of simple insert, update, and select operations. I’m not sure it’s the best real world test, but it shows some interesting results.

    Those comparisons  are important, but ultimately we do a lot more than simply insert rows and select from basic small sets of data in many of our applications. I see many systems making use of complex queries with aggregations, multi-table joins, and complex sorting operations. These might work well in a NoSQL system, but they also might not. Who knows how well complex business transactions and reports will perform on these platforms. Someone will have to try and see if these systems can handle those needs.

    NoSQL is worth examining further and learning about. I would not be surprised to see some of the features, such as easier scale-out, coming to SQL Server in the next few years. However I’m certainly not ready to view NoSQL systems as any type of evolution of the RDBMS. I think it’s much more likely that NoSQL systems solve a certain domain of problems better than a row-oriented RDBMS, much like column-oriented databases seem to be much more efficient at working with some types of data warehouses.

    Steve Jones

    BTW, if you want to listen to a little NoSQL humor, check out this video. It’s Not Safe For Work (NSFW), so be sure that you have a properly configured “cone of silence” so as not to offend others.

    The Voice of the DBA Podcasts

  • NoSQL Basics

    Last year there was quite a bit of press devoted to the NOSQL movement, emphasizing the scalability and power of this class of databases. They have not been well known, but have been used to power some of the very well known Internet companies out there. Companies like Google, Facebook, and others are using NoSQL databases in places, achieving the scalability that many RDBMS’s have struggled to achieve without enormous costs.

    I ran across an article that talks about some of the basics of what is classified as a NOSQL database. It’s written more for managers, and it does a good job of warning them that NOSQL is not the “answer” to all your performance problems. It’s a piece of technology that fits in some places and in some situations.

    Should you care about NOSQL? I think you should, if for no other reason than some manager will ask you about it at some point. Or a developer will want to build an application using a NOSQL database. A flat “no” from the data group is counter-productive,  and is not appropriate. If you are going to rationally argue against a new technology, you should have some basic understanding of how it works, what problems it solves, and engage in a logical debate.

    There are lots of good NOSQL articles out there, and perhaps the first thing you should learn is that there are different types of technologies for solving different problems. Cassandra is not interchangeable with MongoDB, and Voldemort is different from the other two. None of them is a direct replacement for SQL Server (or another RDBMS), but they do work in different areas. If you’ve never seen the CAP triangle, take a look at it now.

    Many of you are data professionals, and SQL Server specialists, and that’s fine. That doesn’t mean you shouldn’t learn a little something about other technologies, and how they might compare and contrast with SQL Server. Here’s a nice basic article from SQL Server Master to get you started.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72127/)

    Podcasts:

  • Plan for Capacity

    In many applications, it seems that performance often falls off a cliff at some point because no one is planning for capacity increases. Everyone talks about the potential load on the system when it’s first being built. However since we often over-buy hardware, we rarely monitor the load until something goes wrong.

    I was reminded up this with a write-up from Simon Sabin recently that examined a lesson on capacity planning from FourSquare. Apparently FourSquare had some capacity issues with their MongoDB server. Despite the realization that they were growing and the addition of a second node to their database, they didn’t learn the lesson and didn’t add a third or fourth node until they were over capacity.

    Most of us don’t experience this type of hyper-growth in our systems. The majority of applications I’ve seen have undergone a quick growth in load at some point, but then leveled off to a steady, or slowly growing load on the system. However that doesn’t necessarily change the planning needed for growth. It just means that you need to grow your system at different times than if you were doubling in size every few months.

    A solid monitoring plan, and buy-in from management that you will periodically need to upgrade your servers, is necessary. Typically you will add storage over time, perhaps RAM, and potentially new CPUs or servers. You might not be able to exactly predict when you will have performance issues, but you can plan for issues. You can proactively let management know that space is running low, or that you may run into issues if data sets continue to grow in size.

    Funding is often hard to get, but by preparing people in advance that your database will need improvements over time, you are more likely to be able to respond quickly when there are performance issues.

    Steve Jones

  • MongoDB

    I found a comparison of MongoDB and SQL Server recently, from a C# MVP and a person that works with SQL Server regularly. It’s an interesting read, and on the surface, you might think that MongoDB is much better than SQL Server in terms of raw performance.

    That certainly might be the case, especially for large data loads. MongoDB has the ability to scale out widely, and that always can help with performance. Even in single server environments, I have no doubt that MondDB has less overhead, and likely requires less resources, so it can be faster.

    However it also lacks some of the robustness and security that comes with an ACID compliant systems. It’s entirely possible that you could lose work you think you have committed in a MongoDB system. Not likely, but possible.

    These are, however, very different products. SQL Server is designed to handle some domains, and some loads very well. MongoDB has other purposes and ideas in it’s design. They aren’t interchangeable in some loads, but for many simpler systems, like web site back ends, they might either work fine.

    I like SQL Server, and I think it offers a very rich, and well rounded environment on which to store and work with your data. I’m not sure how MondoDB would fair in some situations, especially those that involve lots of calculations and summarizing of data sets, but it does seem to be a very robust database system for managing documents and scaling widely across servers.

    It will be interesting to see in the future of NoSQL systems, like MongoDB, start to become more prevalent in those places where ACID compliance is not critical.