He3DB 系统架构02

　　以Aurora为代表的云原生数据库，通过架构改造，能够极大的改善了RDS存在的一些问题，例如读写性能相比RDS提升3-5倍，容量支持64T,支持实时备份并保证备份速率高效等能力。

　　虽然云原生数据库相比RDS优化了很多，但是依然存在一些问题无法解决，

　　性能波动明显：如果数据容量达到10T以上，数据内存命中率会明显下降，导致读写性能波动过大，影响业务稳定性

　　成本过高：无论使用云盘还是增加的一系列的管理模块，相比RDS云原生数据库成本都过高。这也导致虽然产品力远超RDS。但是市场收入各大云厂商还是以RDS为主

　　我们认为这两个问题，是制约云原生数据库发展的核心问题。

　　那么HE3DB的架构设计如何解决这些问题呢？

　　He3DB的架构设计，主要分成三步：

　　第一步：完成产品定位；确定目标用户；梳理出产品核心竞争力

　　产品定位：属于云原生数据库产品。

　　目标用户：RDS以及云原生数据库用户。RDS成本和云原生数据库产品力之间存在一个权衡，而正是这种权衡，促使我们决定研发He3DB，我们希望He3DB既能向下占据部分RDS市场，又能向上承接部分云原生数据库业务。

　　核心竞争力：首先He3DB主要的核心指标必须保持和其它竞品处于同一水平线，同时着力云原生数据库存在的两个痛点，形成差异化竞争：

　　解决大数据量（>10T），业务性能指标波动过大的问题（主要由于内存命中率低导致的问题）

　　解决成本问题，目标相比竞品下降30%以上成本，未来跟RDS 一主两备成本持本

　　第二步：根据产品定位以及目标用户，完成产品核心能力制定

　　He3DB立项之初，不会把追求更大，更快，更强作为我们的目标，而是充分调研行业主流指标以及移动云场景下对数据库服务能力的要求，我们制定了一些指标上限：

　　读QPS>100W，写TPS>10W

　　数据量>100T，为什么是100T而不是aurora的64T,HE3DB后续会往下HTAP方向发展，我们认为100T的上限更合理

　　RTO上限30S，正常情况下，RTO值非常小

　　备份速度10G/S

　　在保证这些指标实现的前提下，如何降低成本才是我们后续发力的重点方向

　　第三步：完成架构设计，架构设计考虑的重点：

　　一是保证能够满足核心指标上限；

　　二是保证数据正确性；

　　三 可持续迭代，往高性能，低成本方向演进

　　关于正确性证明：前期快速开发了一个模型，实现了log is database,计算存储分离，共享存储。开发过程中，不会考虑任何高可用，性能，异常处理。并且为了快速验证，我们直接基于开源juicefs改造，实现分布式存储。