Author: way0utwest

  • The New Data Warehouse Choice

    I was listening to the SQL Data Partners podcast the other day with BI expert, Tim Mitchell, and the opening question was “Is the on-premises Data Warehouse dead?” Tim is a friend, so I tuned in knowing he has some good thoughts on the topic. It’s an interesting listen, and one you might enjoy if you’re at all interested in data warehousing and related topics. Spoiler alert, Tim says no, on-premise isn’t dead, but he does point out some interesting things about the Azure SQL Data Warehouse (ASDW) and similar offerings.

    One of the more interesting comments Tim made was about a health care company he worked for. They had an end of month process that heavily taxed their systems. If they didn’t need that peak level of processing, Tim noted that the cost of their large data warehouse architecture would be that halved. That need to scale up dramatically can be a big savings in moving to a cloud based system, where you can pay for a much lower level of performance most of the time and increase your scale at particular times.

    I know this is feasible as I worked with a similar situation. My employer purchased a very large system for our end of month and end of quarter closing load. Fortunately, we had an AIX machine that contained its own hypervisor. At the time (2001), we purchased a 32 processor server, with the idea that only 18 CPUs (and a slice of RAM) were running our financial systems most of the month. We had QA, development, and other guests on the same hardware. During the month closing, we would shut down some VMs and dedicate most of the processors to the finance system for a few days to handle the load. What’s more, the IBM machine actually contained additional CPUs that we could “rent” from IBM for a few hours if we really needed them.

    That’s what data warehouses in the cloud can do for you. Certainly the decision to move to a cloud architecture is more complex than just having the scale up power of ASDW or Amazon’s Redshift. The ability to load into the system, the development challenges, the tax implications, and more will impact the decision. I think the workload characteristics are also important. If you don’t have a highly variable, or large peak, workload, then the cloud might make less sense. If you don’t have any sort of data center, then maybe the cloud makes more sense.

    I do think, however, that the decision to implement a new data warehouse isn’t a simple one, and the cloud is a viable choice. The platforms are becoming more capable all the time, with more tools and scale options, as well as better performance guarantees. Many of the tools used to analyze data in a warehouse are more important than the underlying platform, with Excel, Tableau, Power BI, and more easily connecting to any data warehouse platform, in the cloud or on-premise.

    This means that we will end up managing more disparate systems over time, especially in larger organizations where some groups will adopt cloud systems while others stick with on-premise installations. Certainly if you are a person that works with a data warehouse, you might want to build a small POC on Azure SQL Data Warehouse and see what you think about its capabilities. At least then you’ll be able to add some educated and intelligent thoughts to the discussion when the question comes up inside your organization.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Getting Started with Database DevOps, DLM, and New Tools

    Next Tuesday is the next installment of our DLM series from Redgate. I’m off the hook, with Grant and Arneh showing off Git, Team City, and Octopus Deploy as the main tools. Register today and see how you can get started.

    We’ve been running this series for a year, with a focus on showing different tools being used to deploy database changes. Of course, we do showcase some Redgate tools from the Toolbelt, but the idea is to integrate with various other common development tools.

    68_dlm dashboard red wfillIf you’re looking for an easy way to get started, consider downloading and trying DLM Dashboard, a free tool to audit and monitor your database schemas.

    If you’ve missed any, you can see these combinations of Version Control, CI, and Release tools:

      Version Control Continuous Integration/Build Release Management/Deployment
    Webinar link Git TFS Build in VSTS Microsoft Release Management
    Webinar link TFSVC TeamCity Octopus Deploy
    Webinar link TFSVC Jenkins Octopus Deploy
    Webinar link Subversion (SVN) TeamCity Octopus Deploy
    Webinar link TFSVC TFS Build in VSTS Microsoft Release Management

    Feel free to watch any of these, or come to the next webinar and ask questions live. There are more resources in our DLM library.

    DLM really can help smooth your development and deployment process, reducing mistakes, and allowing you to deliver enhancements to customers faster.

  • 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 .

  • Thanks, Karla

    I heard the news this week, and I’m still sad. Karla Landrum is leaving PASS after five years of acting as the Community Evangelist.

    Thank you, Karla, for all you’ve done.

    In the last five years, we’ve seen tremendous growth in the SQL Saturday franchise, as well as other chapters. Most of that has to do with Karla’s work ethic and success in supporting even organizers all over the globe.

    When Andy Warren and I transferred the SQL Saturday franchise to PASS, we were hoping that the organization would provide a bit more support and help in organizing events. Our expectations were wildly exceeded with tremendous growth in the number of events. In 2010, when we transferred the responsibility, there had been 26 events held. That was across the span from Oct 2007 to Mar 2010.

    2016-07-13 10_14_39-Book1 - Excel

     

    That tremendous growth in 2011-2015 is Karla. Even this year is on pace to exceed last year’s event total.

    All of you that have attended, spoken at, or learned something from a SQL Saturday should send a thank you to Karla for your tireless advocacy and help in ensuring that many of us could get free training almost every weekend somewhere in the world.

    Karla will be missed by many of us, and I just wanted to publicly thank her and let her know how much I’ve enjoyed working with her over the years.

    I hope PASS can find someone that can continue her work in growing our SQL Server community.