SphereEx分布式数据库增强计算平台_数据库集群

SphereEx分布式数据库增强计算平台

SphereEx分布式数据库增强计算平台为解决原有方案的技术瓶颈，降低更换架构带来的复杂性风险，在不更换原有架构前提下，实现数据库同步，管理多个异构数据库集群，线性提升数据存储容量及并发吞吐。为用户提供基于数据分片，分布式事务、弹性伸缩的分布式数据库解决方案，兼具单机交易型数据库稳定性和分布式数据库的扩展能力。

立即咨询

首页 > 产品中心 > 分布式数据库 > SphereEx分布式数据库增强计算平台

三种分布式技术路线

分布式中间件+单机数据库
优势 • 兼容性好，学习成本低；

• 资源投入足够大时节点可以扩展到很大规模。

不足 • 业务代码修改成本高；

• 下层计算节点无法按需扩展；

• 全局事务能力、高可用等方面有短板；

• 复杂度高，机器冗余多。

非对称计算节点+分布式存储
优势 • 兼容性好，应用无需改造；

• 共享存储中一致性好，产品整合较高。

不足 • 扩展性有限，数据处理

规模较高时，需分库处理；

• 难以做到跨地域高可用；

• 对高性能基础设施底座有较大依赖。

原生分布式数据库
优势 • 可按需扩展，没有数量和规模限制；

• 数据一致性的安全保护机制更好；

• 支持跨地域的访问和容灾；

• 硬件依赖少，可灵活进行混合云和多云部署；

• 硬件利用率高，可以通过普通

PC服务器实现集群和高可用。

不足 • 产品成熟度仍需时间沉淀；

• 上下游生态适配还需进一步完善。

特点及使用场景

技术路线	路线优点	路线缺点	适用场景
分布式中间件 +单机数据库	稳定性高极致性能超大规模	功能不完整潜力不足	大规模 OLTP 高性能、高并发
原生分布式数据库	高弹性无侵入功能完整	风险中高稳定性待验证	中小规模 OLTP 混合负载场景高可用场景
业务自研+开源单机数据库	灵活可控风险低	侵入强成本高	小规模 OLTP 数量众多外围系统

分布式数据库解决方案 icon

分布式数据库解决方案：为解决原有方案的技术瓶颈，降低更换架构带来的复杂性风险，在不更换原有架构前提下，实现数据库同步，管理多个异构数据库集群，线性提升数据存储容量及并发吞吐。为用户提供基于数据分片，分布式事务、弹性伸缩的分布式数据库解决方案，兼具单机交易型数据库稳定性和分布式数据库的扩展能力。

案例：某大型国有银行（核心交易场景） icon

用户收益：分布式数据库中间件与国产库组合，解决银行核心交易场景；实现动态伸缩、弹性扩展、业务无感，满足金融业“稳态+敏态”业务。

案例：京东白条 - 千亿数据量级金融场景 icon

用户收益：高并发和海量数据的极致处理能力，节约研发成本，改善架构可扩展性。

行业/场景

常见数据存储加密方案 icon

数据安全解决方案

数据安全解决方案：为了防止数据泄露，保护数据安全，提供基于产品的数据加密功能。在不改动原有代码的前提下，为企业提供跨平台、异构环境的数据安全解决方案。功能特性极致性能 & 多接入端多数据库方言 & 访问协议支持数据加密 / 国密支持密态计算在线加密 / 转加密权限控制 / 对接 LDAP & 第三方在线洗数。

案例：某跨境电商 - 云端密钥管理场景 icon

项目背景

既有业务加密改造

云端密钥管理

符合 GDPR 要求客户收益

业务零改造

高效、稳定上线

在线完成洗数

一站式加密处理

平台扩展性强

预留分片等扩展插槽

行业/场景

改造阶段说明

架构选型阶段

该阶段需完成信创技术栈的选型问题。

研发测试阶段

该阶段需完成业务系统针对信创技术栈的改造及测试。这其中涉及到较大的成本（人力、时间）的投入。

