关于大型网站数据库的讨论-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

关于大型网站数据库的讨论

简介:

俱乐部离有朋友建议看看http://www.phpv.net/html/1659.html大型网站架构的问题,这里谈点个人的看法。

感觉作者有点悲观了。

他所描述的,实际上是关系型数据库,数据量恶性增长,并且新业务不断添加之后造成的恶果。

关系型数据库,顾名思义,主要存储关系,换而言之,它是作为通用性数据库推出的,因此,设计时,面面俱到,功能很完善,但性能堪忧,很难做到单笔业务优化的灵活性。

    目前我们的业务中也有类似的问题,MySQL不管怎么完善,总觉得差了一颗米。

事实上,经过思考,我认为我们如果跳出关系型数据库的框框,很多思路就豁然开朗了。

    数据库,顾名思义,本来就是负责数据存储的,能满足数据快速保存和提取就好了。这才是数据库真正应该干的事情。

但在数据库应用中,很多业务其实是数据的关系组织,将一堆离散的数据,静态或动态构建其关系,即可提供出新的业务。这造成了人们一种很不好的习惯性思维,认为关系才是数据库的核心,想让数据库替代程序员处理所有的关系处理的原因。

我仔细研究了一下作者的议题:

A. 海量数据的处理。

其实这是一个数据库平行扩容性问题,我们知道,其实如果以简单的文件来组织数据,平行扩容根本不是问题,但为什么关系型数据库,平行扩容很难呢?原因很简单,关系型数据库,关注了太多的关系,而做过大型程序的人都知道,一个系统的设计,首先就是设定边界,关系型数据库,处理的边界太多,很难实现平行扩容。

B. 数据并发的处理

其实这也是习惯性思维的一个恶果,关系型数据库,以数据库为核心考虑设计的问题,自然而然,系统的设计不知不觉变成了星型设计,即数据库是整个系统的核心,数据库做了太多不擅长的事情,连缓存和锁都要关注。甚至还要在前级设计连接池,处理海量并发的连接请求,其实,作为系统设计而言,数据库就是数据库,这些工作,应该另有专门的模块去解决的。

C. 文件存贮的问题

其实这个问题也是平行扩容性不好导致的,如果我们数据库仅仅处理简单数据请求,前级一个简单的DirectoryService,已经足以做到动态负载均衡,那哪里还有文件存储问题。

D. 数据关系的处理

关系型数据库的设计,最痛苦的莫过于表段设计,要以静态的表段,归纳整理出业务所需要的所有关系,并且还要兼顾以后潜在的关系需求,确实是一件不可能的任务。

最后的结果,基本上又走回了头疼医头,脚疼医脚,来个新任务,加个查询,加个事务,加个表之类的打补丁操作。

E. 数据索引的问题

关系型数据库,由于试图以静态表来完成动态的索引需求,必然导致索引算法僵化,很难满足所有的应用。

F. 分布式处理

这其实也是A类的平行扩容性问题。

G. Ajax的利弊分析

这个我不懂,不予置评。

H. 数据安全性的分析

这个我认为也是关系型数据库处理了太多不相干业务的问题,加密,本来就不是数据库应该做的事情。

I. 数据同步和集群的处理的问题

这其实也是A类的平行扩容性问题。

K.数据共享的渠道以及OPENAPI趋势

OpenAPI很好,但我认为这和数据库没有关系,这是关系的新的组织方式,是数据库的使用者应该关注的,而不是数据库本身应该关注的事情。

综上所述,我发现,其实作者写的大部分问题,其实都是因为思路局限在关系型数据库这个框框里面导致的。

跳出框框,其实我们发现还有哈希型数据库等很多选择。其实别的类型的数据库,处理起上述问题来,都比关系型数据库方便。

这里说一点我的经验,一家之言哈,仅供参考,欢迎批评。

如果我来设计一个海量数据库,可能首先考虑的就是平行扩容性,原因很简单,我没有办法预估将来的数据规模,那我也就没有边界可言,因此,基本上首选dbm类哈希型数据库,甚至,对于实时性要求很高的数据库,可能会自行设计库。

事实上,以前在为一个证券系统做顾问时,考虑到高可靠性和高性能,我们直接接管了一个磁盘的FAT系统,直接以扇区方式,自行构建Index体系,完成数据库的Add、Del、Modeify逻辑。

