Voice of the DBA

Category: Editorial

  • The Consistency Debate

    How consistent do your systems really need to be?

    One of the questions I constantly see asked about on SQLServerCentral is how can you scale out the database. How can you easily keep multiple copes if your data in sync with one another on different servers, and allow clients to read from any of those servers. The Always On features in SQL Server 2012 will allow readable secondaries, something that wasn’t possible in database mirroring, giving you up to date reads of your data, which is in sync with your primary database.

    However is that really necessary for many applications? The largest applications in the world, Google’s search engine, Facebook, and more, are turning to NoSQL databases and storage to handle their loads. I ran across a nice piece on Ars Technica that talks about how these companies handle the large data storage challenges they have. The one very interesting thing in the piece is the way the consistency challenges are talked about. These phrases, “designed with less concern for consistency of data across the system”, “jobs in progress will still hit stale data”, and “(it) is entirely okay with serving up stale data”, would scare most DBAs I know.

    But should they? For some applications, it is important that we maintain consistency across nodes. The classic bank account example requires that a withdrawal and a deposit between accounts are totally committed or rolled back to ensure the proper balances. However that doesn’t mean that every node in the banking system knows your balance. Only those times when a transaction affects the balance, do we need to be sure of the actual value. Deposits are sometimes not reflected immediately on another node, say a remote ATM. Withdrawals are sometimes approved, even with modern checking machines, when there are insufficient funds, resulting in bounced checks.

    In many of our applications, we are told we need consistency, but I think that’s a goal. It’s like 100% uptime, which is rarely met, and almost never funded. Think about a report. A User might run the report, assuming that the data is accurate, and it may be, but 14ms later it might not be because of changes. If the report had been run 14ms earlier, it might have missed other changes. Most people understand that, even if they are asking for consistent behavior of the system.

    With that in mind, should we be looking for more distributed architectures in our applications? I think that replication and service broker, both excellent techniques for scaling out, should become a more regular tool for our applications, and should receive more attention in future versions of SQL Server. We are only acquiring more and more data, and while hardware continues to get more powerful, we are outpacing the developments in storage bandwidth. We should start thinking about how to anticipate future challenges in application load, not reacting to them later.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Great Developers

     

    Are you on track to be a great developer?

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Old, but stable

    SQL Server 2000 was a great platform

    I had another poll planned for today, but then I saw Paul Randal’s blog on SQL Server 2000 and it inspired me. I spent many years working on SQL Server 2000 systems, and I liked the platform. It very very stable, reliable, and effective for the companies in which I worked. This was pre-cool SQL Server logo, pre-SSRS, pre-64-bit hardware. SQL Server 2000 was the release that I spent the most time working on to that point in my career.

    Today we have an easy poll, and I’d love to get your answer, and I’m sure Paul would as well, so feel free to put your answer here and on his blog:

    Are you still running SQL Server 2000 in production and why?

    It’s 2012, we have now had 4 releases of SQL Server since SQL Server 2000, but I know there are still plenty of SQL Server 2000 instances out there. It’s not being actively supported or patched, but many companies still continue to use it. Why?

    The reasons often come down to money. I know a few friends that have SQL Server 2000 instances running some proprietary software and their companies do not want to spend the money on an upgrade. With a stable database platform that doesn’t have issues, would you? Is it worth upgrading to the latest version of the platform when what you have works?

    I think you upgrade when you see an advantage to doing so. If that means you want readable secondaries that provide HA, DR, and reporting, then you are probably planning on a SQL Server 2012 upgrade now. If you have to run a key card system that checks people in and out of a building, SQL Server 6.5 probably works fine.

    Let us know today if you still run SQL Server 2000, and how it’s working for you.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Scaling Out

    Scaling Out
    One way to scale out

    When I first heard about Service Broker coming in SQL Server 2005, I knew it would be slow to gain traction, and many people would not see the power of guaranteed messaging. However I thought over the next 3-4 years it would catch on as we companies looked to scale out their databases to multiple physical servers.

    That hasn’t really happened, and it seems Service Broker has not been widely adopted by many database developers. It surprises me since it seems like a fantastic way to move data between servers. I’m not sure if too many data professionals think a message means a substantial delay in the movement of data, or if they don’t trust the architecture, but there don’t seem to be many people using this feature in SQL Server.

    They should, however, and I saw a great writeup on scaling out SQL Server with Service Broker. It talks about ways in which you might think about improving your application’s performance, especially at larger scales, but implementing Service Broker as a part of your architecture. It has advantages over replication, and it makes sense to me that this could be an extremely flexible way to handle your peak loads.

    However it isn’t the solution to all problems. It has a steep learning curve, the tools have not advanced very far, and the documentation and descriptions can be confusing and incomplete. I had hoped that things would improve over time, but this feature seems to have been largely ignored. However Service Broker and messaging are great technologies, and I’d encourage you to spend some time learning about it, and look for places in your environment that it might solve scale problems.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.