无 DBA
2013 年 2 月 25 日
在许多组织中,人们期望任何持久性数据都将存储在由中央数据库管理组管理的关系数据库中。这种中央控制有各种原因,通常集中在使用 集成数据库。中央数据组担心阻止格式错误的数据、可能减慢重要共享资源速度的查询以及跨企业的始终一致的数据模型。
这些目标可能值得,但它们的一个后果是关于存储数据的相当多的仪式。我经常听到关于更改订单的抱怨,这些更改订单需要数周才能在数据库中添加一列。对于习惯于短周期演化式设计的现代应用程序开发人员来说,这种仪式太慢了,更不用说太烦人了。
因此,应用程序开发组告诉我使用 NoSQL 数据库 来绕过 DBA。他们在这里使用的是“仅仅是数据存储”,而不是“真正的数据库”,这很有帮助。这样,DBA 就可以被排除在循环之外,通常不会被告知或乐于不关心。 [1]
所有这些都有好有坏。从好的方面来说,这有助于打破许多组织应用程序开发中经常出现的瓶颈。应用程序开发人员和数据库专业人员之间的可悲分隔造成了许多问题,DBA 社区对许多 现代 开发 技术 的采用不足,扼杀了许多开发。 共享数据库 是一种糟糕的集成机制,NoDBA 开发推动了将 Web 服务 作为集成基础的趋势。 [2]
从负面的角度来看,出于社会原因使用一项技术往往会导致对该技术的糟糕使用。不难想象人们使用 NoSQL 数据库来避免 DBA,而关系型 应用程序数据库 会是更好的选择。数据通常是重要的资产,绕过 DBA 组也可能意味着绕过知道如何备份和保护宝贵数据的运维组。
当然,真正的答案是与数据专业人员进行类似于 DevOps 运动的合作。正是组与组之间的障碍造成了许多仪式,很少有数据组是由魔鬼组成的。我们已经看到邀请 DBA 参加利益相关者会议取得了成功,他们在会议上可以参与应用程序的广泛目标。我们也有一些 NoSQL 项目,我们联系了 DBA,帮助他们了解这项新技术,并在支持数据需求方面获得了宝贵的帮助。因此,尽管 NoDBA 策略有时是合适的,但合作通常更好。
致谢
像往常一样,我发现我们内部列表上关于本文草案的讨论非常有趣。我特别借鉴了 David Pattinson 的贡献。注释
1: 在这种情况下,使用 MongoDB 似乎特别常见,理由是 MongoDB 易于安装、配置和使用。
2: 对更改请求的缓慢响应很大程度上是因为许多现有的数据库本质上是大型依赖关系网络中心的复杂遗留应用程序。这些数据库很脆弱且未经测试(不可测试),因此 DBA 谨慎地进行更改也就不足为奇了。这样的系统甚至会让最聪明的开发人员对进行更改犹豫不决。