一个数据库,简单做好数据的存储就好了,其他的它不应该考虑,因此,其实它也只应该接受Add、Del、Modeify这三条逻辑,这其实就是数据库的API,对上,它屏蔽内部数据处理细节,对下,它处理简单信令,不理解复杂的业务逻辑。

那么,在此基础上,我们考虑数据库平行扩容,则应该考虑一套目录服务Directory Service,而实现目录服务的关键,首先要考虑一套合用的ID体系,即数据库中每个元素,都可以使用唯一ID来表示。

事实上,我做的所有数据库相关项目,第一件事情,就是规划ID。

目录体系有很多种规划方式,这里不一一列举额,但我们可以知道,只要有一个合用的目录体系,其实存储方面的平行扩容是很容易的。

然后我们来讨论访问,数据库要做到高效访问,必然有并发处理,也就一定会带出锁业务,然后,锁死、死锁。。。就都来了。

难道这样就无解吗?

其实不是的,我们发现,web相关应用,其实在超时上是很宽泛的,基本上都是秒级,甚至是分钟级,换而言之,一次请求,被悬挂一段时间,是可以的。

那么,我们为什么还要用同步模式,同步才会有锁要求,要是所有的请求被打入队列,后台实现一个事务处理机,从队列中提取需求,分别异步处理,哪里还需要锁?

但这里面带出一个问题,当一个客户请求被悬挂等待,当请求处理完成后,结果需要回送给发起者时,需要有一个检索依据,这也很简单,一个SessionID就好了。

那么,我们其实可以把绝大多数的客户端请求都由同步模式,变成“异步+SessionID”的伪同步模式,那么,我们所谓的锁效率,死锁问题,其实就迎刃而解了。

这时我们已经可以看到,通过事务批处理机、目录服务和底层数据存取模块,我们已经把前文提到的很多问题都解决了。

那下面的问题是什么?

业务。

前文说过,业务就是不同关系的组织,那么,既然业务千变万化,为什么我们还要用静态的表来处理动态的关系?

前级业务层使用一套脚本语言来处理,PHP、JS,选择太多了,所有的业务关系,其实是利用脚本语言组织出来的,要改很容易,而且非常灵活,数据库中仅仅保留的是离散的数据,数据库也从不理解数据的含义。

这其实是我们利用脚本语言,构建了一套业务描述层。

Ok,综上所述,我们可以看到,当我们使用业务描述脚本、事务批处理机、目录服务、底层存取来划分一个数据库系统之后,其实,所谓的海量数据需求,也就不是那么难办到了。

嗯,这样还有一个额外的好处,就是由于平行扩容性很好,因此,前期可以以较低成本搭建一个简单的架子,后期根据业务量逐出扩容。这对很多企业来说,就是入门门槛很低,便于操作,且商业风险也小。比起动辄几十万美金,搭建豪华的Oracle平台,成本低多了。

以上仅为本人的一点工作心得,我其实也不是搞数据库专业出身的,因此难免有孟浪之处,呵呵,仅供参考,欢迎大家拍砖。

***********************************************************************

补充一点:

前文我说了这么多,可能有点偏激了。这不太好。

我的本意是希望做系统分析时,跳出框框,拓展思维,但并没有否定关系型数据库的意思。

关系型数据库,也有其优秀的一面,要一分为二地看待。

举个例子,在目录服务中,服务器数量较多,需要数据库来管理,但毕竟这个绝对数量比动辄几百万的终端客户数来说,还是小得多。这个数据规模,用关系型数据库来管理,就比较合用。

另外,关系型数据库,再怎么说,也是数据库,也具有数据库基本的存储和提取功能,这么看来,其实我们就用关系型数据库,作为数据库的底层存储模块,也是可行的,毕竟,纯增改删的效率,哪个数据库都做得比较到位了。

因此,我的建议,以后的数据库设计,还是要根据业务来细分,每个业务处理的数据规模不同,优化的方式不同,不好一概而论,原则上,哪个合用用哪个。毕竟从0开发,效率还是太低了。

既不轻易否定,也不轻易肯定。我想这是一个比较科学的态度。

根据不同的业务需求,选用合适的数据库方案,在公司资源够用的前提下,为公司尽可能地节约资源,创造更大的效益,我想,这也是我们架构师这个行业的核心竞争力吧。

呵呵,一家之言,欢迎拍砖哈。

