He3DB是受Aurora论文启发，移动云研发的云原生数据库。研发初期我们阅读了能够找到的所有的云原生数据库相关论文以及试用了业内主流的云原生数据库产品，然后整理出了不同架构的核心关健技术，优劣势（后续相关论文解读会陆续分享出来）。在深入掌握了云原生数据库大量理论基础下，我们开始思考移动云应该研发一款什么样的云原生数据库。
任何产品的立项研发，一定是从解决实际问题出发考虑：
RDS 存在的问题：
RDS本质上就是将传统数据库部署到云基础设施上（虚机，云盘），在云上提供一键获取、自动运维、安全保障等服务。但是相比物理机部署时代，数据库本身的能力并没有得到本质提升，甚至性能出现下降：
-
问题1: 如果使用云盘，性能相比本地盘会出现较大下降，并且成本随着备节点扩容而线性上升(例如一主两备架构，使用三副本云盘，数据将被复制9份)。 如果使用本地盘，将丢失使用云盘的优势：计算存储分离，存储在线动态扩容，高可用能力等。而这些能力对一些业务场景具有非常大的吸引力
-
问题2: 无论物理机部署，还是RDS，数据库读写瓶颈都不高，实际业务场景中，很容易出现单机无法承受业务负载压力，而不得不使用分库分表的方案，极大的增加业务架构的复杂性
-
问题3: 备机虽然可以提供只读服务，但是因为主备延时无法控制，导致备机读到的数据完全不可控，可能是一小时前的的数据。很多业务设计无法接受最终一致性，导致备机只 作为高可用节点，极大的限制了读扩展能力，而很多OLTP业务，一般是读多写少的场景，所以这是一个很大的予盾点
-
问题4：备份影响业务，每次备份对生产服务会产生比较大的影响。核心业务，每天只能给 出很短的时间窗口做备份。而备份速度又有上限，导致随着业务规模越来越大，备份时间窗口会越来越短，而备份时间会越来越长，窗口和备份时长的予盾会越来越激励，并且无解。而如果备份频率很低，或者长时间只做增量，当数据库服务出现问题后，要么丢数据，要么数据库恢复时长过大，无论那种后果，对业务造成的损失都是不可估量的
-
问题5：数据库容量问题，一般我们建议MYSQL或者PG容易尽量不要超过2T，否则会产生一系列维护的问题以及性能问题（例如数据内存命中率降低）。在业务场景中，容量问题同样会导致数据库使用分库分表方案
-
问题6：备节点支持的数量问题，即使业务能够接受最终一致性，备机数据也不能无限增加，目前增加备机两种方式，串联或者并联，无论那一种方式，备机数目的增加都会对挂载节点很大的负载（主要是网络负载），也增加cluster管理负担（状态监控，主备切换）
