Voice of the DBA

Category: Editorial

  • Graphing Performance

    We have a lot of different database platforms to choose from when building software. Most of us reading this are SQL Server users, and likely relationally biased. However, key-value stores, document databases, graph databases, and more are out there. If you work with developers that embrace change and new options, likely you’ve been asked about implementing some sort of NoSQL database instead of SQL Server for some project. Maybe you’ve even been asked to migrate away from SQL Server to an Open Source (OSS) NoSQL platform, with the lack of software cost being a factor.

    I do think that there are some domains of problems that relational systems don’t handle well. Certainly at scales (data volume or rate), there are better ways to deal with some data sets in a less structured and tightly coupled way. We see that in the large scale web companies like Google, Twitter, Facebook, etc. If these companies had tried to build their entire system on a RDBMS platform, they would have struggled to grow, and maybe not even reached the size they are.

    I’ve been reading and playing with the new graph capabilities of SQL Server 2017, trying to determine what I think of the concepts. Certainly large scale many-many relationships don’t seem to be a strength of relational databases and I’ve thought there are certain types of queries or data models that might be better handled by a graph database.

    Then I ran across this report from a few researchers that examine how graph database compare to relational ones. After all, we’ve grown accustomed to using RDBMSs in many environments and situations. What better way to evaluate the performance of a specialized database than compare its performance in the problem domain its designed to solve to that of a general database platform.

    The results are a little surprising. Even with a sub-optimal query language, I would have expected the graph database to perform better. Instead, relational seems to handle the reference graph workload better. Raw performance isn’t everything. Ease of development and ability to scale are important. There may be other considerations in your system as well, but I did find this to be an interesting paper.

    We will see how the world of specialized databases handles real world workloads over time as more companies use them, but for now, I’d be skeptical of replacing an existing, working RDBMS with something unproven. I’d need to see a good POC that shows quite a bit of improvement across a variety of metrics, not just scalability.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Career Bucket List

    The Bucket List is a fun movie to watch, where two old men get a second chance at life and engage in some activities they’ve always wanted to enjoy. The idea of a bucket list isn’t new, and there are plenty of sites that can help you manage one. Brent Ozar has one on his site that he calls his Epic Life Quest, and I’ve enjoyed watching him tick off items. I got the idea of my own list nearly 20 years ago after hearing Ted Lesonis on the radio. He had a list of 101 things to tackled in life. Since he sold his stake in AOL, he’s had the resources to work on them. I have one, along with my wife, and we’ve worked through a few items over the years, though we were talking recently we need to revisit the list and perhaps revise things.
    Why revise a bucket list? One of the things I’ve learned over time is that I change and the values, goals, and desires I once had will also change. The things I’ve had put on a list at 20 years old would have included owning a Ferrari, a Porsche, and a Lamborghini. At 40+, having owned a Porsche, the other things seem a little silly and vain, not to mention very impractical. At this point in my life, there are other things I find more interesting and captivating. The bucket list of today would be more experience based and likely contain more volunteer oriented goals.
    I think my career has really changed as well, and as I move towards retirement, I don’t know if there are many more goals for me in this area.  However, if I think back, I know I’d have had lots of them when I were younger. There are a few things I’d still like to accomplish, and hopefully I’ll find some time to work on them. For now, I wanted to ask you about your career.
    What’s your career bucket list? Is there something you’d want to accomplish? Build some software? Work in an industry? Get a particular job, position, or work in a location? Maybe you’d like to become an advanced techie on some platform or using some technology. There might even be a goal you have to achieve some recognition for your skills.
    This is a tough question to spring on you in an editorial, but leave a comment if something comes to mind. If it does, maybe you want to jot some notes down that might help you move towards that goal. Even if nothing strikes you, perhaps you want to bookmark this piece and spend some time in the coming weeks thinking about your career. Goals are always good, and they can help drive us in a direction that may ultimately provide some meaning or satisfaction that is lacking.
    Steve Jones

    The Voice of the DBA Podcast

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

  • The Downsides of AI

    I remember reading about AI as a college student, and I always wondered if we’d get computing algorithms that might actually make better decisions than informed humans. As my tech career grew, I saw the advancement in systems, like Deep Blue, that showed we could build better systems that might beat humans at their own games. The recent success of AlphaGo makes me wonder what the next challenge will be?

    Certainly machine learning (ML) and AI-like systems are becoming quite popular in business these days. More and more companies are trying to find ways to use these computer science tools to improve their organizations capabilities. Whether these techniques will continue to be popular remains to be seen, but in the short term, all the efforts of companies like Microsoft and Amazon will get many companies to try to build intelligent systems.

    There is a lot of data being used to fuel these AI and ML applications, so it’s a natural fit that many data professionals will want to be involved. It’s a complex area, where lots of data is used to conduct lots and lots of experiments. That type of work my not suit many of you, but give it a try on one of these platforms and see what you think. Perhaps this is work you will enjoy. However, even if you enjoy the work and become good at it, there’s potentially some issue that may impact the use of these systems.

    We don’t know how most of the applications actually work. That’s because we haven’t programmed them. In some sense, many of these systems learn from data, and with a little guidance, but there isn’t necessarily a debug log that might explain all the actions. That is perhaps the dark secret of AI. We don’t really understand what’s going on.

    The article linked above looks at autonomous cars, which a number of companies are researching and building. One of the issues with the complex system(s) that runs the car is that we don’t necessarily know how it works. This might not bother technical people, but it certainly does bother many people. When there is a problem, and there will be a problem since there are always failures, how do we determine what went wrong and make it better? Add more data and retrain the system? I’m not sure that is a solution that most people will accept.

    Ultimately I think some of the research and work on AI needs to focus on allowing the model to output a set of data on what data is being weighed and the impact on the flow of information that leads to a decision. I know this is a tremendous amount of data, but it is probably the type of analysis that is needed for accountability in these systems. After all, it’s not just cars where this matters. Imagine that your have an AI system that cuts off all AC in the summer, or decides not to order enough resources for a busy time period. How do we explain to management that “the system just decided” on that course of action? I really think we need better tools for analyzing these models.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Use More Pull Requests

    I noticed a short while back that Books Online is on github. You can fork the code and make corrections to pages and then submit a pull request. This is the model that many OSS projects use, including the amazing DBATools project. That one I really like, and if I was better at PowerShell, I’d contribute. If you’re a PoSh whiz, I’d urge you to contribute.

    A few years ago I saw a lot of complaints about the SQL Saturday site, and over the years I’ve also seen a number of complaints about the Pass Summit sites, and the registration process. At one point there was a debate over whether PASS should build a registration system or continue to pay for the service. To me, this was a perfect place to start a project, maybe with a few volunteers, and then crowdsource enhancements and improvements. Get help from the members of this technical community, after all, this is the way most of us make a living.

    If Microsoft can get help from outside, I’d expect other organizations could as well. Certainly PASS has limited resources, and this is a great way to perhaps get new ideas, innovate, and grow their system. There will be some friction and loss in reviewing changes, but I’d expect that the overall gain would come from the greater number of people contributing to the software.

    We’ve kicked this around for SQLServerCentral and Database Weekly, and I am hoping to start getting help in enhancing my own site from its community at some point. There are certainly challenges and difficulties in integrating code from lots of sources. DevOps makes this easier, with more automation to evaluate and test code before a human needs to review it. However, DevOps has its own challenges, with extending the culture and process to others, and finding those individuals that want to contribute and buy into the philosophy, not to mention maintaining code quality and standards. However, I hope that you consider using pull requests and getting help from others in your own organization or project.

    Steve Jones

    The Voice of the DBA Podcast

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