Author: way0utwest

  • Moving from NoSQL to an RDBMS

    I saw this link about a company that moved (Goodbye, CouchDB) from a NoSQL database (CouchDB) to a relational one (MySQL) because of some problems they experienced. Sauce Labs provides testing services in the cloud for developers using the Selenium framework.

    The first link is a blog post that talks about some of the things they initially liked about CouchDB and then the problems they experienced. Their move to MySQL showed better performance and stability over the CouchDB they were using. It’s an interesting read, not too long, and it seems well thought out.

    I think that this isn’t a knock on NoSQL databases, and I do think there are problem sets they are well suited to solve. I don’t know that I think because your developers don’t like SQL is a good reason, but there are problems with scale and size that are better handled with some NoSQL solutions. I’m an RDBMS person, but I don’t expect everyone to be that way.

    However this does say a few things about NoSQL maturity. Many of these products have gotten popular quickly, with some success stories, but that doesn’t meant they are necessarily ready for your application unless you have staff that have lots of experience with the tools. These are young platforms, they have problems inside the code, especially if you deviate from the way the authors used the platform, and you may have issues.

    Experience matters. Just as many people have issues with SQL Server scaling when they don’t know how to build a good data model or write efficient queries, I suspect that picking a NoSQL database because it’s cool, or seems easy to implement, or it worked well at some other company. I would almost always suggest that you stick with platforms that your staff is very experienced with, since they are likely going to have issues at scale on every platform, and their experience can make a difference.

    Note that this assumes you have good people. Just because you have a DBA with 10 years of experience doesn’t mean he or she is necessarily good. They could easily have 1 year of experience 10 times. You want people that have worked on a variety of systems in different areas.

  • Hustle

    As long as we have people with this attitude, we are going places:

    “If you hustle – all out, fully hustle – and you succeed, then you gain the satisfaction of a job well done. If you hustle and fail, you never have to worry about what might have been if you’d given everything.

    If you slack off, you might get lucky and still succeed, but there’s little satisfaction other than the temporary thrill of escaping with your life. If you slack off and fail, you have to live forever with not knowing what you were truly capable of.”

    From Todd Henry (via Tim Mitchell)

  • What is Big Data?

    big data visualization
    Big Data visualization of “water” being spoken to a child.

    This industry is full of some very smart people. We tend to get some very strong opinions, and some rather snarky comments at times about the way the technologies that we use are presented. Karen Lopez (@datachick | blog) recently made headlines with her comments on big data. “What the heck kind of definition is that?” she asked when looking at the Wikipedia definition of Big Data. If “big data” is data that is “awkward to work with” then I know lots of people that have had to deal with big data anytime they had to work with outer joins.

    While I’m not sure big data is well defined, I do know that there are large data sets which can overwhelm relational databases, both in scale and the speed at which the data is collected. Microsoft added StreamInsight to SQL Server to help deal with the speed problem, but I’m not sure that relational databases can handle the size issues at the same time. Some large computing and analysis problems don’t lend themselves well to non-relational soluttions, and other technologies are needed.

    I do agree with Karen that big data, whatever that means to you, is not really in conflict with relational databases like SQL Server. There are lots of data sets that work well inside of a relational database, especially when you have built a solid data model and referential integrity. Many problems with relational databases come about because of poor code added to the platform, not a problem with relational platforms in general.

    Relational database systems are not “obsolete”, despite what some vendors of other databases think. I have complete confidence that SQL Server as a relational platform will be used for years to come.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • Self Service SQL

    self service help and advice
    Self service isn’t always better.

    I was looking over the Microsoft Virtual Academy recently, and went through one of the courses they have on SQL Server for the private cloud. I was curious how this solution is being both implemented and presented. It was interesting, and I learned a few things, including the fact that Microsoft is looking to build self-service into this idea of a private cloud. Users can build a virtual machine from a template, with Windows, SQL Server, and more already setup. They receive a SQL Server they can use as long as they like, and can delete it when they are done with it.

    There are a few problems here, and they are similar problems that we’ve seen in the past as we pushed out more capabilities to individual users. The first one is that allowing people to create their own SQL Server instances can be problematic as they don’t do a good job of setting up maintenance. SQL Server is easy to set up, but a little more complicated to manage over time. I suppose templates could potentially have backups and maintenance built in, but if you do this with any scale, you might end up with storage and space issues as well.  There’s only so much automation can do with limited resources, and I could see this ending up causing more infrastructure problems over time for IT staffs.

    The second issue is that people just don’t manage data well. How many people would delete a virtual machine without a final backup? How many people would create machines, load data, and then forget they had data out there? Apart from security concerns, there are likely to be efficiency concerns. How many people might create their own database server for financial data, even though the person in the next office might have already done the same thing? How many reconciliation problems will be brought to the DBA when people load different data sets into their servers, run reports, and then try to compare the results?

    I think IT self-service is a good idea in many ways, but it’s not the answer for all problems, and without some controls, I can see it easily causing as many issues as it solves.

    Steve Jones


    The Voice of the DBA Podcasts

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