THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Maria Zakourdaev

Becoming a Multiplatform DBA.

I wonder if I had started my career as a PostgreSQL DBA or MongoDB DBA, would it be easier for me to accept the rapid growth and the variety of data storage solutions and our new reality of the Polyglot persistence?  

 

Polyglot is the term that came from the Ancient Greek meaning speaking many languages.  Polyglot persistence is about storing your data not only inside SQL Server but in multiple data storage technologies. Whatever suits better your application needs or sometimes even single application component.

 

Be prepared that tomorrow or next month one of developers will come up with some "other database" which (they will be 100% confident) will serve their application needs better. In  some situations they might be right. My own first natural reaction to those situations is to immediately start searching for "why not" arguments. To keep them in SQL Server. These days I try my best to hold this reaction and allow them to try. If it will work out - everyone will be happy. If not, everyone will learn.

 

If you push yourself to this change, you soon will realize that the learning curve is not that huge and you are not starting from zero level. Data can be modeled in various forms. Relational form, document form or key and value form but you already understand how to deal with data and how to take care of it. And believe me or not, the concepts are quite similar. 

 

Of course, your developer is now convinced that he will not need a DBA with his brand new NoSQL technology. Surprise him. You, as a DBA, and Mr. Developer have a strong focus and interest on an entirely different yet equally important aspects of the application infrastructure.

You know that  data must be backed up on some agreed schedule and from time to time it is beneficial to try and restore the backup to make sure it is useful.  Of course if data is important and needs to be persistent. 

After digging for a while you learn that the many open schema systems need someone to manage the schema anyway. Correct data types impact queries in ElasticSearch, Cassandra and some other systems that I have worked with.

Data modelling can be tricky and experienced DBA has a lot of added value there. Some queries might benefit from the pre-aggregations.

Monitoring your server is another huge topic. Monitoring free space, monitoring queries per second, events per second - trust me, Mr. Developer didn’t think about all this. He will be more than grateful to have you as a part of his project. He will re-learn to value DBA.

 

DBA stays DBA no matter which technology he is managing. Your experience is very valuable and you can append it to any technology you meet on your way.

Published Wednesday, March 23, 2016 2:03 PM by Maria Zakourdaev

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Dave Wentzel said:

Learning multiple DBMSs also helps you understand architectural tradeoffs that were made for each variant.  For instance, many sql server DBAs find it amazing that Oracle has no concept of clustered indexes and likewise Oracle DBAs don't understand why those things are even needed.  When you know both you get a true understanding of the different use cases.  

March 23, 2016 6:36 PM
 

Maria Zakourdaev said:

Dave, thank you for your comment. I agree with you. The more data storage technologies we meet on our way the better we understand the architectural tradeoffs, data usage patterns, data persistence and data modelling differences and impact.

However my main idea in this post was that the person who managed one DBMS for quite a while can switch to any other DBMS and, even without any experience, brings with him huge knowledge of how to tread and care for THE DATA.

March 24, 2016 5:03 AM
 

RichB said:

On the other hand, how many toys do you want to support when you have excess capacity already catered for, already in place, already monitored, already within a 24/7 care facility, highly available, already with appropriate consideration given to continuity, secondary uses of data, and access controls etc

Seems like work creation for the sake of it, unless there is a convincing argument why it should be the alternative, with all the overheads that brings with it.

Yes you can learn some cool new stuff on an alternative platform that you can get called out for at 3am.  But I bet there's still cool stuff you could do with SQL that they haven't thought through already.

Sure it won't be a new shiny toy (maybe) but it might just be the right solution for the business - rather than the developer.

March 28, 2016 10:26 PM
 

Maria Zakourdaev said:

RichB, the main convincing argument is usually query performance (milliseconds), large amounts of data and fast online analytics. when the requirements for performance and amounts of data that you need to support change you have no other choice but to provide solution. Even if it means going out of your comfort zone.

April 11, 2016 6:20 AM
 

Victor Sosa said:

Great post, Maria.

I´m a SQL Server professional but we can be closed to just one product, the current market is very volatile and we need to be prepared and open to new solutions. Hopefully, I will keep on working in SQL Server but if I need to learn a new technology to deliver the solution to the business I will.

January 20, 2017 5:01 PM
 

Victor Sosa said:

Little mistake in my previous answer, I meant to say: "we CAN'T be closed to just one product"

January 20, 2017 5:02 PM

Leave a Comment

(required) 
(required) 
Submit

About Maria Zakourdaev

The shortest word in the English language that contains the letters: abcdef is… feedback! Let me know if I have touched something that is alive in the cosmos.
Privacy Statement