系统验证阶段

完成业务系统改造后，需针对新平台的功能、稳定性、可用性等方面进行验证。一般为保证真实性，可通过业务并行方式进行。

系统上线阶段

在系统已经得到充分验证后，需将业务系统从原技术栈完全迁移到新技术栈。此阶段需重点解决迁移及出现问题的保障维护方面。

阶段：选型评估

信创技术栈分散

尚未形成选型标准，选型困难。在生态兼容性上，有兼容 MySQL、PG、Oracle、自有标准等多种形式。架构上包括单机、集中式、分布式等多种,包括以NewSQL为代表的产品受到关注。在部署平台上，包括私有部署及云端部署 (含私有云带底座、公有云)等多种形式。

产品能力层次不齐

产品能力层次不齐，不同产品间功能差异明显，包括内核层面、周边生态层面及管理维护层面等多方面。无法面对统一的服务界面会很困难。此外,在产品部署形态上，云数据库产品成为很多企业的选择。但在云产品选择上，用户的自主权较差，存在与原有方式的管理差异。

阶段：研发测试

系统评估难

在实际工作中，经常会面临一类问题就是旧有系统已无人了解或干脆是由第三方开发的。如在存量业务的改造中, 缺乏有效的手段去收集、进而很难评估改造任务工作量。

改造成本高

原系统，对旧技术栈依赖严重,之前多采用Oracle、DB2为代表商业数据库，应用端依赖数据库方言、库内计算、生态工具等。新技术栈功能不足，需应用改造故存在较大工作。策略上，部分需改造适应新架构，部分需在异构平台 (如大数据、缓存)或应用层解决。

评估结果难

对新产品兼容性存疑,仅通过语法兼容或少量改造,难保证语义一致,造成上线风险。缺乏有效的评测手段,针对语义等价(数据一致性)及性能等能做到评估。

阶段：系统验证

风险高、回退难

为了在验证阶段,验证系统是否工作正常, 一般需要开发大量验证类的代码。这部分工作为了满足系统支持新旧技术栈及必要的对比等工作，但往往工作量巨大。如很多应，用常见的数据双发逻辑，就是通过数据双写，同步验证两边执行结果。为达到这一-诉求, 不得不在原有业务逻辑上开发两套适应不同技术栈的代码。

验证难,无从下手

在验证阶段还有一个比较难的地方在于如何验证，最好的验证方式是带着真实流量的验证，但同时还需考虑风险问题。如果对业务访问做好精准的控制，按需求进行业务验证，且还需提供必要的退化能力保证安全。如常用的基于读写的分配、基于流量的分发(甚至基于业务特征的分发能力)。

阶段：系统上线

窗口短、迁移难

在系统上线阶段, -个突出问题是迁移窗口期的问题，其普遍的.上线窗口期很短。这就需要在较短的时间内能够完成数据库间(一般是异构)的数据的迁移工作，同时还需针对迁移后的数据提供质量对比，能够保证迁移数据是正确的。

不稳定、无逃生

系统上线后的稳定性问题，用户最为关心。作为新产品、新架构，很难保证上线后不出问题。虽可通过充测试、并行验证等手段尽量减少风险，但显然无法完全避免。较好方式是提供能力，根据可能出现的运行问题,通过-些手段可以尽量减少问题影响范围，恢复业务。

方案亮点

解决问题

信创改造

亮点

行业唯一：开发角度：提升开发效率，降低开发成本，缩短开发周期，降低运行风险；管理角度：统一数据库访问管理，降低使用风险，便于使用追踪；运维角度：降低应用访问及数据安全风险 • 兼容广泛：兼容多款数据库产品（MySQL、PG、SQLServer、Oracle、openGauss、KingBase...）

案例：某大型国有银行 – 异构数据网关 icon

用户收益：多源异构数据库统一接入处理能力；标准化数据库访问，简化研发投入；改善数据库接入方式，灵活可扩展。