下面是SLS OpenTelemetry Trace的实现架构，核心是通过数据编排计算Trace原始数据并得到聚合数据，并基于SLS提供的接口实现各类Trace的附加功能。例如：
依赖关系：这是绝大部分的Trace系统都会附带的功能，基于Trace中的父子关系进行聚合计算，得到Trace Dependency
中间件分析：Trace中对于中间件（数据库/MQ等）的调用一般都会记录成一个个Span，基于这些Span的统计可以得到中间件的QPS、延迟、错误率。
PolarDB MySQL是因云而生的一个数据库系统, 除了云上OLTP场景，大量客户也对PolarDB提出了实时数据分析的性能需求。对此PolarDB技术团队提出了In-Memory Column Index(IMCI）的技术方案，在复杂分析查询场景获得的数百倍的加速效果。
MySQL是一款主要面向OLTP型场景设计的开源数据库，开源社区的研发方向侧重于加强其事务处理的能力，如提升单核性能/多核扩展性/增强集群能力以提升可用性等。
随着互联网而兴起的新兴数据库产品很多都兼容了MySQL协议，因此成为替代MySQL的一个可选项。而这些分布式数据库产品大部分采用了分布式Share Nothing的方案，其一个核心特点是使用分布式一致性协议来保障单个partition多副本之间的数据一致性。
比多副本Divergent Design方法更进一步的，是在同一个数据库实例中采用行列混合存储的方案，同时响应TP型和AP型负载。这是传统商用数据库Oracle/SQL Server/DB2等不约而同采用的方案。
PolarDB MySQL能力栈与开源MySQL类似，长于TP但AP能力较弱。由于PolarDB提供了最大单实例100TB的存储能力，同时其事务处理能力远超用户自建MySQL。因此PolarDB用户倾向于在单实例上存储更多的数据，同时会在这些数据上运行一些复杂聚合查询。借助于PolarDB一写多读的架构，用户可以增加只读的RO节点以运行复杂只读查询，从而避免分析型查询对TP负载的干扰。
1 MySQL的架构在AP场景的缺陷
MySQL的实现架构在执行复杂查询时性能差有多个方面的原因，对比专用的OLAP系统，其性能瓶颈体现多个方面：
PolarDB团队开发的并行查询框架（Parallel Query), 可以在当查询数据量到达一定阈值时，自动启动并行执行，在存储层将数据分片到不同的线程上，多个线程并行计算，将结果流水线汇总到总线程，最后总线程做些简单归并返回给用户，提高查询效率。
列式存储同样能提高CPU在处理数据时的执行效率，首先列存的紧凑排列方式可提升CPU访问内存效率，减少L1/L2 Cache miss导致的执行停顿。其次在列式存储上可以使用应用SIMD技术进一步提升单核吞吐能力，而这是现代高性能分析执行引擎的通用技术路线（Oracle/SQL Server/ClickHouse).
