Update 20210902_02.md

Author: digoal

202109/20210902_02.md

@@ -24,22 +24,26 @@ PostgreSQL , 只读实例 , 孤岛
 
 3、这个问题将影响哪些行业以及业务场景  
 - 人类的祖先智人为什么能干掉脑容量更大的尼安德特人? 社交能力. 即大群体能力对抗小群体(150人)的能力.    
-- 既有TP(单机为主, 灵活, 低延迟高并发小事务, 全局一致性等需求), 又有复杂分析的业务(OLAP, 多机并行计算为主).   
+- 既有TP(单机为主, 灵活, 低延迟高并发小事务, 全局一致性等需求), 又有复杂分析的业务(OLAP, 多机并行计算为主).
+- 很多企业会在业务库上跑日报、周报、月报的需求, 通常是半夜业务低峰跑报表, 白天跑高并发业务的场景.    
 
 4、会导致什么问题?  
 - 一般来说读写分离可以解决读请求能力扩展的问题, 但是对于复杂的分析, 不行.   
 - 单一实例的CPU核数有限, 实例内并行计算的话很容易达到单机天花板.   
 
 5、业务上应该如何避免这个坑  
-- 将数据同步到专门的OLAP数据库进行处理.   
+- 复杂SQL使用其他产品, 将数据同步到专门的OLAP数据库进行处理.   
 
 6、业务上避免这个坑牺牲了什么, 会引入什么新的问题  
-- 额外的OLAP数据库, 增加了成本.  
-- 增加了同步带来的研发、软件、维护开销.  
-- 增加了管理复杂度  
+- 额外的OLAP数据库, 增加了成本.
+- 同步有延迟问题, 导致报表数据不及时.
+- 跨产品同步还可能引入类型不兼容、编码不兼容、丢数据等难缠的问题, 导致报表数据不准确.      
+- 增加了同步带来的研发、软件、维护开销.     
+- 增加了管理复杂度.     
 
 7、数据库未来产品迭代如何修复这个坑  
-- 内核改进: 将多个RO节点联合起来执行同一个任务, 例如一个非常复杂的SQL, JOIN, 创建索引等. 类似于Greenplum的MPP处理能力. 可以线性提升性能.    
+- 内核改进: 将多个RO节点联合起来执行同一个任务, 例如一个非常复杂的SQL, JOIN, 创建索引等. 类似于Greenplum的MPP处理能力. 可以线性提升性能.
+- 或者可以通过PolarDB for PG的开源版本体验一下跨节点并行的功能(ePQ) 参考文章:  [《开源PolarDB|PostgreSQL 应用开发者&DBA 公开课 - 5.5 PolarDB开源版本必学特性 - PolarDB 特性解读与体验》](../202401/20240125_07.md)