KingbaseRAC
目录产品定位当前状态后续计划
设计的基本假设引入集群，是因为：单机的处理能力无法继续纵向扩展（scaleup）。单机的可用性方案依赖日志恢复，故障恢复时间较长经调查，很多应用中对数据的读访问比例远远高于写访问比例。也就是说：单机处理能力无法继续扩展很大程度上是由于读访问引起的。而对于写访问，一方面由于写访问的数量不高，另一方面由于主流PC服务器的处理能力已经比较强（CPU：32核，内存：128GB），单从处理能力的角度看，采用单个服务器应该能够管理好所有的写访问和数据。
设计思路基于上述假设，在KingbaseES基础上进行如下调整得出KingbaseRAC的总体结构：调整1（单机层面的调整）：读写分离将KingbaseES管理的每张表的数据都分成如下两部分：基线数据：指元组的基线版本，保存在在硬盘上；增量数据：指对基线数据中的元组进行增、删、改操作所产生的数据。这部分数据保存在内存中，并且定期/不定期的与基线数据合并，形成新的基线数据；相应的，当对表进行扫描的时候，需要将两部分数据加以合并，然后才能返回给上层调用；调整2（扩展成集群）：将增量数据的管理独立出来，由一个专门的节点/实例管理（MN）将单一KingbaseES实例扩展为多个节点/实例（TN），该节点负责读取基线数据，向MN请求增量数据、以及合并基线数据和增量数据；
预期效果功能：基本功能与KingbaseES保持一致新增集群特有的功能（具体需求跟OracleRAC的相应功能对应）：负载均衡HA配置、管理、监控性能：响应时间比单机略差Merge对系统性能的影响与Checkpoint基本一致吞吐量线性扩展
适用场景定位：面向企业级关系数据库市场，提供高并发、高可用性、高性能、负载均衡的数据库集群，可替代OracleRAC场景：基于以下原因，从单机升级到集群的应用：性能不足，需要扩展性的应用单机可用性不足，需要增强可用性的应用原来采用集群（如OracleRAC）的应用约束：读写分离导致的限制：应用读多写少或存在明显的业务高峰和低谷期MN的配置是重点国产芯片和OS平台的限制：缺少集群文件系统具体应用类型：OA、ERP、CRM…..
竞争分析—集群架构单活VS多活单副本VS多副本基于共享存储的双机热备单活单副本基于Standby的双机热备单活，可多活（备机只读）多副本基于复制的双机热备单活，可多活（备机只读）多副本读写分离集群多活，但不保证事务一致性多副本SN集群多活单副本+多副本SD集群多活单副本+多副本基于共享存储的双机热备基于Standby的双机热备基于复制的双机热备读写分离集群
竞争分析—厂商双机热备方案，各家都有。DM还有：读写分离集群SN集群（MPP集群）SD集群（在研）ST只有SN集群xCluster（很初级）
目录产品定位当前状态后续计划
研发状态功能支持情况：除以下功能以外，兼容基线版本的所有单机功能大对象临时表部分DDL暂不支持DDL语句不允许放在事务中集群特性：支持服务故障自动转移支持动态扩展连接级负载均衡性能：上次28s测试反馈的性能问题已安排解决基本可用，TPCC1800w稳定运行；峰值可超过10wtpmc欠缺缺少配套的配置、监控、管理工具集群HA、负载均衡、性能特性需要进一步完善
项目情况海情5XX
目录产品定位当前状态后续计划
研发安排ToDo换内核大对象临时表具体时间安排待定
产品推广欢迎交流和试用
讨论
金仓数据库集群——KingbaseRAC满足复杂业务场景需求：对OLTP与OLAP紧密结合（新一代数据处理需求）复杂综合业务场景的有力支撑低总体拥有成本：适合高低混合配置服务器，主控节点（高配置）+事务节点（低配置）融合内存数据库与磁盘数据库充分利用SSD磁盘的随机IO速度优势，又规避其擦写次数有限的缺点
KingbaseRAC-高可用服务准零中断DMNBTN共享存储心跳网络ATNCTNPacemakerDMNBTN共享存储心跳网络ATNPacemakerCTN-MNDMNBTN共享存储心跳网络ATNCPacemakerMN
KingbaseRAC-高扩展性能加速比平均性能加速比超过0.7
KingbaseRAC-高性能5台机器足够支撑几乎所有在线交易应用
KingbaseRAC-高兼容源自KingbaseES，天然具备KingbaseES的各种开发和管理特性单机存储管理编程语言处理客户端编程接口配置、管理工具KingbaseES集群存储管理编程语言处理客户端编程接口配置、管理工具KingbaseRAC
KingbaseRAC-易部署/管理一键克隆部署