俱乐部离有朋友建议看看http://www.phpv.net/html/1659.html大型网站架构的问题,这里谈点个人的看法。

感觉作者有点悲观了。

他所描述的,实际上是关系型数据库,数据量恶性增长,并且新业务不断添加之后造成的恶果。

关系型数据库,顾名思义,主要存储关系,换而言之,它是作为通用性数据库推出的,因此,设计时,面面俱到,功能很完善,但性能堪忧,很难做到单笔业务优化的灵活性。

    目前我们的业务中也有类似的问题,MySQL不管怎么完善,总觉得差了一颗米。

事实上,经过思考,我认为我们如果跳出关系型数据库的框框,很多思路就豁然开朗了。

    数据库,顾名思义,本来就是负责数据存储的,能满足数据快速保存和提取就好了。这才是数据库真正应该干的事情。

但在数据库应用中,很多业务其实是数据的关系组织,将一堆离散的数据,静态或动态构建其关系,即可提供出新的业务。这造成了人们一种很不好的习惯性思维,认为关系才是数据库的核心,想让数据库替代程序员处理所有的关系处理的原因。

我仔细研究了一下作者的议题:

A. 海量数据的处理。

其实这是一个数据库平行扩容性问题,我们知道,其实如果以简单的文件来组织数据,平行扩容根本不是问题,但为什么关系型数据库,平行扩容很难呢?原因很简单,关系型数据库,关注了太多的关系,而做过大型程序的人都知道,一个系统的设计,首先就是设定边界,关系型数据库,处理的边界太多,很难实现平行扩容。

B. 数据并发的处理

其实这也是习惯性思维的一个恶果,关系型数据库,以数据库为核心考虑设计的问题,自然而然,系统的设计不知不觉变成了星型设计,即数据库是整个系统的核心,数据库做了太多不擅长的事情,连缓存和锁都要关注。甚至还要在前级设计连接池,处理海量并发的连接请求,其实,作为系统设计而言,数据库就是数据库,这些工作,应该另有专门的模块去解决的。

C. 文件存贮的问题

其实这个问题也是平行扩容性不好导致的,如果我们数据库仅仅处理简单数据请求,前级一个简单的DirectoryService,已经足以做到动态负载均衡,那哪里还有文件存储问题。

D. 数据关系的处理

关系型数据库的设计,最痛苦的莫过于表段设计,要以静态的表段,归纳整理出业务所需要的所有关系,并且还要兼顾以后潜在的关系需求,确实是一件不可能的任务。

最后的结果,基本上又走回了头疼医头,脚疼医脚,来个新任务,加个查询,加个事务,加个表之类的打补丁操作。

E. 数据索引的问题

关系型数据库,由于试图以静态表来完成动态的索引需求,必然导致索引算法僵化,很难满足所有的应用。

F. 分布式处理

这其实也是A类的平行扩容性问题。

G. Ajax的利弊分析

这个我不懂,不予置评。

H. 数据安全性的分析

这个我认为也是关系型数据库处理了太多不相干业务的问题,加密,本来就不是数据库应该做的事情。

I. 数据同步和集群的处理的问题

这其实也是A类的平行扩容性问题。

K.数据共享的渠道以及OPENAPI趋势

OpenAPI很好,但我认为这和数据库没有关系,这是关系的新的组织方式,是数据库的使用者应该关注的,而不是数据库本身应该关注的事情。

综上所述,我发现,其实作者写的大部分问题,其实都是因为思路局限在关系型数据库这个框框里面导致的。

跳出框框,其实我们发现还有哈希型数据库等很多选择。其实别的类型的数据库,处理起上述问题来,都比关系型数据库方便。

这里说一点我的经验,一家之言哈,仅供参考,欢迎批评。

如果我来设计一个海量数据库,可能首先考虑的就是平行扩容性,原因很简单,我没有办法预估将来的数据规模,那我也就没有边界可言,因此,基本上首选dbm类哈希型数据库,甚至,对于实时性要求很高的数据库,可能会自行设计库。

事实上,以前在为一个证券系统做顾问时,考虑到高可靠性和高性能,我们直接接管了一个磁盘的FAT系统,直接以扇区方式,自行构建Index体系,完成数据库的Add、Del、Modeify逻辑。

