MongoDB vs RDBMS DBA duties
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 & 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.
I have been in the NoSQL field since last 3 years.
Being a MongoDB DBA you need to work closely with Development and Ops teams. Following are the things you need to do as day to day tasks as a MongoDB DBA.
The role can be broadly classified into three parts:
Administration:
- New deployments (manual/automated)
- Deployment design of your database systems
- Monitoring
- Backups & Recovery
- Security
- DB Health best practices
Development:
- You are required to write code/scripts that run periodically/once on your data, this may be required to generate reports & analytics.
- Debugging application-db issues with development teams
- Implementing availability, scalability and security from app side
- Querying database on staging and production whenever required
- Suggesting indexing strategies and implementing them
- You are involved in database design and modelling
Performance Tuning:
- This requires continuously measuring performance of your database using tools
- Create indexes or shard database based on the requirements
- Report database performance to the dev team