OB的未来发展方向是什么？主要竞争对手是 Oracle、MySQL、PG，还是 TiDB 这种国产分布式数据库？感觉 OB 的产品定位也不是很清晰明确，有点混乱，一开始是对标替换 Oracle、MySQL，最近 4.0 的像最开始的多租户、PL/SQL、存储过程、Oracle/MySQL模式，以及 4.0 新增的单机分布式一体化、MySQL 的预处理语句、在线 DDL、LOB增强、表锁与死锁检测、ASH 等功能，整体看来还是模仿 Oracle、MySQL，在做兼容它们的东西以抢占它们的市场份额。可另一方面看，增加向量化引擎、KV 引擎等多个异构引擎的支持，又像是在向 TiDB 看齐。即便做 HTAP，又如何与一些由多个开源技术组成的解决方案厂商竞争呢？ 毕竟中小企业居多。这里又引出OB 面向的主要客户定位不清的问题了。从OB 做 Oracle 和 MySQL 兼容看，主抓的是金融客户；从单机分布式一体化看，是面向中小型企业。**多租户、公有云是引导让客户用云，但银行、证券、保险等金融机构不缺钱，人家有自己的云，而且内部员工的技术能力也很强，出于安全考虑，不会全部使用 OB 的公有云，最多加到混合云里，而且出入政治、国家级安全方面的考虑，还很可能有采用国企通讯商的云或者与国企合办子公司来提供服务的硬性要求；而数量庞大的中小企业，主要考虑因素是成本，能用开源免费的绝不多花钱，尤其是新冠疫情加经济下行周期的影响。据我了解，像 Oracle 的公有云，在国外反响也不好，市场份额很少，反倒是 AWS、Azure 提供的基于开源数据库的云上数据库解决方案卖得更好，同样，国内的阿里云、腾讯云也是如此。
1 个赞
一些个人理解：做 Oracle 兼容主要是面对金融客户，开源相关的 MySQL 兼容以及 4.0 的单机分布式一体化都可以算是面向中小企业的。至于 OB 的产品定位，我觉得不是说没有明确的对标产品就等于定位混乱，OB 的定位是支持 HTAP 的企业级原生分布式数据库，做的功能也都是基于这个定位结合一些业务场景去做的，不存在向 TiDB 或者其他产品看齐，只能说在解决某些问题的时候会有一些和其他产品类似的方案和实现。同样的，跟OB的能力或者应用场景有交叉的产品在一定程度上都可以算是竞争对手，这个也肯定不止一家。
1 个赞
矛盾点
详细列举一下我认为的矛盾点：
-
我觉得，OB 一方面为了金融客户不断增加对传统数据库兼容的同时，一边贴近云原生这本身就是矛盾的。费劲吧啦设计出来兼容这些功能，结果没有人用，岂不是再做无用功？
使用数据库的主要是应用开发人员，他们很多都喜欢让数据库只负责读写数据，让应用来实现业务逻辑，所以他们非常抵触 PL/SQL、存储过程、SQL 高级语法等数据库高级功能，毕竟很少有人愿意学习被认为过时的新知识。在云原生、低/无代码、轻应用的趋势下，现有的应用都要基于上云满足云原生而做一些满足云原生应用开发规范（比如 12-factor）的改动，更何况是更底层的数据库软件。 -
做了分布式事务、大事务、复杂事务的功能，却又不建议使用，尽量使用本地事务、小事务，不矛盾吗？
比如分区，以对范围分区表进行单表读写为例，一张表的分区副本的 Leader 可以全部分布在一个 Zone 的一个节点上，执行本地事务，在不考虑压缩和读、写、空间放大的情况下，这样会消耗至少三倍存储；也可以分布在不同 Zone 的不同节点上，执行分布式事务，这样会带来数据分布不均匀，范围查询跨节点甚至跨 Zone 的问题，不知道还会不会有行迁移、行链接问题。 -
不管是 OLTP 还是 OLAP 都需要多表关联，而 HTAP 分布式数据库在这方面做的并不是很好，也是不建议多表关联，那 OLAP 的能力提现在哪呢？ 通过应用来处理多表关联？亦或是创建一个纯列存格式的副本，使用基于新一代CPU的SIMD功能的向量化引擎来加强 OLAP 能力？使用压缩编码的行存的副本同步将数据给列存副本的延迟问题也需要处理。这和传统的ETL加工再转存到数仓、数据集市的方式并没有本质不同，都存储了多份原数据，并不像各厂商宣称的那样“一份数据，随处可用”。
还有，OLAP 并不是只有数据库写 SQL 能做，其他编程语言以及用它们开发的应用接口、查询语言也能做，而且可能比 SQL 做得更好。SQL 是面向集合的，某些分析类需求需要编写大段复杂 SQL 语句实现，而用新型查询语言往往可以更简短、快捷地实现。
暂时先写这些矛盾点，其他的以后想到再补充。
其他疑惑
HTAP、云原生、分布式、高可用、弹性伸缩、无共享、全对等，这些基本是各厂商宣传时的共性特点。我认为，如果要在一个 DBMS 里实现完善的 HTAP，那这个软件本身的臃肿、冗余程度一定会很高，因为我既要满足偏重 OLTP 和对数据一致性、安全性有严格要求的用户需求，又要满足偏向 OLAP 用户的需求。可通过增加很多系统参数、变量实现，但 DBMS 的配置会变得极其复杂，且为实现这些功能而设计的代码也会使软件大小变得很大；如果分裂成不同产品，其底层存在共有代码，如果有大版本改动（尤其是不向后兼容的版本更新，比如这次的 3.X 到 4），维护各分支的成本也会加倍。
OceanBase 认为，真正的 HTAP 要求先有高性能的 OLTP，然后在 OLTP 的基础上支持实时分析。OceanBase 通过原生分布式技术提供高性能的 OLTP 能力，真正通过“一个系统”同时提供事务处理和数据实时分析能力，“一份数据”用于不同的工作负载，从根本上保持数据的一致性并最大程度降低数据冗余，帮助企业大幅降低总成本。
由上文的引用可知，OB 的 HTAP 实现过程也是先实现 OLTP 功能，在此基础上再实现、优化 OLAP 功能。充分利用向量化引擎的优势必须使用列存，而正常微块是行存的，这样来看实际上也并不是“一份数据”，不考虑压缩的情况下（你有压缩技术，人家也有压缩技术），降低冗余、总成本更是无从谈起。
某种程度上讲，做 DBMS 软件与做数据中台、数据湖软件和开源产品的中间件、解决方案的目标是一致的，都是为了打通各数据源，将业务数据高度共享交互，最终提供对用户透明的 HTAP 的能力。只不过 DBMS 软件将解决方案内嵌了，从而达到更好的技术可靠性，但加重了开发、维护成本。
此外，分布式数据库的分布式一致性问题影响了事务一致性，导致更长的延迟和数据一致性问题。2PC 的缺陷导致依然无法解决协调者单点故障问题，和同步阻塞、网络异常导致的数据不一致问题。OB 的 RootService 应该也存在类似的问题吧？之前听 OB 员工说 OB 对 2PC 做了优化，解决了它的缺陷，但在官网文档里并没有看到相关内容。类似的分布式事务导致的数据异常，无法满足金融、银行、传统行业企业客户对数据安全、可靠、一致、响应快的要求。 即便近年来技术得到了发展，CAP 几乎三点都可满足，但 CAP 提出者所强调的是 100% 的可用性，这仍是无法实现的。结合 PACELC 理论，设计分布式数据库时必须考虑 A 与 C 、L 与 C 的权衡取舍。这里 OB 可能会拿蚂蚁集团在支付宝等业务上的实践举例，但这些例子也是存在很多问题的，比如我最近遇到的“双十一期间部分支付宝卡包中的红包在满足抵扣规则的条件下仍无法使用的问题”，反馈给客服后，支付宝上方出了个滚动公告“双十一期间部分红包卡券无法使用，我们对此深感抱歉，敬请谅解”。。。
1 个赞
-
对于提到的应用开发人员不喜欢一些功能，按我的理解这里可能更多的是指一部分互联网用户，我个人并不认同它们是过时的知识，实际情况也不是没人用。OceanBase作为一个基础软件产品，肯定也不能因为一部分用户就选择放弃一些能力，进而失去另一些可能的潜在用户。保持对Oracle/MySQL的高度兼容性对于有平滑替换需要的用户是非常有意义的，这也是体现OceanBase产品竞争力的一部分。在云原生的方向上，OceanBase目前在我看来还处在比较初期的阶段，在以后发展的过程中不可避免会遇到一些跟原有设计相冲突的地方，这是肯定要面对的问题，也一定会有办法解决，只是需要一些时间。
-
分布式事务在功能上得到了实现，但是它带来的开销对于相当一部分用户的业务场景来说是不可接受的，所以不建议使用，我个人理解这里不存在矛盾，一个功能不可能适合所有人，按需使用是很自然的选择。对于存储成本，OceanBase实现了非常高的压缩率，因此跟传统数据库相比不会带来额外的成本。
-
OceanBase是行列混存的，确实是只有一份数据。至于提到的其他语言查询，OceanBase本身其实也提供了OBKV的服务形式，目前可以通过 Java、Rust来进行查询。
3 个赞
个人回答一下, 非官方观点
最大的问题 “OB 的未来发展方向是什么”, 然后再对每个feature 背后的逻辑做一个梳理, 最后再回答你一些其他的问题如你认为矛盾的地方.
OB 未来的发展方向是什么.
如果一句话来回答
企业版 --》 面向未来的oracle
社区版 --〉 面向未来mysql
“面向未来的oracle/mysql” 里面的oracle 和mysql, 只是表达我们想去兼容oracle 的语法和mysql的语法, 兼容现成的oracle 生态和mysql 生态, 核心的观点是面向未来, 做下一代的数据库.
今天oracle 的数据库能力, 已经吊打一大片数据库, 比如mysql, postgres, 甚至一些著名的商业数据库(这里不说名字了).
做“多租户、PL/SQL、存储过程、Oracle/MySQL模式，以及 4.0 新增的单机分布式一体化、MySQL 的预处理语句、在线 DDL、LOB增强、表锁与死锁检测、ASH ” 这些特性只是追上oracle 的能力, 但我们追求的不仅仅是oracle 的这些能力, 还有更多, 就像oceanbase 这个名字一样, 前面有一个ocean, 意味着我们要处理海量的数据, 而不是像过去oracle 一样存在单机瓶颈, 另外我们处在一个云的时代, 我们会将我们的产品和云做更好的贴合, 云原生意味着我们有更好的弹性.
回答
增加向量化引擎、KV 引擎等多个异构引擎的支持，又像是在向 TiDB 看齐。
- 向量化引擎和kv 引擎, 10多年前就出现了, 这些技术很早就出现, tidb 只是其中的一个技术实现者, clickhouse, greenplum, starrocks, doris, hologres, adb这么多数据库都在使用向量化技术, 难道说他们都是tidb的学习者
- 你可能对oceanbase的技术不是很了解, oceanbase 的sql 执行引擎和存储引擎就一个, 只是sql 执行引擎具备向量化执行的能力, 存储引擎具备kv 的接口而已, 不是一个异构引擎. 很多存储引擎底层都具备kv 存储能力, 而ob 存储引擎恰好也具备这个能力
回答
即便做 HTAP，又如何与一些由多个开源技术组成的解决方案厂商竞争呢？
其实不需要回答如何竞争, 回答的应该是如何更好的满足用户的诉求, 有多个开源技术组成的方案, 他的优势是短平快, 具备一定的灵活性, 但在做数据库这个领域, 在tp 场景下追求的是稳定性和极限rt, 需要将一切不稳定因素给控制住, 开源技术引入会带来大量不可控的因素以及因为各个系统的对接, 需要大量的拆包和封装, 它的效率一定不是最优. 注定它的性能不会很出彩.
回答
ob 客户定位不清
今天oracle 在金融行业大面积使用, 试问一下oracle 如果免费不用钱, 你觉得中小企业会用oracle吗?
今天oracle 的能力已经跨越了金融用户和中小企业, 其实OB 也是这样的
5 个赞
回答1
引用你的回答
增加向量化引擎、KV 引擎等多个异构引擎的支持，又像是在向 TiDB 看齐。
- 向量化引擎和kv 引擎, 10多年前就出现了, 这些技术很早就出现, tidb 只是其中的一个技术实现者, clickhouse, greenplum, starrocks, doris, hologres, adb这么多数据库都在使用向量化技术, 难道说他们都是tidb的学习者
- 你可能对oceanbase的技术不是很了解, oceanbase 的sql 执行引擎和存储引擎就一个, 只是sql 执行引擎具备向量化执行的能力, 存储引擎具备kv 的接口而已, 不是一个异构引擎. 很多存储引擎底层都具备kv 存储能力, 而ob 存储引擎恰好也具备这个能力
这块是只针对国产数据库市场说的。国内外应用环境有很大不同，不只是开发、使用习惯，技术栈，用户规模，还有政策红利等因素。再加上 TiDB 和 OB 目前位列国产数据库前二，所以我说的是“向 TiDB 看齐”。我也知道 TiDB 是学习 ClickHouse，GreenPlum ，根本没有师傅徒弟搞混淆的意思。对于两个数据库产品，我并没有特别的喜好和偏见，而你的回答似乎有所导向，按你的话说，难道 OB 就不是基于某个国外的产品改出来的吗？
其实很多近些年大火的技术都是几十年前就出现的技术了，不止数据库相关技术，我们与国外的差距仍然很大，我个人认为，单就数据库领域，国产数据库与国外数据库巨头的差距还有十到二十年的差距，但在新兴赛道上大家的起点相同，国产数据库存在“弯道超车”的可能。
引用你的回答
oceanbase 的sql 执行引擎和存储引擎就一个
我是不太了解 OB 。MySQL 模式和Oracle 模式都采用的是一个 SQL 引擎？下图中为什么 SQL 引擎里画了多个，是产生了歧义导致我理解错了？
源自白皮书《oceanbase-native-distributed-database.pdf》-OceanBase 产品体系
回答2
引用你的回答
其实不需要回答如何竞争, 回答的应该是如何更好的满足用户的诉求, 有多个开源技术组成的方案, 他的优势是短平快, 具备一定的灵活性, 但在做数据库这个领域, 在tp 场景下追求的是稳定性和极限rt, 需要将一切不稳定因素给控制住, 开源技术引入会带来大量不可控的因素以及因为各个系统的对接, 需要大量的拆包和封装, 它的效率一定不是最优. 注定它的性能不会很出彩.
这个回答比较普遍，和我能想到差不多，我问这个问题的目的想听到一些 OB 在 HTAP 方面特有的优势。和“Oracle、MySQL 反复强调了它们是专为 Mission-Critical 应用设计的”所解释的差不多。
另外，组合使用开源产品并经过实际业务系统多年考验后形成的解决方案，效率一定不是最优，注定性能也不是很出彩？DBMS 很多时候也只是把新（开源）技术和理论整合重构实现到其内部罢了，兼容性问题由 DBMS 解决了，与前者并没有本质上的不同。
A3
引用你的回答
ob 客户定位不清今天oracle 在金融行业大面积使用, 试问一下oracle 如果免费不用钱, 你觉得中小企业会用oracle吗?
今天oracle 的能力已经跨越了金融用户和中小企业, 其实OB 也是这样的
第二句，你说“今天oracle 的能力已经跨越了金融用户和中小企业”，表达了中小企业也在用 Oracle ；第一句，你“试问一下oracle 如果免费不用钱, 你觉得中小企业会用oracle吗?”，我回答当然是会用啊！这两句本身就无法逻辑自洽，Oracle 收费中小企业都用呢，免费了不更得用了（当然抛开政治因素）？
面向金融，但商业银行的核心业务上目前还是很少有用 OB 的吧？目前还只是在蚂蚁集团内部和地方银行在用。就昨天，像建行这样的大行，转账交易核心系统出问题上了热搜，可见安全性方面还有待提升。银行、金融注重的是稳，安全第一，同时对响应效率有一定要求。而国产数据库目前都只注重 RDBMS 的基础功能开发和大数据分析、高可用、运维部署平台、可视化，对备份、审计、加密等方面投入的资源不够。比如，OB 的审计功能，我记得之前测试过 3.X ，似乎只有 Oracle 模式的租户具有一定的审计能力，MySQL 租户默认禁用审计账户，开启了似乎也只是一些很基础的开关机审计。有个北京金融科技产业联盟可以做金融行业认证的，想要入局金融，过审这个有一定的说服力。
至于金融、政务、泛互联网这些行业的客户量与营收情况，我想贵公司一定有统计。我好奇的是，客户数量、企业的上云需求，这些在市场的真实表现如何？面向未来，功能完善强大无疑是好的，但结合现实，总归有个轻重缓急。我觉得从一个产品的大版本更新日志便可看出短期未来走向，了解新的大版本的侧重点。而 OB 4.0 的，我看了感觉并不是很清晰。
我觉得，OB 一方面为了金融客户不断增加对传统数据库兼容的同时，一边贴近云原生这本身就是矛盾的。费劲吧啦设计出来兼容这些功能，结果没有人用，岂不是再做无用功？
使用数据库的主要是应用开发人员，他们很多都喜欢让数据库只负责读写数据，让应用来实现业务逻辑，所以他们非常抵触 PL/SQL、存储过程、SQL 高级语法等数据库高级功能，毕竟很少有人愿意学习被认为过时的新知识。在云原生、低/无代码、轻应用的趋势下，现有的应用都要基于上云满足云原生而做一些满足云原生应用开发规范（比如 12-factor）的改动，更何况是更底层的数据库软件。
可能你在产品线, 对ob 的研发流程不是很熟, 今天ob 已经完全面向用户, 每个功能都会有内部评审, 会审视在什么场景下会被使用, 背后root cause是, 我们今天来自客户的需求太多了, ob 已经上线400多位用户, 每天提过来的需求, 已经把我们研发给淹没了, 我们研发已经是供不应求.
坦白讲, 我们做为研发, 很多时候, 真的想去做一些比较炫酷的东西, 不过, 今天ob 当前阶段很难这么去做.
PL/SQL、存储过程、SQL 高级语法等数据库高级功能
金融企业很多在做数据库升级, 他们需要这些功能, oracle 有2000w的存储过程, 太多了, 我们只是完成了他们常用的一部分.
1 个赞
做了分布式事务、大事务、复杂事务的功能，却又不建议使用，尽量使用本地事务、小事务，不矛盾吗？
有了分布式事务, 大事务, 复杂事物 是让这个数据库具备处理海量的数据, 复杂的场景. 没有分布式事务, 那处理能力只能是单机事务, 处理的数据量始终是受限的.
本地事务性能肯定是比分布式事务要强, 这是毋庸置疑的事情, 所以站在用户的角度, 肯定是建议用户尽量使用本地事务, 小事务. 另外打一个比方,
我一顿能吃2kg 西瓜, 但我最舒服, 最健康的方式,可能是400g 西瓜, 那肯定鼓励的是让我吃400g 西瓜. 而不是顿顿2kg 西瓜.
不管是 OLTP 还是 OLAP 都需要多表关联，而 HTAP 分布式数据库在这方面做的并不是很好，也是不建议多表关联，那 OLAP 的能力提现在哪呢？ 通过应用来处理多表关联？亦或是创建一个纯列存格式的副本，使用基于新一代CPU的SIMD功能的向量化引擎来加强 OLAP 能力？使用压缩编码的行存的副本同步将数据给列存副本的延迟问题也需要处理。这和传统的ETL加工再转存到数仓、数据集市的方式并没有本质不同，都存储了多份原数据，并不像各厂商宣称的那样“一份数据，随处可用”。
还有，OLAP 并不是只有数据库写 SQL 能做，其他编程语言以及用它们开发的应用接口、查询语言也能做，而且可能比 SQL 做得更好。SQL 是面向集合的，某些分析类需求需要编写大段复杂 SQL 语句实现，而用新型查询语言往往可以更简短、快捷地实现。
oltp 和olap 需要多表关联, 为啥就得出结论 HTAP 分布式就做的不好, 反而我过去经验看, 反而 分布式在HTAP 上更有优势.
我个人观点:
oltp 和olap 从sql 上没有多少区别, 区别的是数据量上, 同样一个2表join, 如果数据量小, mysql 直接可以干, 很多人就会认为它是tp 查询, 但如果它的数据量上了2个量级, mysql 已经扛不住了, 甚至oracle 也扛不住了, 这个时候, 大家可能认为它是olap 查询, 这时可能只有分布式数据库才能处理. 所以我个人观点就是htap 就是数据量到了一定的数量后业务需求, 这个时候, 分布式可能更有优势.
olap 引擎往下延伸一下或者数据量再大一圈, 是不是就进入大数据领域, 我们看看大数据领域, 全是分布式架构, 分布式引擎, mpp 引擎, 很少看到单机引擎, 这是不是从另外一个侧面, 说明分布式在这块更有优势.
2 个赞
HTAP、云原生、分布式、高可用、弹性伸缩、无共享、全对等，这些基本是各厂商宣传时的共性特点。我认为，如果要在一个 DBMS 里实现完善的 HTAP，那这个软件本身的臃肿、冗余程度一定会很高，因为我既要满足偏重 OLTP 和对数据一致性、安全性有严格要求的用户需求，又要满足偏向 OLAP 用户的需求。可通过增加很多系统参数、变量实现，但 DBMS 的配置会变得极其复杂，且为实现这些功能而设计的代码也会使软件大小变得很大；如果分裂成不同产品，其底层存在共有代码，如果有大版本改动（尤其是不向后兼容的版本更新，比如这次的 3.X 到 4），维护各分支的成本也会加倍。
就像你说功能越多, 数据库也会越来越复杂, 但站在ob和数据库的角度是期望 “复杂留给自己, 简单留给用户”.
另外, oracle 2000万行源码, 2000万行存储过程, 复杂都留给了oracle, 简单给了用户, ob 也是向这个方向发展.
有一些上下文, 可能需要我们铺垫一下, 很多htap 方案是一套oltp一套olap 2套数据库, 而ob 提供的一套方案来做这件事情, 节省了一套数据库, 所以是降成本的.
可能让你误解了, sql 引擎下有4个框, 分表表示支持不同的功能, 第一个框表示 同时支持oracle 模式和mysql 模式, 第二个框表示支持lob, gis, json, kv 等方式, 第三个框表示支持并行执行, 第四个框表示支持向量化执行和算子下推.
是的，您说的很对。即便开源这套玩法，新产品在推广使用初期很多都是搭钱积攒客户，免费试用，收集用户需求。开源带来了更多的用户需求，需要需求分析人员和研发研判需求的合理性和可行性等。国外比较大的数据库厂商的研发团队往往有上千人，不知 OB 的研发团队规模目前是多少？
存储过程这点，我其实是拥护者，以前也做过 PL/SQL 开发的工作。这东西虽老，但很多金融、保险、通讯公司都还在用，也有其用的道理。相较于业务代码，这种数据库内部的（可以叫“原生”）预编译程序，运行效率一定是更高的。而且 SQL 的简易性使其更受业务人员青睐，只需学习一点过程化编程的知识，便可轻松写出 PL/SQL 块、包、存储过程、函数。
可我和很多大小厂的研发同事都聊过，几乎没有喜欢用的。换数据，金融客户有大量的存储过程需要转移处理，现在为了效率和兼容性做平稳过渡，可考虑到上云、云原生应用、微服务这些热点发展方向，没准费劲吧啦地做好了存储过程完全兼容，刚迁移过来没几年，企业对云原生这块又有要求了，还是得放弃存储过程，把它们的逻辑通过云原生应用程序实现。我不是做市场和管理的，不清楚 为了市场份额而做行业巨头产品的兼容 和 强制要求客户按我的标准来使用 的权衡取舍。但我觉得，一个足够自信、有底气的公司，积极参与到行业标准的指定上，是可以不用做 非标准以外 的兼容的。比如 SQL 标准，我只需兼容 ISO/ANSI 最新 SQL 标准即可，为什么要去创造多个模式去兼容其他主流数据库产品的 SQL 方言？
坦白讲, 最早我和您想法一样的, 自己推一个标准, 难道不是更好吗?
后来出去和客户交流后, 就被打脸了, 很多用户第一句是, 我这个系统能否平滑迁移过来.
而且不是一个, 两个用户这么说, 是几乎所有的用户这么说,
而且部分用户回答更直接, “我就希望你支持mysql, 哪一天我不用你的系统, 我还能换成mysql或者其他兼容mysql的系统”
2 个赞
我觉您的问题挺好的, 我可能没有回答清楚
今天oracle在金融行业大面积被使用, 如果oracle 不花钱, 不出意料的话, 中小企业基本上都会用oracle. 这说明了oracle 的数据库的能力已经覆盖了金融和中小企业, ob 未来期望也覆盖中小企业和金融企业.
ob 4.0 后, 确实产品方向向单机倾斜了一些, 向中小型企业靠拢了, 我们期望能覆盖更多的用户, cover 更多的场景, 本质是让ob 的内核能力变强, 另外金融的场景下很多也有小型化的诉求, 2边定位上其实也没有那么大的冲突.
1 个赞
OB 已经上线400多家企业, 推荐您下一下我们白皮书, 上面有列一些清单
https://www.oceanbase.com/whitepaper
您如果用企业版是有审计能力的, 社区版这块是没有这个功能
我当时用的是别人安装的OB 3.X 企业版，审计能力也就是有的程度，实用性上差点意思。
rootservice 是整个ob 最重要的角色之一, 它是完全保障高可用的,
每个zone 一个rootservice, 3个zone 就会构成一个paxos group, 保障高可用.
而且底层rs 的高可用和普通partition 是完全类似, 几个zone 就有几个副本, leader 可以任意执行命令切换.
rootservice 介绍
https://www.oceanbase.com/docs/community-observer-cn-10000000000449617
分布式事务导致 HTAP 中的TP 存在一致性和延迟问题，AP 上使用分布式没错，数据量上来了使用分布式也没错，大数据领域使用也没错。但现在的问题是，HTAP 分布式数据库目标是既替换掉 TP 的传统集中式数据库，又替换掉 大数据。TP 与 AP 的兼容性能做到何种程度，是 HTAP 评级的关键。
老的架构体系里，完全可以只用 Oracle 数据库做 HTAP，Oracle 的分布式数据库就是使用 DB Link 实现的。 时至今日，仍然有一些企业会在 DWD，DWS以及DM层使用 Oracle 来完成 AP业务，而且用的还是 11g 。HTAP 也不是什么新概念，只是换汤不换药的重新定义了一遍已有的东西。Oracle 在分布式数据库方面也做了很久了，dblink 需要 Join 的数据选择本地缓存还是远端缓存，本地缓存带来的快照过旧、临时表空间不足、Undo 表空间不足等问题，也是用户痛点。**我就遇到过某金融机构的技术负责人坚决不信 HTAP，说 AP 和 TP 不可能完美的共存，两个方向上总归有个侧重点，要么为了 TP 牺牲 AP ，要么反过来。**而大部分数据库厂商都是先做 TP，再做 AP，自然选择上就放弃了 AP 的一些能力。
而微块根据用户指定存储格式可以分别以 encoding 格式或者 flat 格式存储，encoding 格式的微块, 内部数据会以行列混合模式存储；对于 flat 格式的微块，所有数据行则是平铺存储。
OB 所谓的“行列混存”，和其他的行列混存还不太一样，其实还是行存，利用编码技术对定长列做了一定的编码以节约空间，并利于向量计算。同样，OB 所谓的“多个副本可以存储成多种形态”，也是“行列混存”，或平铺（flat，其实就是行存）存储。我之前对这块没有深入研究，看白皮书还以为是常规的行列混存呢！OB 支持纯列存格式吗？OB的默认存储格式是行存还是行列混存？还有，宏块不会出现行迁移、行链接的问题吗？
在 OceanBase 数据库中, 每个分区的基本存储单元是一个个的 SSTable，而所有存储的基本粒度是宏块，数据库启动时，会将整个数据文件按照 2MB 定长大小切分为一个个宏块，每个 SSTable 实质就是多个宏块的集合。
OceanBase 在企业版 3.2.3 全面实现了向量化引擎
如果我没记错，向量化引擎以前 OB 没有吧？否则也不会在 4.0 发布时特意强调了。所以我之前提到的“向XX数据库看齐”没错，增加功能提高竞争力嘛！向量计算这块大家都差不多。
我不太了解这块，两套的也是多副本中某一个或多个副本使用列存供 AP 使用吧？一套，压缩比平均能达到多少，如果按你们宣传中所说的 “Oracle、MySQL 的 1/4 ”来算，三副本每个副本也就是1/12，如果是使用 SAN 并采取必要的存储压缩手段的 Oracle RAC，OB 存储同样的数据只需要 1/12 的存储空间？
一套，跟 Oracle 的设计思路一样，但因数据量上涨导致使用 Oracle RAC 出现瓶颈无法满足大数据量的 HTAP 要求，加上国内去 IOE 浪潮下企业对升级 Oracle 意愿不强， 这才使得近年来国产数据库行业迅速崛起，从蓝海变为红海行业，出现百花齐放的格局。Oracle 除了不断升级迭代，也单独退出了其他的分析型数据、大数据产品。我了解到的某通讯商升级到 Oracle 18c 后反响也很不错，仍对 Oracle 赞不绝口。