HTAP 架构 - 存储计算分离处理AP查询的挑战
在这个架构下，如果用户需要跑一些分析型的查询，可以举个实际例子，比如像电信计费系统，白天处理用户的充值、各种积分的结算，像这样的请求，都会带有 UserID，通过索引可以精确地定位到修改的页面。在晚上会跑一些批量的分析，比如做对账，在不同的维度去统计省、市，统计整体的销售情况。存储计算分离的架构在处理大查询上，把 SQL 通过读写分离，将 SQL 动态地负载到负载较低的节点上。
这个节点在处理复杂 SQL 时，PG 数据库具备单机并行的能力，虽然单机并行处理复杂 SQL 比单机的串行有很大的提升，但在单机并行下内存和 CPU 还是有一定局限性，在这种架构下处理复杂 SQL 只能通过 Scale Up 的方式来加速。也就是说如果发现 SQL 处理得比较慢，就只能增加 CPU，增加内存，找一个配置更高的机器来当只读节点。而且单一节点来处理一个复杂SQL，是无法发挥出整个存储池大带宽的优势。
因为分布式存储底层是有多个盘，每个盘都具有读写的能力。如果计算节点成为瓶颈，那么底层共享存储池，每个盘的能力是无法发挥的 。另外一个问题，当只用一个节点来处理复杂 SQL 时，其他节点有可能是空闲的，因为通常AP的并发是很低的，有可能只是几个节点在跑一些固定的报表SQL，而其他的节点是处于空闲的状态，它的CPU，内存还有网络也是没有办法利用起来的。
