关于数据库选型中的几个问题谈谈我的观点


关于数据库选型中的几个问题谈谈我的观点

文章插图
最近总有朋友问我数据库选型的问题,希望我写几篇文章阐述下我的观点 。写这种文章是十分得罪友商的,所以在这方面我一向比较谨慎 。不过有些话还是不吐不快,今天就讲几句吧 。观点只是个人的看法,并不一定正确,也没有任何学术探讨的意思 。实际上数据库应用场景的复杂性决定了不同的用户对自己的数据库选型都有一套自己的看法,可能对别人来说,不一定合适,不过可能只有自己会知道,这种选择是合适的 。鞋是不是合适,只有脚知道 。因此今天我所表达的观点,如果有些不太对您的胃口,姑且一笑而过 。
谈到数据库选型,免不了要说benchnark测试,当年数据库与小型机市场战火纷飞的时候,TPC-C打榜十分热闹,数据库厂商要证明自己的数据库是天下武功第一 。数据库市场和小型机市场尘埃落定之后,厂家很少去搞TPC-C打榜了,反倒是近些年中国和韩国的数据库厂家偶尔会出现在最新的榜单中 。TPC-C基准测试实际上并不仅仅是数据库的性能测试,而是一个数据库应用系统的整体性能测试,不仅仅要看TPMC的极端指标,还要看每个TPMC的成本 。我想现在国产数据库选型的时候,每个企业都会针对TPC-C/TPC-H等进行测试 。实际上这种测试意义并不大,只要是一个合格的数据库厂商,那么它出厂时TPC-C就能够满足绝大多数应用场景的需求,而那些真正的需要高并发,大负载的场景,benchmark测试是测不出来的 。TPC-H也是类似,每个数据库厂商都会在数据库研发时针对tpc-c/tpc-h等基准测试场景做好优化工作,因此只要是一个靠谱一点的数据库产品,这方面都能够满足你的业务需求 。另外一方面,TPC-C测试是一种十分专业的测试,一般的测试团队不具备测试与分析测试数据的能力,因此测试获得的数据也不一定准确,无法进行横向对比 。
数据库选型中的第二个常见问题是分布式数据库和集中式数据库之间的选择 。很多用户在考虑数据库选型的时候都会对横向扩展能力有一些执念,认为选择数据库一定要选择具有横向扩展能力的数据库产品 。实际上绝大多数企业数据库应用场景对横向扩展的要求并没有那么高,一台2路服务器往往已经能够满足未来5年的业务需求了,更何况我们还有更大配置的4路、8路服务器可选 。而五年后,服务器的性能又可以翻番 。因此对于大多数系统来说,横向扩展并不一定是刚需 。我和很多金融企业的IT人员交流过,他们选择分布式数据库的主要考虑是安全性和可靠性,并不是更大的并发处理能力与动态扩展能力 。在他们进行的一些测试中,也发现了交易在分布式数据库上交易延时并不像分布式数据库厂商所说的那么优秀 。对于绝大多数用户来说也是如此,对于OLTP系统来说,用户需要的是分布式数据库的高可用架构,而并不是其横向扩展能力以及极致高并发能力,大多数系统一个单机集中式数据库就能够很好的支撑了 。OLAP领域则是相反的,支持列存引擎的MPP数据库在低并发,复杂SQL并发执行上面的优势是十分明显的 。
第三个问题是Oracle兼容性问题,这个问题上有两派截然不同的观点 。第一派认为和Oracle兼容十分重要,兼容性已经成为他们选择替代数据库的最重要的原则 。另外一派则认为无所谓,数据迁移是一次性的,只要能够做好数模转换,花费一次性的成本就可以解决问题了,没必要把企业的数据库应用锁定在与Oracle兼容这个圈子里,让自己在数据库选型方面受到限制 。持这种观点的人大多数都是MySQL的拥趸,因为MySQL与Oracle的兼容性方面确实差距有点大 。第一派认为与Oracle的兼容性十分关键,这不仅仅涉及到应用迁移的成本,也涉及到今后长期运维时能够降低一些成本 。在这方面我还是倾向于这种观点的,因为在考虑数据库选型的企业中,往往都是已经大规模使用Oracle数据库的,与Oracle保持较高的兼容性,不仅仅可以降低应用迁移的成本,更重要的是可以让整个企业IT都维持在一个Oracle兼容性生态中,研发队伍也不需要去适应新的研发习惯,以往的一些积累也可以继续沿用 。这样就可以大大节约数据库国产化工作中的整体IT投资 。不过兼容性不仅仅要看表面上的兼容性,如果一条SQL不加以修改就能在新数据库上跑,但是性能下降了几十倍,不该写还无法正常使用,那么这种兼容性是伪兼容性,而不是真正的兼容 。在企业做数据库选型的时候,需要对一些常用的复杂SQL进行测试,才能真正区分出两种看似“很兼容”的数据库产品中的兼容性的差别 。


推荐阅读