哇！ 自从我在博客文章中发布内容以来已经有一段时间了。 我一直很忙，搬到MongoDB，学习，学习，学习……最后我可以喘口气，回答一些问题。
上周，我一直在帮助我的同事Norberto在巴黎提供MongoDB Essentials培训。 这是一个非常好的经历，我急于自己交付它。 我很高兴看到观众在开发人员和操作人员（主要是DBA）之间取得了很好的平衡。
我还需要DBA吗？
这是一个提出观点或提出错误想法的好机会：您正在使用MongoDB或任何其他NoSQL数据存储这一事实并不意味着您不需要DBA…与任何项目一样，管理员不是强制性的，但是如果你有一个更好。 因此，即使在开发团队推动MongoDB的情况下，了解数据库的工作方式以及如何管理，监视它也非常重要。
如果您很幸运地拥有真正的运营团队，那么好的系统和数据库管理员可以使用它们！ 它们对于您的应用程序非常重要。
大多数DBA /系统管理员已经在生产中维护系统多年。 他们知道如何保持您的应用程序正常运行。 他们大多数时候还经历了许多“灾难”，然后恢复（我希望）。
谁知道，您的应用程序可能会遇到大问题，您现在很乐意将它们放在您的身边。
“很好，但是DBA减慢了我的开发速度！”
有时，我听到了这一消息，过去对大型组织的开发人员有这种感觉。 是真的吗
开发人员和DBA如今不在同一世界：
- 开发人员希望尽快集成新技术，这不仅是因为它很有趣，而且他们可以在聚会或会议中吹牛。 但是由于这些技术在大多数情况下正在提高它们的生产力，并为消费者提供更好的服务/体验
- DBA，在这里保持应用程序的正常运行！ 因此，每当他们对某项技术不满时，他们都会退缩。 我认为这很自然，而且我的立场可能也会一样。 像所有极客一样，他们会乐于采用新技术，但他们需要在此之前先了解并信任它。
系统管理员，DBAS与开发人员以不同的角度看待该技术。
基于此假设，当开发团队要集成MongoDB或任何新的数据存储时，请尽早将操作团队带入非常重要。 尽早让运营团队参与进来将简化MongoDB在公司中的全球采用。
就个人而言，这将显示我的年龄，我已经看到开发人员和DBA一起工作的方式发生了巨大变化。
上世纪90年代，当时主要的架构是基于客户端/服务器架构的开发人员和DBA一起工作的； 可能是因为他们说的是同一语言：SQL无处不在。 我定期开会，机智
然后，自2000年中以来，大量的应用程序已迁移到具有Java中间件的基于Web的体系结构，并且开发人员停止使用DBA。 可能是因为ORM提供的抽象数据层将数据库公开为应该起作用的“商品”服务：“嗨，DBA先生，我的应用程序是使用市场上最好的中间件技术编写的，因此现在要处理性能和可扩展性！ 我做完！”
是的，这是陈词滥调，但是我敢肯定，你们中的一些人会意识到这一点。
但是，我会尽可能地推动开发人员与管理员进行更多的交流，并密切关注他们的数据库！
运营和开发团队的新时代
开发人员对MongoDB的快速采用，是修复我们十年前在大型信息系统中破坏的绝好的机会：
- 再说吧！
MongoDB首先为开发人员构建。 面向文档的方法具有很大的灵活性，可以快速适应变化。 因此，即使您的业务用户需要一项新功能，也可以实施它，即使此更改会影响数据结构。 现在，数据模型由应用程序而非数据库引擎驱动和控制。
但是，应用程序仍需要24×7可用，并且运行良好。 这些主题由管理员和开发人员管理和共享！ 情况一直都是这样，但是，正如我之前所描述的，我们当中有些人似乎已经忘记了这一点。
模式设计，更改速度由应用程序驱动，因此业务和开发团队会影响数据库，例如：
- 存储将如何增长？
- 必须创建哪些索引来加速我的应用程序？
- 如何组织群集以正确利用基础架构：
- 副本集组织（以及相关的写入问题，由开发人员管理）
- 其中最重要的是：备份/恢复策略
项目团队可以管理很多事情，但是如果您有一个运营团队，那么最好由一个团队来完成。
您（开发人员）坚信MongoDB是适合您的项目的最佳数据库！ 现在是时候与操作团队合作并说服他们了。 因此，您应该确定要说明为什么MongoDB对您来说对开发人员有好处，但同时您也应该强调操作的所有好处，首先是内置高可用性的副本集，以及通过分片实现的易扩展性。 MongoDB也可以使管理员的工作更加轻松！ 在下一段中，我分享了一些操作人员感兴趣的资源。
让我们再重复一遍，尝试尽快让操作团队参与进来，并以此为契机建立/重建开发人员与系统管理员之间的关系！
资源资源
您可以在网站上找到许多有用的资源来帮助操作或了解以下信息：
翻译自: https://www.javacodegeeks.com/2014/04/db-person-find-role-dba.html
2206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
