数据库的“江湖”，一向以“门派”众多而著称。一个萝卜一个坑，一种数据类型或者一种业务类型对应一个数据库“门派”的方式，也是由来已久。
这种泾渭分明的派系逻辑，清晰的边界，很容易构筑竞争壁垒，造就顶级的名门大派，如Oracle数据库就是典型的的OLTP业务模型，通过在企业核心 IT 业务系统中广泛应用，一度成为数据库江湖的“盟主”，风光可谓一时无两。
但随着云时代的到来，乃至业务智能化的风靡，面向大量数据分析的OLAP流派逐渐崛起。传统数据库江湖开始“分庭而治”，但客户的业务场景的多元化，又带了数据处理的复杂化。客户难免要同时与多个“门派”交流，对复杂性的畏惧感，也是很多企业客户对数字化转型望而却步的原因之一。
《射雕英雄传》当中，“老顽童”周伯通被禁闭在桃花岛的地洞里，创出了一门武功叫左右互搏术。这门左右两手可以同时使用不同招式的武学，对于战斗力加成几乎是翻倍的。
客户数据处理需求的变迁，其实也需要一种“左右互搏”的武学，能够将两大流派融汇，做到内外兼修，一体化融合。
OceanBase就是这样一位“武学高手”，4月20日在第二届OceanBase开发者大会上，OceanBase发布4.3版本，进一步加强TP/AP一体化，在其“关键业务负载”的一体化战略上迈出了坚实一步。
OLTP与OLAP走向融合的业务逻辑
一家企业由小及大，不断成长的过程，其实就是数据价值不断被挖掘和使用的过程。
OLTP为代表传统的关系型数据库的主要应用主要是基本的、日常的事务处理，所以每家企业在信息化初期都会诞生OLTP的场景需求，企业最常见的业务系统如ERP，CRM，OA等系统都属于OLTP的范畴。
应该说OLTP作为事务性非常高的在线系统，承担了大量小事务以及小查询的高并发，且保证了足够快的响应时间，对银行等行业的关键业务数字化建设起到了汗马功劳。
而随着数据量的不断激增，企业数字化不会只满足于事务性的工作，需要利用积累起来的庞大数据做总结分析，并为企业发展做决策支持，这时候就产生了OLAP的需求。相比于OLTP而言，OLAP系统每一次读取的数据量更巨大，一些复杂的查询，甚至要读取上百万条数据，使用者主要是企业决策人员，面向分析决策的能力。
由于OLTP所产生的业务数据分散在不同的业务系统中，而OLAP往往需要将不同的业务数据集中到一起进行统一综合的分析，这时候就需要根据业务分析需求做对应的数据清洗后存储在数据仓库中，然后由数据仓库来统一提供OLAP分析。
所以，OLTP是数据库的应用，而OLAP则属于数据仓库的应用。这两者之间，在过去很长一段时间里，还是泾渭分明的不同“门派”。
如果从企业成长的角度看，当一个企业在业务发展初期，数据的规模比较小，事务性的工作比较多，一般会利用OLTP关系型数据库来支撑业务。但随着业务规模逐渐增大，数据量和数据的形态变得更加丰富，通常会使用OLAP数据仓库，来做数据的优化、治理和数据的各种应用。
不难看出，从业务发展的逻辑上看，这两大场景出现在企业不同的发展阶段，承载了不同的业务形态，并不是对立关系，而应该是并行或者是融合的。
这也是OceanBase 4.3版本，强调TP/AP一体化架构的原因。这也意味着，行业关键业务场景，可以通过TP/AP一体化的高性能融合，来支撑面对两大场景融合下的业务诉求。
三问OceanBase:一体化到底能带来何种价值？
当然，要让客户和开发者认可TP/AP的一体化架构，OceanBase其实还有很多疑问需要直面。
第一个问题：为什么是TP/AP的一体化，而不是HTAP？
过去两年HTAP数据库异常火爆，从Google Cloud 发布HTAP的云数据库 AlloyDB开始，几乎所有的数据库厂家和云大厂都发布了HTAP数据库产品。而HTAP数据库就是为了解决AP和OP混合场景下的应用需求而来的。
那么，为什么OceanBase不直接叫HTAP数据库，而是强调TP/AP的一体化呢？这是因为，OceanBase未来的愿景，不止于HTAP。OceanBase CTO 杨传辉说“HTAP也不是万能的，它应用的范围也是相对有限的，比较适合数据量在几百个GB到几百个TB的场景，如果数据量再大也难以承载。”而OceanBase是将分布式的TP能力直接融合到AP系统里，做出更好、更实时，且对开发者更加易用的新型实时分析数据库。未来，无论是TP、HTAP、AP场景，客户都可以考虑选择使用OceanBase。
第二个问题：一体化融合能够为用户带来什么实际价值？
传统数据库把业务分成 OLTP 和OLAP，并通过 ETL 定期将数据从 OLTP 数据库抽取到 OLAP 数据库，这种方式带来了两个问题：延迟和复杂度。延迟等于牺牲了部分数据库性能，而复杂度就代表着更高的成本。
OceanBase的一体化架构，则是追求分布式架构下的极致性能与最佳成本。既能实现同等硬件条件下，比主流单机数据库提供更好的性能，也能实现分布式架构下事务处理和实时分析的最佳性能。此外，统一的技术栈，也最小化了管理成本，大大降低架构成本、存储成本、运维成本、管理成本。
另外，根据国际咨询机构Forrester《OceanBase总体经济影响报告》的数据显示，采用OceanBase后，企业数据存储空间节约70%、服务器资源节约85%、平均每注册用户数据库成本节约50%，且呈现逐渐成本节约递增的趋势，越用越便宜。
第三，OceanBase过去长期专注于TP，那么新版本会在AP上做哪些补强？
首先是列式存储。列式存储是AP数据库的关键能力之一，但列存存储引擎在实现上往往假设数据随机更新不频繁，以维持列存组织数据的静态性。当系统面临大量随机更新时，往往会引发性能问题。OceanBase LSM-Tree架构的引入恰好解决了这一挑战，通过将基线数据和增量数据分别处理，有效应对了随机更新带来的性能问题。
其次是向量化引擎增强。OceanBase 在4.3版本上实现了向量化引擎2.0版本，将数据格式描述改为Column，避免了ObDatum维护所带来的内存使用、序列化和读写访问开销。
最后是新增的物化视图功能。物化视图是支持AP业务的一个关键特性，通过预计算和存储视图的查询结果，减少实时计算来提升查询性能，简化复杂查询逻辑，常用于快速报表生成和数据分析场景。
也正因为有如此多基于AP场景的技术创新，让OceanBase敢于喊出“OLTP PLUS”，并能够通过一体化融合带给客户真正的价值。
化繁为简，紧扣数据库行业发展趋势
我们常说，IT技术永远不能取代业务，而是业务的辅助，所以越是简单的IT，越能帮助企业发挥业务“辅助”的特色。
所以，无论企业应用对数据的需求是分析、实时性，还是一致性，都不要过于复杂，简化本身也是最贴近用户的做法。在信息化时代，数据库本来是一个“简单”的技术。数据库的稳定性和高性能，带给企业是一种近乎“无感”的体验。
即便到了数字化和智能化的今天，企业也不希望再度面向“复杂”，所以化繁为简是为正道。
诞生之初时起，OceanBase 就将一体化作为最“自然而然”的默认选项，如果从用户视角来描述，一体化的本质是用一个数据库解决 80% 的问题，将 OLTP 与OLAP 的能力融合在一起，同时处理复杂和简单查询，还能应对任意大小规模的数据量，支持不同的数据类型、模态。
从这个意义上讲OceanBase的一体化战略，本身就是一种从客户需求角度出发的逻辑。数据处理走向一体化融合，也遵循了简化数据库应用的原则，这将是数据库行业发展的必然趋势。
“用一个数据库满足客户80%的数据库场景需求”，这不仅仅是OceanBase的“愿景”，更是通过技术体系创新和战略创新，要实现的切实目标。
