Voice of the DBA

Category: Editorial

  • 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

  • Max Memory

    What's the most RAM you have in a server?

    Recently I upgraded the memory in my laptop. For a few hundred dollars, I went to 16GB of RAM, which means that I can more easily run Virtual Machines without a noticeable slowdown on my system. Combining that with an SSD as a second drive, and I have laptop that I think performs well.

    For servers, 16GB wouldn’t be much RAM. In fact, I heard from a friend recently who had enough RAM in one of his servers that my jaw dropped open a little.  I know hardware has advanced a lot in the last few years, but I wonder how much of that has filtered down to the average company.

    It’s time to brag a bit today, and let others drool over your SQL Server. Give us the answer to this poll question if you can.

    What’s the largest amount of RAM in one of your database instances?

    I’m looking for the biggest box you have, and then maybe you can let us know how it’s used, or how many people it supports, or some other metrics. Perhaps even tell us the database size, so we can guess what percentage is in cache.

    Let us know today just how much RAM you have and how proud you are of your large instances. I’ll say that 16GB is the largest server I have here at the ranch. The SQLServerCentral database servers have 24GB of RAM in their virtual machines.

    Steve Jones

    The Voice of the DBA Podcasts

  • DBA Concerns

    Security is everywhere, or is it?

    I ran across a survey of Oracle DBAs that examined their concerns about security that I found it very interesting. Considering how much data from companies and governments supposedly resides in Oracle databases, it’s shocking to see how large a percentage of the DBAs don’t know or understand what security measures are being used in some cases. It’s also surprising to see that so many of the threats these DBAs perceive are internal threats or problems with a lack of some sort of process.

    It makes me wonder if a survey of SQL Server DBAs would be any different.

    My guess is that it would not. SQL Server would have a good percentage of people that don’t encrypt data, a good percentage that don’t apply patches or don’t know what processes are being used to secure and protect data. I would expect that a lack of process, lack of priority from management, and other internal threats would be concerns as well.

    As DBAs, I think that the integrity of the data we deal with is paramount. We must comply to our own version of the ACID principles for databases by ensuring that data is secure, available, intact, and recoverable in the event of a disaster. If we cannot guarantee the safety of the data, we aren’t very good custodians.

    The best data professionals I know leave nothing to chance. They don’t depend on their own skills or memory. They implement a process everywhere they can, and automate these processes as much as possible to ensure they are followed. As you learn how your environment should function, use code to assure yourself that the processes are followed. Then use other tools available to verify those processes are actually running correctly.

    The best DBAs aren’t necessarily smarter, or more talented than anyone else. They’re often just more methodical and focused, ensuring that the work that needs to be done, gets done. Usually by coding the server to handle most things on its own.

    Steve Jones

    The Voice of the DBA Podcasts

  • Quality Over Timing

    Is quality job one?

    Is quality really the number one job of software developers? I think we’d all like this to be the case, but I suspect that in many companies it’s not. This piece is a few years old, and it talks about how quality has become more important at many large software vendors. Looking back across the five years since the article was written, do you agree?

    Whether you are a commercial software company, or building applications for internal use by a company, there are so many external pressures to finish or ship an application that quality becomes a second, or even third, tier goal. The need to have people begin using the software, with those last minute features added, means that quality gets cut in some areas.

    We build software with the best of intentions, and I understand that there must be a deadline for the software to start being used. However I think that the balance between finding a finishing point for a version of software and quality is leaning a bit too often towards the deadline taking priority.

    In my ideal world, we would pick a stopping point, and then ensure that the development and testing of everything in progress before the stopping point is completed. In other words, we can’t pick a ship date, but we can pick a design end date, and from there work through the proper build and test from that point forward to a well built piece of software.

    I don’t know if we’ll ever get to the point where the overall image of software is that it is mostly well built, but I can hope we do.

    Steve Jones

    The Voice of the DBA Podcasts