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

俱乐部离有朋友建议看看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，如需转载请自行联系原作者