与 RDBMS DBA 相比，Mongo DBA 的日常任务/职责有什么区别？
例如，一些站点声称 MongoDB DBA 不需要像开发人员或应用程序设计人员那样进行数据建模或设计数据库。
这意味着某些任务不再需要由 MongoDB 管理来完成，而这些任务早先由 RDBMS DBA 完成。
还需要哪些其他任务，这些任务通常不在 RDBMS DBA 的日程安排中？以及 RDBMS DBA 曾经执行但不再在 MongoDB DBA 日程安排中的任务？
我是 MongoDB 管理的新手，所以我试图确定这些任务，这样我就不会犯在日常任务中做不需要的事情的错误，或者我错过了我需要做的事情。
任何有经验的 MongoDB DBA 都可以帮助我，这样我就不会在工作中犯任何愚蠢的错误吗？
DBA 是一个小缩写，但作用很大。我曾多次看到 DBA 照看
.. 和其他人。我看不到其中任何一个会因为 Oracle/SQL Server/PostgreSQL 被 MongoDB/Cassandra/CouchDB 取代而消失。
“哦，”但你说，“没有模式。我不必做建模和设计的事情。”
“你被迷惑了，”我会回答。如果系统用于订单处理（而不是订单处理和巧克力蛋糕食谱和自拍编目等），并且业务部门通过 7 位整数订单号区分订单，并且每个订单由一个或多个订单行组成（每个引用一个产品），那么您就有了一个架构。仅仅因为它是在应用程序层而不是在 DBMS 中强制执行并不会使其消失。还有人最好将这些规则写下来，并与用户确认，并将它们传达给测试团队，并教导新员工它们是什么，并将它们放入最终用户文档中，并确保旧数据仍然可以由刚刚更改的应用程序读取。仅仅因为规则可以单独在应用程序代码中更改，而不是在应用程序代码和 DBMS 脚本中更改，并不会使这些内容变得不那么重要。
因此，就我的两分钱而言，尽管它有很多很多好处，但我不相信这类软件会消除传统上由 DBA 在 RDBMS 世界中完成的任何重要任务。它可能会将它们重新分配给拥有其他职位的人，并且这些任务可能会变得更容易执行或对 SDLC 的侵入性降低。
至于添加任务，存在的问题是如何保持与根据之前对业务规则的理解编写的旧数据的兼容性。RDBMS 不会有这个问题，因为在任何时间点都只有一个可接受的模式。
自过去 3 年以来，我一直在 NoSQL 领域工作。
作为 MongoDB DBA，您需要与开发和运营团队密切合作。以下是作为 MongoDB DBA 的日常任务需要做的事情。角色大致可以分为三个部分：
行政：
发展：
性能调优：