principleMinor
MongoDB vs RDBMS DBA duties
Viewed 0 times
dutiesdbamongodbrdbms
Problem
What are the differences between the daily tasks/duties of a Mongo DBA compared to a RDBMS DBA?
For example, some sites claim that a MongoDB DBA would not require to do data modelling or designing the database, as that would be done by a developer or application designer.
This would mean some tasks are no longer needed to be done wrt MongoDB administrations, which was earlier being done by the RDBMS DBAs.
What other tasks would be required, that are not normally in the schedule of a RDBMS DBA?, and also the task which the RDBMS DBAs used to do but is no longer in the schedule of MongoDB DBAs ?
I'm new in MongoDB administration, so I'm trying to identify these task so that I may not commit the mistake of doing things in my daily task that are not needed or I miss something that I need to.
Can any experienced MongoDB DBAs help me out so that I don't do any foolish mistakes in my work ?
For example, some sites claim that a MongoDB DBA would not require to do data modelling or designing the database, as that would be done by a developer or application designer.
This would mean some tasks are no longer needed to be done wrt MongoDB administrations, which was earlier being done by the RDBMS DBAs.
What other tasks would be required, that are not normally in the schedule of a RDBMS DBA?, and also the task which the RDBMS DBAs used to do but is no longer in the schedule of MongoDB DBAs ?
I'm new in MongoDB administration, so I'm trying to identify these task so that I may not commit the mistake of doing things in my daily task that are not needed or I miss something that I need to.
Can any experienced MongoDB DBAs help me out so that I don't do any foolish mistakes in my work ?
Solution
DBA is a small acronym but a large role. At various times I have seen a DBA look after
.. and others besides. I cannot see any of these disappearing just because Oracle/ SQL Server/ PostgreSQL is replaced by MongoDB/ Cassandra/ CouchDB.
"Oh," but you say, "There's no schema. I don't have to do that modelling & design thing."
"You're deluded," I would reply. If the system is for, say, order processsing (and not order processing and chocolate cake recipies and cataloging selfies etc.), and The Business distinguishes Orders by a 7-digit integer Order Number, and each Order consists of one or more Order Lines (referencing one Product each), then you have a schema. Just because it's enforced in the application layer and not in the DBMS does not make it disappear. And somebody had better be writting those rules down, and confirming them with the users, and communicating them to the test team, and teaching newly-hired employees what they are, and getting them into the end-user documentation, and ensuring old data can still be read by the just-changed application. Just because the rules can be changed in application code alone, rather than application code and DBMS script, does not make any of that stuff any less important.
So, for my two cents' worth, despite its many, many benefits I don't believe this class of software removes any significant task traditionally done by a DBA in the RDBMS world. It may redistribute them onto people holding other job titles, and the tasks may become easier to perform or less intrusive into the SDLC.
As for adding tasks, there is the issue of maintaining compatibility with old data written according to a previous understanding of the business rules. An RDBMS would not have this problem as there is only one acceptable schema at any point in time.
- storage
- network
- VMs
- compute nodes
- installation and configuration of the above
- backups, and testing restores
- DR strategy
- enterprise data integrity
- ETL
- data security
- data modelling, normalisation and database design
- data tier programing
- performance tuning
- operational availability
- replication
- failovers
- on-call support
.. and others besides. I cannot see any of these disappearing just because Oracle/ SQL Server/ PostgreSQL is replaced by MongoDB/ Cassandra/ CouchDB.
"Oh," but you say, "There's no schema. I don't have to do that modelling & design thing."
"You're deluded," I would reply. If the system is for, say, order processsing (and not order processing and chocolate cake recipies and cataloging selfies etc.), and The Business distinguishes Orders by a 7-digit integer Order Number, and each Order consists of one or more Order Lines (referencing one Product each), then you have a schema. Just because it's enforced in the application layer and not in the DBMS does not make it disappear. And somebody had better be writting those rules down, and confirming them with the users, and communicating them to the test team, and teaching newly-hired employees what they are, and getting them into the end-user documentation, and ensuring old data can still be read by the just-changed application. Just because the rules can be changed in application code alone, rather than application code and DBMS script, does not make any of that stuff any less important.
So, for my two cents' worth, despite its many, many benefits I don't believe this class of software removes any significant task traditionally done by a DBA in the RDBMS world. It may redistribute them onto people holding other job titles, and the tasks may become easier to perform or less intrusive into the SDLC.
As for adding tasks, there is the issue of maintaining compatibility with old data written according to a previous understanding of the business rules. An RDBMS would not have this problem as there is only one acceptable schema at any point in time.
Context
StackExchange Database Administrators Q#138522, answer score: 8
Revisions (0)
No revisions yet.