序言
最近IDC公布了2023年分布式数据库在金融行业的市场份额报告，作为既涉及过国产数据库工作，又在金融行业继续从业的人，也是第一时间去阅读了这份报告。虽然我以前在银行短暂工作过2年，但是早已经是多年以前的事，所以银行板块的东西，大概浏览就过去了。而证券行业则是我重点关注的部分。
报告把保险和证券放到一起，一方面是这两个行业的市场占比比起银行来说都小很多，另一方面，也是因为业务类型和银行有着较大差异。不过一共涉及到的行业也就这三个，如果有机会，我还是希望有机会把保险和证券再分一次，我个人也想看看两个行业各自的比例。
考虑到公有云上的情况，我自己了解有限，还是把主要关注点放在了本地部署。而本地部署中，占据半壁江山的，恰恰是我最近一直在关注的OceanBase，以它作为切入点，来聊聊证券行业分布式数据库的几个发展和猜想。
新特性的测试
4月下旬，我在去上海看F1的间隙，从嘉定跑到七宝听了OceanBase的新版本发布会。作为大版本更新的4.3，新特性让我应接不暇，尤其其中几个新特性，让我都想尽快飞回北京，在测试环境部署一份，开始测试。心动不如行动，在回到北京以后，准备好环境，我就部署了一套4.3的集群，几个新特性基本上都体验了，大部分符合预期，少部分超出预期。
列式存储。过往OB都是行存，这就意味着更适合做交易系统，而对于报表来说，性能可能就没有那么完善。4.3引入列存之后，我先创建了一个租户，行存方式倒入交易系统的测试数据，接下来直接将数仓的ODS层建在了新租户的列存上。这种情况下，ODS层的查询建模以及ETL效率，比起对照组的行存，有着数量级的提升。利用ODS层来建设后续的DWD层或者DWS层，效率大幅提高，如果可以迁移到生产中，每天晚上从ODS到DWD这段耗时很长的任务，可以大幅缩短。
物化视图。很多逻辑上没有那么复杂的ETL，可以将ETL脚本里的SQL抽取出来，以创建物化视图的方式来实现。这是我在发布会现场的一个收获。过往的思维定势，大可以跳出来。通过定义物化视图的刷新参数，来确保ODS层的数据能够在经过计算之后导入到DWD以及DWS层。一方面节省了很多ETL任务和中间环节的监控，另一方面基于列存和物化视图的组合，查询性能也能有足够的提升。
旁路导入。严格来说，这是4.3.1才测的新特性，是我开始测试4.3.0有一阵子之后升级才开始做的。在券商有大量的离线CSV文件，比如沪深交易所和期货交易所定期推送的Level2行情，有时候业务部门需要我门帮忙导入做分析和测试，这时候少则几千个文件，多则几十万个文件。4.3.1这个功能增强之后，有了很多性能和使用便利性的提升。过去要写脚本以及各种纠错的过程也有了大幅缩减。尝试着将几十只股票过去3年的行情都导入列存租户，在交给同事使用，我开玩笑说，以后这事直接找实习生就行，不用我自己来了。
租户克隆。OceanBase的租户是严格的逻辑隔离，这一点我很喜欢。过往我曾经用PostgreSQL做过资源隔离，但是比较麻烦的是，实际上PG各个数据库之间，并不是严格的隔离，更多的是用grant和revoke隔离。OceanBase这个隔离，连资源分配都能控制住，加上克隆功能之后，可以快速将提前配置好的租户批量交给用户，用于不同的业务场景。比如同一份测试数据，有的场景要测试交易，有的场景测试清算，有的场景测试开户，不用再担心干扰。
未来的发展与猜想
对于OceanBase的未来在证券行业的发展与猜想，也是我这段时间一直在思考的。当然我还是要先说一句，距离我重新回到证券行业，刚刚半年多，几年的变化让我有很多东西需要重新学习和适应。这些发展和与猜想，很多可能已经实现了，有的是我自己拍脑子想的不一定正确。纯粹的抛砖引玉。
核心替换。因为我用的是社区版，所以Oracle兼容模式没有体验过。目前证券行业常用的几个核心交易系统例如恒生、根网等等，都是基于Oracle开发。如果OceanBase的RTO以及交易延时都能做到足够好，我相信核心替换并不是什么问题。要知道当年Oracle8i或者9i，也存在着各种各样的问题，并不是大家印象里11g这样一统江湖的威武。
极速柜台。极速柜台是这几年券商开始卷的新方向，在过去极速柜台的数据库里，MySQL占据了相当的比例。最近几年陆陆续续开始有了信创版本，甚至也有了国产数据库在这个领域的使用。我尝试着搜了一下，没有明确找到对应的客户案例，以目前我对OceanBase特性和性能的了解，我感觉这个场景以目前OceanBase的能力，是可以承担的。
高频读写。在处理行情数据的时候，高频读写是必备的。既有量化的各种策略，又有很多新行情数据的接入。目前很多券商会单独采购时序数据库，也有的会在内存里处理。我也看到了一些厂商对Clickhouse做了二次开发之后，加强时序能力来提供服务。我测试了OceanBase高频的读写的性能，让我感觉，OceanBase作为时序数据库来使用或者提供某一部分时序的服务，是有戏的。
数据湖。实际上，市面上已经有了一些分布式数据库，既具备了事务能力，又能够对对象存储提供服务。如果OceanBase能够在未来版本中对对象存储，以及对一些数据湖技术栈兼容，以现在的HTAP能力，是可以实现把交易数据——数仓报表数据——数据湖数据都管理起来的。当然这个脑洞比较大，本着打仗冲锋不是我的原则，给OceanBase开发团队提了一个问题，能不能实现，我其实并不清楚。
尾声
国产数据库经过这几年发展，已经让我看到了几个眼前一亮的产品。OceanBase就是其中之一。这既有阳振坤老师当年的高屋建瓴，领先于时代的思考和规划，也有着无数工程师和技术支持同行们十年如一日的耕耘。
开发一个数据库有时候和竹子有点像，可能80%的时间都在地面之下悄无声息地生长。直到破土而出的那一刻，才能被看到。大部分产品其实都在突破之前销声匿迹，能够破土而出被人所知的终究是少数。
期待OceanBase在5.0时代的时候，能够带来更多惊喜，也能为我们在证券行业提供更多成熟高效低成本的案例。
