No Handwaving Away the DBA

  • Comments posted to this topic are about the item No Handwaving Away the DBA

  • At the moment there appears to be a number of schools of thought that are being misappropriated and misapplied in ways which are suggesting that important roles and duties are not going to be performed properly. Along with NoSQL, agile is one of these.

    Steve, you highlighted the NoSQL movement encouraging a "no DBA" duties/roles and agile can be misapplied to remove architecting, documentation, all testing but unit testing etc as well as attempting to circumvent DBAs.

    I know that the leaders of these movements believe that this not the right way to go but that many of the implementers on the ground have conveniently forgotten or avoided reading the small print. It is up to all of us to remain strong and speak up.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (5/8/2014)


    ....but that many of the implementers on the ground have conveniently forgotten or avoided reading the small print. .....

    Remember when companies were downsizing because a guru said so. Apparently, that guru said "Some companies need to downsize". Cant see the industry based on logic falling for the same style of mistake....

    There are also a number of people who will jump onto a NOSql bandwagon thinking that it means NoSQL ( Not Only SQL vs No SQL ). There will be enough companies out there that will go through the pain, until the next greatest thing is suggested.

  • In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.

    Oh, I'm sure that for many of us, development and operations are of the same mind and have a very symbiotic relationship to each other. The developer side of my mind has a conversation with operations while driving into work, and then operations has plenty to say back and the end of the day. Now if only I keep both sides in harmony. 🙂

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I do think NoSQL has a place in the world. There are domains of problems that I'm sure Riak, MongoDB, and others, solve in a more efficient way than SQL Server, Oracle, MySQL, and other relational systems. I'm not sure what they are, and to some extent, I haven't seen good guidance on where particular platforms excel.

    This might be a nice start:

    http://readwrite.com/2011/02/03/the-big-list-of-nosql-use-case[/url]

    One case I personally like that calls for a non-sql solution is a need for fast RBAR. With SQL Server, you either get pokey single row selects, inserts and updates, or nice and fast set oriented operations. What about fast RBAR?

    I do hold out hope that SQL Server 2014 might address this.

  • Obviously running ad-hoc queries against unstructured data is a use case for a NoSQL database, and MongoDB is good for that. This would include things like ecommerce shopping carts and other memcache type data. However, once the user clicks the final purchase button, then you want your order entry and fullfillment system running SQL Server.

    There are also cases where very large raw files are injested from external sources, but only some columns and a much smaller subset of records are operationally useful and worthy for ETL into a normalized relational database. However, there may still be a need to retain a complete history of all these files in some online queryable fashion for archival or exploratory purposes. The DBA would prefer not to use SQL Server as a dumping ground for that type of thing. So, Hadoop to the rescue.

    So, yes, are occasions where it's very useful to dump things on NoSQL. Find space for it on the rack and put it to work.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (5/8/2014)


    In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.

    Oh, I'm sure that for many of us, development and operations are of the same mind and have a very symbiotic relationship to each other. The developer side of my mind has a conversation with operations while driving into work, and then operations has plenty to say back and the end of the day. Now if only I keep both sides in harmony. 🙂

    I found that list to be a load of hot air e.g. Easier maintainability, administration and operations.

    Try maintaining a NoSQL database for a bitcoins exchange 😛

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I remember when fellow grad students (in 1993) looked down at me because I was focusing on RDBMS's, while they were all gaga for Object-Oriented DBMS's. Relational systems were so old school. The future was all OO, and I was wasting my time, they said.

    Still waiting for something that is truly better. Meanwhile, I'm very happy to work in a relational, SQL world.

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • "...if you think that switching to NoSQL will just let you hand-wave away all of the challenges of running a database, you are terribly misguided."

    But it seems increasingly there is the effect (if not necessarily the conscious effort) to 'hand-wave away the DBA' -- by moving to cloud-based SaaS, and by consuming web services (rather than making direct database calls) within Ajax-type applications.

    Without a doubt, competent DBAs will always be needed -- but the direct exposure developers have to them will likely decrease because of the evolution of application design and infrastructure.

  • It seems to me that Microsoft's increasingly aggressive licensing costs for SQL Server 2012 and, worse, 2014, are hastening the impetus to look at alternatives even among relational db vendors.

    It seems that the price was too good, the performance too predictable, and the operational support far too mature for too long. Now company executives are balking with sticker shock and looking for a place to hide while mourning their budgets.

    As a data architect, I feel Microsoft is nudging the bayonet in the backs of companies who walk the plank towards Open Source relational and non-relational stores. Good, bad, or indifferent, they will turn this migration into a stampede.

  • Google the "Hype Cycle".

    NOSQL is such a broad term that it is next to meaningless.

    Not all NOSQL solutions deliver "No single point of failure".

    BASE has made people realise how much they miss ACID. Eventually consistent doesn't really work.

    These systems emerged to satisfy a niche for companies operating at the bleeding edge. The inventors of the solutions were pretty clear on the use cases for what they had invented. They understood that NOSQL meant Not Only SQL and for the most part it seems that the systems were produced by craftsmen who needed a craftsmans tools.

    What appears to have happened is that journeymen think they need craftsmans tools and are building wobbly systems with them.

    Of all the NOSQL solutions I see graph databases as making the most sustained inroads into the space of the traditional RDBMS. I had a lot of fun with Neo4J. I genuinely do mean fun, no irony or sarcasm involved. Microsoft have a number of articles on their graph database code named Trinity.

    REDIS is a great key-value pair in-memory solution for web session management and anything transient.

    I can see from a developer perspective why document stores are currently popular. From an operational perspective I'm sceptical. For MongoDB I'd be looking at TokuMX [/url]as a replacement engine. As Mongo doesn't have a shared nothing architecture I'd probably look at Couchbase instead.

    RIAK is interesting, especially as it follows the Amazon Dynamo white paper. It's really worth reading the Amazon paper. It'll take you a few attempts to digest it but is worth it in the end. In a lot of cases front-end web development simply wants to retrieve an object by a key value and if that is all you want to do then virtually all the NOSQL solutions fulfill that brilliantly.

    Cassandra is one I keep looking at but am not sure I've fully grasped its potential.

    Hadoop has a large ecosystem and there is a huge amount of investment in it. I liked the idea of HIVE which effectively lets you use the MySQL dialect of SQL to query structured data in Hadoop.

    I believe that Stinger has the same design goals as Impala in terms of adding real-time SQL querying of the Hadoop core.

    The big challenge faced by data professionals is to identify the stuff that is merely a fad and the stuff that really will continue to engage after the fruit-fly attention span of early adopters has got bored with it.

  • I look at all of these as tools. And as a mechanic, a new tools may work in specialized ways, but I do not get rid of all my old tools. Hadoop/NOSQL/Cassandra, etc have specialized uses. Hadoop is great for loading all that unorganized data, unstructured data first, and then adding organization. But SQL is simple, efficient and great.

    The more you are prepared, the less you need it.

  • As for the article, the reference to the Oracle DBA was interesting. Every Oracle person I have met seems to suffer from an inferiority complex. When I mention I focus on the Microsoft BI stack, it is always how Oracle is so much better. Ok, if it was common knowledge that it was so much better, why do all of them feel like they need to defend it? Sorry, just ranting. Or are they still lost in the cursor world?

    The more you are prepared, the less you need it.

  • David.Poole (5/8/2014)


    Google the "Hype Cycle".

    NOSQL is such a broad term that it is next to meaningless.

    Not all NOSQL solutions deliver "No single point of failure".

    BASE has made people realise how much they miss ACID. Eventually consistent doesn't really work.

    Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.

  • Whats wrong with eventual consistency? Its not designed to be a drop in replacement for the 'C' in ACID right? Its more like the 'C' in CAP from what I remember.

    It seems that the "eventual" thing is a bit unreliable. It isn't guaranteed and people have started to notice.

Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic. Login to reply