没有完美的数据库怎么办
今年XC很热，国产数据库产品也层出不穷。我们看到更多的是一个数据库厂商明明没多少年历史，不过拿出产品清单来，可以看到这个厂商拥有的数据库产品数量之多，令人惊讶。这说明我们的数据库厂商能力很强吗？恐怕不是这样的。 上星期和一个数据库厂商谈一个客户的项目的数据库测试场景。这个系统数据库很大，核心业务库的测试环境有几十TB。应用场景也比较复杂，除了有大批量数据写入，还有一些需要多表关联的批处理业务，因为原来用的是ORACLE数据库，因此还需要保证和ORACLE有一定的兼容性，不能在应用迁移上太复杂了。厂商的售前人员之间和我沟通的时候表态是没有问题的，不过今天过来交流的两位都是做技术的。他们听了完整的需求后就犯难了。如果说是并发写入和大数据量查询，那么他们有一款数据库是可以一试的，不过这款数据库产品与Oracle数据库的兼容性就很差，而和Oracle数据库兼容性较好的产品则性能上可能无法满足要求。虽然厂商有很多款数据库产品，不过没有一款能够拿出来完整的完成这个替代Oracle数据库的工作。这是我们搞国产数据库替代时常遇到的场景，虽然可选择的数据库产品很多，不过都有缺陷，只能满足客户的部分需求。在替代一款Oracle数据库的时候，往往需要三英战吕布才行，刘关张无论是谁，单独上去都是去送人头。实际上Oracle当年也不太行，OLTP和OLAP还得在安装时候选择安装模式，默认的安装也只能满足OLTP的需求。现在的Oracle确实能够面对大多数的用户场景了。虽然Oracle从来不标榜自己是HTAP数据库，不过哪怕对于数据量还不是超大的OLAP场景，用上软硬一体的EXADATA，也还是挺能打的。反观国产数据库产品，虽然随便哪个国产数据库都敢号称自己是HTAP的，但是一旦遇到一些大型的复杂查询业务，大多数国产的交易型的关系型数据库也是会歇菜的。周末的时候看了卢月明老师推送的“明说三人行”和李飞飞的对话，在这期三人行中，飞刀谈到未来阿里云的HTAP是基于Polardb和ADB的超级组合，利用云的底层能力实现OLTP与OLAP数据的自动异步复制和行列转换，用户通过一个滑尺按照自己的需求自行设置其需要的复制延迟。这种行存转列存的手法实际上在业内已经有一定的实际应用了，PingCap的TiFlash就是在行存的基础上增加了一个自动生成的列存副本，从而支撑一些OLAP的场景。Oracle的MySQL Heatweave则走得更远，直接将INNODB中的行存数据生成分布式列的内存缓冲，用于OLAP的场景。并且将列存的数据进行了持久化，从而避免数据库重启后大量行列转化的开销。Heatweave的做法有点类似于飞刀说的Polardb+ADB的组合，还结合了飞刀说的PolarDB的轻量级HTAP支持的模式，那就是在行数据库中自动生成无持久化存储的列内存缓冲。这种技术早大规模商用是Oracle的in-memory database，在去年发布的谷歌AlloyDB里也采用了类似的实现。不管是飞刀的Polardb的未来形态还是Oracle的Heatweave抑或是谷歌的AlloyDB，这些都是软硬一体的解决方案，特别是延时滑尺这样的强要求的存在，都决定了这一切都只能在公有云上实现，而无法作为通用软件产品直接向用户提供。这也意味着这些解决方案都无法解决特别广大普通用户所面临的问题。实际上普通用户所需要的功能并不是所谓高大上的HTAP之流，而是能够在自己私有部署的环境中能像Oracle一样解决日常应用中的大多数问题而已。数据库的容量并不会太大，几个TB到二三十个TB就基本上到头了。SQL的复杂度也不会嵌套是多层子查询，仅仅就是一些简单的三四张业务表的关联。这些业务以前在Oracle上都跑得不错，为什么到了国产数据库就必须用那么高大上得解决方案才能解决呢？实际上要做到这些高大上得设计，目前对于国产数据库厂商来说只要投入到位了，还是能够解决底层的问题的，作为技术目标是有实现的可能性的。而做出一个像Oracle这样的CBO优化器，并不完全是技术问题。已经修修补补了二十多年的Oracle CBO优化器在架构设计上可能已经远远落后于目前的一些国产数据库，但是优化器的能力不仅仅取决于架构与技术先进性，而在于常年的业务积累。Oracle知道上万种我们的数据库厂商不知道的SQL执行遇到性能问题的特殊场景，而我们的数据库厂家并没有如此深厚的积累。这种积累不是通过设计与研发能搞定的，需要时间去沉淀。只有在长期的数据库应用实践中不断地遇到问题，才能不断地解决问题，提升CBO的能力。Oracle SQL解析器的几千个FIX以及数百个参数就是这么一点点的积累出来的。特别是Oracle不仅仅是一个数据库厂商，还是全球第二大的ERP厂商，ERP应用具有为复杂的业务关系，因此其复杂SQL的应用场景是为丰富的，它可以为Oracle数据库提供大量的应用案例，加速Oracle CBO优化器的提升。因此如果你的系统的SQL特别复杂，想要找一款能够适应你的今后业务需求的数据库产品，那么咨询那些云厂商没啥用，因为公有云上跑的不是比较小的数据库就是大多数复杂问题靠应用解决的互联网应用。这个问题，去咨询用友、金蝶等ERP厂商的技术人员可能是更靠谱的。虽然在做XC替代的时候我们找不到完美的数据库产品，不过这也不影响我们的XC工作。通过应用修改去避开数据库的坑，或者使用群殴战术打群架，抑或是先用比较高配的硬件去顶一下，都是可行的方案。如果国产数据库的客户群体丰富了，那么再过上三五年，水平自然也就提上来了。