NoDBA(干掉数据库管理员)

13-02-26 banq
Martin fowler发表了一篇有关NoSQL导致NoDBA文章,文章大意如下:

在许多组织中,任何持久性数据将被存储在关系数据库中,由一个中央数据库管理组织进行管理的(DBA)。 这样做有各种原因:利于中央控制。 中央数据组确保良好标准的数据格式,对数据查询优化减少共享资源的负载,并制定整个企业的统一的数据模型。

这样做也许是值得的,但是他们对数据储存可能过于仪式化(banq注:流程标准 不能搞特殊化),可能经常有需要花几个星期将一个列数据加入数据库,这样的时间周期太慢,且太烦人。

所以,应用开发者使用NoSQL将终结自己围着DBA奔波。DBA被告知仅仅是数据存储在这里,而不是一个正规的数据库,这样也许减少大家的麻烦。如下图:

这样做有好的一方面,也有坏的一方面:

好的方面是:这有助于打破许多组织的应用程序开发中一个令人不安的瓶颈:应用程序开发人员和数据库专业人员之间的鸿沟会导致很多问题。

DBA社区扼杀窒息了许多现代开发技术的发展。共享的数据库是一个“贫穷”的整合机制,NoDBA运动发展将有益的推动基于Web服务的集成。

坏的方面是:很难想象,人们使用关系数据库比较好的时候,他们会改变采取抛弃DBA的NoSQL技术,再者,数据是企业资产,绕过DBA,可能忽视有价值数据的备份和保护。

最好的办法是:DBA也需要参与开发者运动,帮助他们了解这项新技术,并获得了宝贵的帮助,支持数据的需求,总之,可以有适当的NODBA,但是大家都参与总是好的。(banq注:如果不配合,就干掉DBA?哈哈)

[该贴被banq于2013-02-26 16:16修改过]

3
banq
2013-02-27 08:15
2005年我写了一篇:数据库时代的终结,大呼中间件SOA时代必定终结数据库时代;

2008年我又唐吉珂德式的写了一篇文章:数据库已死,指出NoSQL必将终结关系数据库时代。

MF这篇文章也是反映他在国外实践前沿发现的潮流,从其文章中看出,有不少应用开发者向他反映他们采取NoSQL,有一方面是为了避免与DBA繁琐的交通成本。

程序员与DBA之间的交流鸿沟,类似对象和关系数据库之间的阻抗一样,是不可调和的,是无法消灭的,只能靠良好的团队管理这些软因素抵消这种鸿沟。

masterice
2013-02-27 15:23
。。。估计今生看不到这样的事儿了

lostalien
2013-03-01 17:27
普通业务系统可以nosql,可是报表啥的怎么办?还有BI之类的

ericyang
2013-03-11 16:10
听说过Autonomy么,虽然很垃圾,不过是个方向。。。

windshome
2013-05-20 15:29
我觉得banq兄你这个观点有点过,呵呵!不能因为架构师和开发人员的原因kill掉DBA啊!

在一个大的系统里,各司其职,自然各自有各自的考虑,架构师应该考虑的是概念和系统的骨架;设计师和开发人员想的是系统的“肉”(指细节的设计和实现);DBA负责系统的数据,没有矛盾。而所谓阻抗,就像无所不在的矛与盾,什么时候都会存在,即便你kill掉DBA,还会出现其它种种矛盾的。

而且,你关于NoSQL的观点我也有不同的见解。在我的文章http://windshome.iteye.com/blog/1852925 中描述了我的看法,我的看法比较粗浅,但是也请不吝赐教。

banq
2013-05-20 15:46
2013-05-20 15:29 "@windshome

"的内容

觉得banq兄你这个观点有点过,呵呵!不能因为架构师和开发人员的原因kill掉DBA啊! ...

呵呵 ,这是我转翻译的MF文章,MF的意思让他们试图和平相处,这是我同意的。

关于数据库和对象的阻抗,推荐这篇DDD/CQRS/EventSorucing的文章读读:http://cqrs.wordpress.com/documents/events-as-storage-mechanism/

在Impedance Mismatch段落专门谈了这种情况,我大致翻译如下:

“为什么这个阻抗失配的存在?面向对象的范例是基于成熟的软件工程原则。,而关系范式是基于成熟的数学原理。

因为基本的范式导致不同的两个技术不能无缝地协同工作。当选择作为起步第一个方法时,阻抗失配变得明显。

用对象范式时你遍历对象是通过它们之间的关系,而关系范式你是通过加入表的数据行。这是根本的区别,结果导致对象和关系的技术发生了非理想的组合,虽然你一起使用他们好像有时没有问题?“

虽然许多工具在试图解决这个不匹配如ORM,当你必须付出成本,需要非常熟悉这两种技术,了解它们之间的差异,然后进行基于知识进行智能的权衡。

具体不匹配表现在下面几点:

Declarative vs. imperative interfaces(声明与命令接口)

Structure vs. behaviour (结构和行为)

Set vs. graph relationships(Set集合和图论)

windshome
2013-05-20 16:35
呵呵,banq兄回复真快。

你解释得很清楚,因为他们本身就不是一个源,所以,设计上的矛盾无法避免。

我觉得我之前在系统设计上,都是尽可能延迟数据库的设计,延迟建库、建表;让自己和设计人员集中心思在业务对象、业务对象的上下文限制以及业务对象之间的关系,通过“伪”的代码和设计,在没有数据库之前把系统框子搭好,之后再考虑怎么做数据的存取。

所以,我都是把数据库存取部分当成非常不重要的部分(是有意这么做的,减少项目组员跟着ORM框架走这个趋势)。而我更喜欢用底层技术(例如JDBC)来实现这些东西。这是很多人都不喜欢的。

猜你喜欢