第一，单机的PG 只支持单机的串行与单机的并行，不支持多机查询和跨机查询， 无法发挥多个计算节点的特性，CPU 和memory 无法横向的scale out，只能单机 scale up，即必须增加CPU 和memory 的实例规格。 第二，原生的PG 直接套用到PolarDB 上，无法充分发挥共享存储池的大吞吐能力， 因为只能利用单机计算节点上的RO 能力。

使用原生的 PolarDB-PG 处理 HTAP（Hybrid Transactional/Analytical Processing）场景时，可能会遇到以下两个挑战：

1. 数据一致性：

   • 在 HTAP 场景中，既需要支持高并发的事务处理（TP），又需要进行复杂的分析处理（AP）。由于分析处理通常需要大规模的数据扫描和聚合操作，这可能导致对数据一致性的要求变得更加复杂。在进行分析处理时，如果同时进行事务处理，可能会影响数据的一致性。

2. 资源竞争和性能问题：

   • 在同一数据库系统中同时进行 TP 和 AP 操作时，可能会引起资源竞争和性能问题。TP 操作通常需要较高的事务吞吐量和低延迟，而 AP 操作则需要较高的查询性能和复杂计算能力。这两种操作具有不同的访问模式和资源需求，因此可能会相互竞争数据库系统的资源，导致性能下降或无法满足要求。

为了克服这些挑战，可以采取一些策略，例如：

• 数据分区：根据业务需求和查询模式，将数据分区存储在不同的表空间或实例中，以减少资源竞争和提高性能。
• 查询优化：使用适当的索引、查询优化技术以及合理的查询设计来提高 AP 场景下的查询性能。
• 事务隔离级别：根据业务需求和数据一致性要求，选择合适的事务隔离级别，平衡 TP 和 AP 操作之间的数据一致性和性能。
• 资源调整：根据负载情况和性能需求，适时增加或减少数据库实例的规模和计算资源，以满足 TP 和 AP 的需求。

综上所述，处理 HTAP 场景时，要注意数据一致性和资源竞争对系统性能的影响，并采取相应的策略来解决这些挑战。