MongoDB vs RDBMS DBA duties 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 ?
DBA is a small acronym but a large role. At various times I have seen a DBA look after


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 &amp; 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.