背景

1、产品的问题点

• 只读实例是独立的孤岛实例, 不能联合起来完成同一个任务(例如一个大的SQL请求, 创建索引, JOIN等)

2、问题点背后涉及的技术原理

• 业界有两种使用只读实例的方法

• • 每个只读实例有独立的URL, 应用程序创建多个数据源(每个数据源对应1个只读实例), 应用程序自己控制将SQL请求发给哪个数据源.
  • 使用读写分离的中间件, 应用只需要连接1个地址(中间件地址), 中间件解析SQL, 将SQL路由到RW或RO实例.

3、这个问题将影响哪些行业以及业务场景

• 人类的祖先智人为什么能干掉脑容量更大的尼安德特人? 社交能力. 即大群体能力对抗小群体(150人)的能力.
• 既有TP(单机为主, 灵活, 低延迟高并发小事务, 全局一致性等需求), 又有复杂分析的业务(OLAP, 多机并行计算为主).

4、会导致什么问题?

• 一般来说读写分离可以解决读请求能力扩展的问题, 但是对于复杂的分析, 不行.
• 单一实例的CPU核数有限, 实例内并行计算的话很容易达到单机天花板.

5、业务上应该如何避免这个坑

• 将数据同步到专门的OLAP数据库进行处理.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 额外的OLAP数据库, 增加了成本.
• 增加了同步带来的研发、软件、维护开销.
• 增加了管理复杂度

7、数据库未来产品迭代如何修复这个坑

• 内核改进: 将多个RO节点联合起来执行同一个任务, 例如一个非常复杂的SQL, JOIN, 创建索引等. 类似于Greenplum的MPP处理能力. 可以线性提升性能.