一个数据库,简单做好数据的存储就好了,其他的它不应该考虑,因此,其实它也只应该接受Add、Del、Modeify这三条逻辑,这其实就是数据库的API,对上,它屏蔽内部数据处理细节,对下,它处理简单信令,不理解复杂的业务逻辑。

那么,在此基础上,我们考虑数据库平行扩容,则应该考虑一套目录服务Directory Service,而实现目录服务的关键,首先要考虑一套合用的ID体系,即数据库中每个元素,都可以使用唯一ID来表示。

事实上,我做的所有数据库相关项目,第一件事情,就是规划ID。

目录体系有很多种规划方式,这里不一一列举额,但我们可以知道,只要有一个合用的目录体系,其实存储方面的平行扩容是很容易的。

然后我们来讨论访问,数据库要做到高效访问,必然有并发处理,也就一定会带出锁业务,然后,锁死、死锁。。。就都来了。

难道这样就无解吗?

其实不是的,我们发现,web相关应用,其实在超时上是很宽泛的,基本上都是秒级,甚至是分钟级,换而言之,一次请求,被悬挂一段时间,是可以的。

那么,我们为什么还要用同步模式,同步才会有锁要求,要是所有的请求被打入队列,后台实现一个事务处理机,从队列中提取需求,分别异步处理,哪里还需要锁?

但这里面带出一个问题,当一个客户请求被悬挂等待,当请求处理完成后,结果需要回送给发起者时,需要有一个检索依据,这也很简单,一个SessionID就好了。

那么,我们其实可以把绝大多数的客户端请求都由同步模式,变成“异步+SessionID”的伪同步模式,那么,我们所谓的锁效率,死锁问题,其实就迎刃而解了。

这时我们已经可以看到,通过事务批处理机、目录服务和底层数据存取模块,我们已经把前文提到的很多问题都解决了。

那下面的问题是什么?

业务。

前文说过,业务就是不同关系的组织,那么,既然业务千变万化,为什么我们还要用静态的表来处理动态的关系?

前级业务层使用一套脚本语言来处理,PHP、JS,选择太多了,所有的业务关系,其实是利用脚本语言组织出来的,要改很容易,而且非常灵活,数据库中仅仅保留的是离散的数据,数据库也从不理解数据的含义。

这其实是我们利用脚本语言,构建了一套业务描述层。

Ok,综上所述,我们可以看到,当我们使用业务描述脚本、事务批处理机、目录服务、底层存取来划分一个数据库系统之后,其实,所谓的海量数据需求,也就不是那么难办到了。

嗯,这样还有一个额外的好处,就是由于平行扩容性很好,因此,前期可以以较低成本搭建一个简单的架子,后期根据业务量逐出扩容。这对很多企业来说,就是入门门槛很低,便于操作,且商业风险也小。比起动辄几十万美金,搭建豪华的Oracle平台,成本低多了。

以上仅为本人的一点工作心得,我其实也不是搞数据库专业出身的,因此难免有孟浪之处,呵呵,仅供参考,欢迎大家拍砖。

***********************************************************************

补充一点:

前文我说了这么多,可能有点偏激了。这不太好。

我的本意是希望做系统分析时,跳出框框,拓展思维,但并没有否定关系型数据库的意思。

关系型数据库,也有其优秀的一面,要一分为二地看待。

举个例子,在目录服务中,服务器数量较多,需要数据库来管理,但毕竟这个绝对数量比动辄几百万的终端客户数来说,还是小得多。这个数据规模,用关系型数据库来管理,就比较合用。

另外,关系型数据库,再怎么说,也是数据库,也具有数据库基本的存储和提取功能,这么看来,其实我们就用关系型数据库,作为数据库的底层存储模块,也是可行的,毕竟,纯增改删的效率,哪个数据库都做得比较到位了。

因此,我的建议,以后的数据库设计,还是要根据业务来细分,每个业务处理的数据规模不同,优化的方式不同,不好一概而论,原则上,哪个合用用哪个。毕竟从0开发,效率还是太低了。

既不轻易否定,也不轻易肯定。我想这是一个比较科学的态度。

根据不同的业务需求,选用合适的数据库方案,在公司资源够用的前提下,为公司尽可能地节约资源,创造更大的效益,我想,这也是我们架构师这个行业的核心竞争力吧。

呵呵,一家之言,欢迎拍砖哈。

本文转自tonyxiaohome 51CTO博客,原文链接:http://blog.51cto.com/tonyxiaohome/198494,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: