昨天在分析一个问题的时候翻到OB的一个知识库文章，里面介绍说不建议一个集群中存储超过3万个分区。我对此很不理解，作为一个分布式数据库，存储海量数据是基本的能力，这些数据大多数是分区表，以前用过的Oracle数据库中的一些大表单表有几千个分区也是常见的，3万个分区够干什么用的。

　　后来和OB的同学讨论后才知道这个描述不够准确，不过在OB 4.X之前，分区都用PG来管理主副本同步。一个PG可以管理多个分区，而OB 2.2之前连PG都没有，一个分区就要占用一定的存储空间。因此在一个单一的OBSERVER中，根据常规内存配置，不建议保存超过5万个分区，否则可能内存占用过大，而2.2版本后这个数量已经放大数倍了。OB 4.X随着新架构的引入，这个问题得到了更好解决。那篇文章所说的“集群中分区数量之和不大于 3 万”的描述，显然是文档编写者的笔误了。

　　这个问题上虽然是虚惊一场，不过从对这个问题的历史渊源的分析也看出来，很多数据库在使用的时候还是有一些限制的，如果不了解这样的限制就去任意使用，今后遇到的麻烦会不小的。我想起了前两年和一个企业的IT部门领导交流国产数据库替代的事情的时候，他认为：“不就是换个数据库吗？都是SQL，换那个数据库，大不了我们的开发商多做点工作不就行了！”。当时我认为他的观点错得离谱，但是他不是计算机专业出身，想要用一些浅显的计算机语言改变他的看法也确实不易，因此当时也只能一笑了之。

　　换个数据库没那么简单，里面有不少坑，不把现实的应用场景代入到某个数据库里，是无从全面知晓的。如果我们真的遇到了OB 2.2之前的版本，服务器内存又有限，单分区的分区数量又极大，那么除了大量扩展OB集群的节点数量，就没有更好的办法了。

　　前些年一个用户在做国产化数据库选型的时候选了一种基于MYSQL+SQL代理中间件的分布式数据库，我当时根据他们的应用特点，觉得不是很合适，建议他们慎重选择，当时他们的领导也是这个观点：“我们的开发部水平不错，让他们去适配吧”。后来开发过程中开发人员遇到大量的SQL性能不行，让数据库原厂的人到现场指导，数据库原厂的工程师直接拿出一本SQL编写指南来，一一指出他们的SQL写得不合规才导致了性能问题。研发部门的领导之前是十分挺这个数据库厂家的，只能捏着鼻子扛下了应用改造的工作。不过从那以后，后续系统的国产化数据库替代工作，他们就再也没有选择这个数据库产品了。

　　从今天我说的这个小例子也可以看出，我们面对的大多数数据库并不是能够让人随心所欲地使用的，因此在为应用选择合适的数据库产品的时候要十分小心。比如说分区表这个功能，几乎所有的数据库都有。不过PG的分区表和Oracle的分区表使用起来是一样的吗？恐怕只有深度用过的人才会理解PG的分区表的不完善之处太多了。临时表也是如此，PG的临时表里的一些奇葩缺陷，会让以前用惯Oracle临时表的开发人员崩溃。

　　除了用户在选择数据库的时候不能被名词所迷惑，数据库厂商也应该承担起这个责任来，不断地打破自己的数据库产品中的这些限制，让用户用起来越来越舒服。OB的这个单服务器分片数量限制从PRE 2.2到4.x的数次优化是我们愿意看到的进步。