SQLServerCentral Editorial

Fast Enough

,

Will RDBMS ever be fast enough? It's not likely, and this opinion piece notes that really any database won't be fast enough. Data volumes are exploding and the demands by users are increasing as new creative ideas abound. This means that we will constantly struggle to keep up with the workload demand. I agree with that part of the piece.

Where I start to disagree is with the idea that sticking with the traditional vendors of databases (Oracle, IBM, and Microsoft) is not a great idea. Even if these vendors adopt new technologies that are being put forth by disruptive startups, the author seems to think that we would be better off adopting some alternative technology from the NoSQL space. There's even a nod that younger millennials don't think that the big vendors' software is feasible. 

While I do think that many younger developers get excited by new technologies, I'd note that many of us older developers used to be young and get excited by new technologies as well. We just temper that with some experience to note that there are rarely magic bullets in technology and much of what we choose to implement has its own disadvantages and tradeoffs. While some might be worth making, not all are.

I do think that some of the technologies that have been developed by vendors in the NoSQL space are useful. Microsoft sees that and the Big Data Clusters coming in SQL Server 2019 are an attempt to access more data and make it useful to an organization. The addition of Machine Learning Services in the last two versions was another way in which the "same old, same old" product from this vendor is growing to accommodate the needs of more customers.

That doesn't mean I view all other types of database technologies as useless. Certainly there are problem domains where a graph database or a key-value store might provide lots of advantages. More and more customers and clients are integrating other databases in strategic places. Redis and Elasticsearch are incredibly popular, and they work very well on certain problems.  Other databases are worth investigating, though moving wholesale to a new technology based on a Proof of Concept, no matter how complex, is something I wouldn't recommend.

The challenge, as always, is getting the data to the engine that can process it. Throwing every query and workload onto your OLTP database is a recipe for disaster, though using ETL processes to copy data to other systems is a complex, though viable, alternative. It just takes work.

Systems are never fast enough for all users, but they often work very well for most of us. Don't get caught up in a new technology and expect it to solve all your problems. Likewise don't be close minded when it comes to evaluating another database engine. Follow the DevOps philosophy. Do more of what works, less of what doesn't, experiment, and always be learning.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating