常见优化思路

核心优化思路

多机并行：能够充分利用多机的资源
单机多核并行：能够充分利用单机上多核的资源
充分利用单核的性能：
3.1 减少 指令数：选择效率更好的执行策略，数据结果，算法 等
3.2 减少 每个指令需要的周期：SIMD, CPU Cache，分支预测 等

资源的视角

CPU
多核扩展性
Lock
分段
thread local
Lock Free
上下文切换
绑核
用户态线程
线程池
NUMA
Cache Line 伪共享
同步 VS 异步
单核性能
SIMD
分支预测
Cache Miss

C++ 优化点

经验法则

reserve memory for std::vector
编译器优化
函数传参时避免 copy
减少shared_ptr 的 copy
Avoid the compiler ever having to consider a potential call to malloc(), or any extern function, in hot loops.
avoid thread synchronisation anywhere inside a hot loop.
Keep collections of data in a single contiguous block of memory as much as possible
In multi-threading programming, sometimes copying blocks of data can be faster than sharing via a mutex. There are other benefits to this, such as avoiding data synchronisation pitfalls, deadlocks, priority inversions, etc.
Choose std::unordered_set/map over std::set/map
Choose std::streambuf and their variants over std::i/ostream when reading/writing lots of data.
std::unique_ptr over std::shared_ptr.
Evaluate things in constexpr if you can.
Make as many types as possible TriviallyCopyable.
用 lambda 代替 std function https://quick-bench.com/q/4IKpxAA5VEbXVziV1G2Po-ZupSE
std::fill 要注意模板的类型匹配 https://travisdowns.github.io/blog/2020/01/20/zero.html
Multiplying and shifting is a standard technique to emulate the division.

Final 去虚拟化

https://gcc.godbolt.org/z/16zMdjEjY

Virtual functions do not incur too much additional cost by themselves, The number one factor that is responsible for bad performance are data cache misses

Avoiding vector of pointers on a hot path is a must

Most overhead of virtual functions comes from small functions, they cost more to call than to execute

虚函数通常通过虚函数表来实现，在虚表中存储函数指针，实际调用时需要间接访问，这需要多一点时间。

然而这并不是虚函数速度慢的主要原因，真正原因是编译器在编译时通常并不知道它将要调用哪个函数，所以它不能被内联优化和其它很多优化，因此就会增加很多无意义的指令（准备寄存器、调用函数、保存状态等），而且如果虚函数有很多实现方法，那分支预测的成功率也会降低很多，分支预测错误也会导致程序性能下降。

Inline

memcpy

内存相关的操作对性能影响会比较大，memcpy 基础操作的优化点：

Prefetch：小数据量时使用
区分内存对齐和非内存对齐的 Copy，内存对齐的simd 指令会更快
Simd 指令加速：sse,avx,avx2,avx512 等指令
Overlapped： to copy the last 4 <= n <= 7 bytes: copy the first & last 4 bytes。 非对齐字节，
不同 szie 使用不同的策略：小于8，小于16，小于32，小于256，大于256 做不同的处理
绕过 CPU Cache，内存直接写，避免影响 CPU Cache
查表法：拷贝不同小尺寸内存，直接跳转到相应地址解除循环。
循环展开
汇编优化

几个系统的优化实现，代码里面的注释可以细读：

StarRocks: Improve performance of strings::memcpy_inlined https://github.com/StarRocks/starrocks/pull/13330/files
ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/21520/files
folly: https://github.com/facebook/folly/blob/master/folly/memcpy.S
标准库： https://www.zhihu.com/question/35172305

memchr

https://gms.tf/stdfind-and-memchr-optimizations.html

memcmp

http://www.picklingtools.com/study.pdf

dpdk Implement memcmp using AVX/SSE instructio : http://patchwork.dpdk.org/project/dpdk/patch/1429716828-19012-2-git-send-email-rkerur@gmail.com/

+/**
+ * Compare 16 bytes between two locations.
+ * locations should not overlap.
+ */
+static inline bool
+rte_cmp16(const uint8_t *src_1, const uint8_t *src_2)
+{
+ __m128i xmm0;
+ __m128i xmm1;
+ __m128i vcmp;
+ uint32_t vmask;
+
+ xmm0 = _mm_loadu_si128((const __m128i *)src_1);
+ xmm1 = _mm_loadu_si128((const __m128i *)src_2);
+
+ vcmp = _mm_cmpeq_epi16(xmm0, xmm1);
+ vmask = _mm_movemask_epi8(vcmp);
+ return (!(vmask == 0xffffU));
+}

memequal(类似 memcmp)

Loop Optimization

Unrolling

Resize No Initialize

Copy To Move

Std::vector

Code Layout

Compile-time Computation

查表法 Table Lookup

optimize harmonic mean evaluation in hll::estimate_cardinality 
https://github.com/StarRocks/starrocks/pull/16351

Make your lookup table do more https://commaok.xyz/post/lookup_tables/

编译期运算 constexpr

#std::inplace_merge 代替 std::merge
std::inplace_merge 是原地 Merge，相比 std::merge 更省内存
https://github.com/StarRocks/starrocks/pull/14609

#用 std::variant 代替 polymorphism
#memory_resource 优化内存分配
http://quick-bench.com/kW0AAZlrPK0ubds9_ZMsEYvFnlI

高性能第三方库

fmt

https://github.com/fmtlib/fmt

https://www.zverovich.net/slides/2017-cppcon.pdf

llfio

https://github.com/ned14/llfio

asio

https://think-async.com/Asio/

zeromq

https://aosabook.org/en/v2/zeromq.html

https://zeromq.org/

nanomsg

https://github.com/nanomsg/nanomsg

phmap

https://github.com/greg7mdp/parallel-hashmap

roaringbitmap

https://roaringbitmap.org/

simdjson

https://github.com/simdjson/simdjson

不同的指令集

High-performance load-time implementation Selection:
https://github.com/CppCon/CppCon2022/blob/main/Presentations/Load-Time-Function-Selection.pdf

数学相关

Computing the number of digits of an integer even faster: https://lemire.me/blog/2021/06/03/computing-the-number-of-digits-of-an-integer-even-faster/

hashtable

https://zhuanlan.zhihu.com/p/614105687?utm_id=0

RPC 优化点

Local exchange pass through
线程模型的设计
  # 全 polling 线程模型
  # brpc 线程模型
内存管理
连接管理
池化
Batch 操作
用户态 TCP
Cache Miss 优化 (避免跨线程访问资源，保证 cache locally) 

序列化
  # ProtoBuf
  # FlatBuffers
压缩和编码
Zero Copy
流量控制
RDMA
DPDK

参考资料

https://www.youtube.com/watch?v=A7PA37fxfp0&t=1981s
https://www.youtube.com/watch?v=fBpJNrSlQm8&t=1206s

Serverless 优化点

弹性

Scale Out 能力

虚拟化的影响

https://www.p99conf.io/session/cutting-through-the-fog-of-virtualization/

对象存储

并行扫描文件
自适应 IO 调度框架
重试(针对云存储的限额等报错，需要自动重试)

Local Cache 加速

资料

https://cloud.google.com/blog/products/data-analytics/inside-bigquerys-serverless-optimizations

SIMD

注意事项

AVX-512 is not always faster than AVX2. 原因是一些 CPU 可能会降频，还有编译器会 prefer 256-bit SIMD operations

SIMD 基础知识

What SIMD
SIMD Registers
Many Ways to Vectorize
Compile Auto Vectorize
How to Ensure SIMD Instructions Used
Vector Intrinsics

SIMD 优化案例

SIMD text parsing
SIMD data filtering
SIMD string operations
SIMD json
SIMD join runtime filter
SIMD hash table probe
SIMD memcpy
SIMD memcmp
SIMD memequal
SIMD case when
SIMD gather
SIMD branchless
SIMD filter (https://github.com/StarRocks/starrocks/pull/14328/files)
SIMD aggregate
SIMD string to integer parser (https://kholdstare.github.io/technical/2020/05/26/faster-integer-parsing.html)
SIMD std::find & memchr
SIMD std::find and memchr Optimizations (https://gms.tf/stdfind-and-memchr-optimizations.html)

如何更好地触发向量化

循环外提 https://github.com/StarRocks/starrocks/pull/14510

循环展开

多平台多SIMD指令兼容

https://github.com/milvus-io/knowhere/blob/main/src/simd/hook.cc

参考资料

https://15721.courses.cs.cmu.edu/spring2023/slides/08-vectorization.pdf

业务侧优化

数据建模
SQL 改写
  #减少不必要的 Join
近似代替精确
抽样代替全量

多核并行优化点

并行执行模型

并行度自适应

线程池 Lock

SpinLock

分段锁 https://github.com/apache/doris/pull/3222

Lock Free
// 通过CAS操作实现Lock-free
do {
  ...
} while(!CAS(ptr，old_data，new_data ))

One way to avoid the ABA problem is to ensure that the head of the stack never has the same value twice.

The addition of a sleep reduced contention, and consequently both increased throughput while decreasing processor utilization.

https://www.singlestore.com/blog/common-pitfalls-in-writing-lock-free-algorithms/

#Lock-Free Queue
可以支持高效并发的写操作和较少的读操作。

无锁队列的基本思想是使用原子操作和 CAS（Compare-and-Swap）操作来实现并发安全的插入和删除操作，而无需使用显式的锁来保护共享数据。

#Epoch Based Reclamation
EBR 适用于读操作频繁、写操作相对较少且需要回收的内存区域较小的场景。

#Read-Copy Update (RCU)
它适用于读操作频繁、写操作相对较少且修改的数据较小的场景。

协程

避免阻塞等待

更高的并发性

减少上下文切换

更好的资源利用

Use Coroutines for Asynchronous I/O to Hide I/O Latencies and Maximize the Read Bandwidth
(https://db.in.tum.de/~fent/papers/coroutines.pdf?lang=en)

https://mp.weixin.qq.com/s/WbR7dN7wVdVEpB8wHBbxCw(仅花200行代码，如何将60万行的RocksDB改造成协程)

调度

优先级调整
用户态线程

异步

https://www.p99conf.io/session/speedup-your-code-through-asynchronous-programing/

CPU独占 (CPU exclusive)

当一个进程或任务独占CPU时，它独自占用CPU资源，没有其他进程或任务与其共享CPU核心。

这意味着其他进程或任务无法在同一时间片内使用该CPU核心。CPU独占通常用于要求高性能的任务，例如实时系统、高性能计算或需要大量计算资源的应用程序。通过将CPU独占分配给特定进程或任务，可以确保它们获得足够的计算能力。

CPU绑核 (CPU affinity)

CPU绑核可以将特定进程或任务绑定到特定的CPU核心上运行。 通过绑定，该进程或任务将只在指定的CPU核心上运行，不会在其他核心上执行。 这可以用于优化多线程或并行应用程序的性能，以减少因线程迁移和上下文切换而引起的开销。通过将特定的线程或进程绑定到特定的CPU核心，可以提高缓存利用率并减少共享资源竞争。

对 CPU Cache 友好
减少 上下文切换

资源隔离 Cgroups

Numa 优化

当有多个 Numa Node, 且内存的分配和回收是瓶颈时，可以考虑针对 Numa 架构进行优化。

CPU NUMA（Non-Uniform Memory Access）优化通常旨在优化多处理器系统中的内存访问性能。 可以考虑下面几个方面的优化：

内存本地性：NUMA 架构中，每个 CPU 都与一组本地内存相关联。优化内存本地性意味着将数据分配到与执行线程所在的 CPU 相对应的本地内存中。这可以减少远程内存访问的开销，提高内存访问速度和整体性能。

数据局部性：NUMA 架构中，处理器可以更快地访问本地内存，而远程内存的访问速度较慢。因此，优化数据局部性可以使访问模式更加局部化，减少跨 Node 的数据传输和远程内存访问。这可以通过使用本地缓存、数据预取和对齐内存访问等技术来实现。

任务和线程绑定：在 NUMA 系统中，将任务或线程绑定到特定的 CPU 可以提高内存访问性能。通过将任务绑定到与其本地内存相关联的 CPU，可以减少远程内存访问和数据传输，从而提高性能。这可以通过使用操作系统或编程语言级别的线程绑定功能来实现。

NUMA 感知调度 ：操作系统和调度程序可以采用 NUMA 感知的调度策略，考虑处理器和内存的 NUMA 布局。通过将任务分配给与其本地内存相关联的处理器，可以减少远程内存访问的开销，提高系统整体的性能。

总而言之，CPU NUMA 优化的目标是最大程度地减少远程内存访问，以提高内存访问性能和整体系统性能。

当需要访问非本地的内存时，进行顺序访问，这样可以通过硬件的预取屏蔽 remote access latency.

内存分配

False Sharing

减少系统调用与上下文切换

存储层优化点

列存

索引

Hash 索引

B+ Tree 索引

Radix tree 索引

https://mp.weixin.qq.com/s/-lPJNRq4UdYYqeSpHPXfLg

前缀索引

ZoneMap 索引 （块索引）

块级索引，是以块为单位，记录块内元数据的索引（最大值、最小值、空值、COUTN、SUM、相关性等）

BloomFilter 索引

Bitmap 倒排索引

StarRocks Bitmap Index Rationale StarRocks 的 Bitmap Index 主要包括两部分内容：字典和 Bitmap 行号。 字典保存了原始值到编码 Id的映射，Bitmap 索引记录了每个编码 ID 到 Bitmap 行号的映射。

StarRocks Bitmap Index Storage Format 如上图所示，StarRocks 的字典部分和 Bitmap 行号部分都是以 Page 的格式存储，同时为了减少内存占用和加速索引，StarRocks 对字典和 Bitmap 的 Page 都建立了索引。

当然，如果建 Bitmap 索引列的基数很低，Dict Data Page 和 Bitmap Data Page 只有一个的话，我们就不需要 Dict Index Page 和 Bitmap Index Page。

Operation On Encode Data

当 StarRocks 利用 Bitmap Index 进行过滤的时候，只需要先加载 Dict Index Page 和部分 Dict Data Page 即可，按照字典值进行快速过滤，无需解码数据，也无需把所有 Bitmap Data Page 一次性加载进来。

综上，由于 StarRocks 支持Bitmap 索引的索引和支持按照字典值进行快速过滤，即使 Bitmap Index 列的基数很高，Bitmap Index 整体磁盘存储很大，内存占用也很小。

Bitmap 索引内存缓存 StarRocks 会保证所有的 Dict Index Page 和 Bitmap Index Page 一定在内存，并让尽可能多的 Dict Data Page 和 Bitmap Data Page 在内存，并保证 Bitmap Index 相关的 Page Cache 不被 Column 的数据冲掉。

这样在点查结果集较小的情况下，即使是第一次 Cold Query，StarRocks 也可以做到只需要一次 Disk Seek。

自适应 Bitmap 索引 当 StarRocks 发现 Bitmap 索引的选择度不高，需要 Seek 很多 Data Page 时，我们就会放弃使用 Bitmap 索引，直接顺序 Scan。

让索引常驻内存

物化列

Cache

多级 Cache RaptorX: Building a 10X Faster Presto

https://prestodb.io/blog/2021/02/04/raptorx

Metastore Versioned Cache
File List cache
Fragment Result Cache
File Descriptor and Footer Cache
Alluxio Data Cache

写入绕过 Cache

TencentCLS: The Cloud Log Service with High Query Performances 
https://www.vldb.org/pvldb/vol15/p3472-yu.pdf

vm.dirty_background_ratio vm.dirty_expire_centisecs

异步 IO

IO异步化对于高性能的网络编程、服务器应用程序、多线程和多进程编程等场景非常有用，可以避免因IO阻塞而导致的资源浪费和性能瓶颈。它允许程序更加高效地利用计算资源，并提高系统的并发能力和响应性能。

https://www.vldb.org/pvldb/vol15/p3496-lakshman.pdf
https://db.in.tum.de/~fent/papers/coroutines.pdf?lang=en

IO 多路复用

IO 并行度 自适应

IO 调度

Scan 优先级

Shared Scan

延迟物化

Segment 大小 / 文件大小

https://www.databricks.com/blog/how-databricks-improved-query-performance

文件的个数

太多的文件往往意味着太多的 IO 次数

文件的版本数

动态文件裁剪 数据局部性

压缩

Gzip
LZ4
Brotli
SNAPPY
ZSTD
BZIP2

编码

预取

Runtime filter

表达式下推存储层

Compaction

Prefetch or Predictive Pipelining

根据访问模式，提前从存储层读取所需要的数据。 在存储分离的架构，合理地 Prefetch S3 等分布式存储的文件，对 Scan 性能的优化更明显

https://www.databricks.com/blog/announcing-general-availability-predictive-io-reads.html

硬件 NVMe

Is Sequential IO Dead In The Era Of The NVMe Drive? 
https://jack-vanlightly.com/blog/2023/5/9/is-sequential-io-dead-in-the-era-of-the-nvme-drive

数据库中的各种 Cache

Cache 类型

Columnar Disk Caching
In-Memory Block Caching
Near-CPU Data Caching
Cube Relational Caching
Arbitrary Relational Caching
MetaData Cache
统计信息的 Cache
Query Result Cache

Cache 系统的问题

缓存穿透
缓存击穿
缓存雪崩

Cache 设计考虑点

Cache Unit
Cache Key
Cache Value
Cache Format
Cache Policy
Cache Metadata
Cache Storage
Cache 的一致性
Cache 的更新策略
Write-through
Post write
Write back

资料：

https://www.usenix.org/system/files/atc22-yang-tzu-wei.pdf

数据建模

表的模型 / 类型

明细模型
聚合模型
更新模型
主键模型

行存 VS 列存

分区

分桶

SortKey

数据类型

Nullable

查询优化器优化点

Parser 优化

Nullable 优化

Null 和 Nullable 是数据库中比较容易出错的点， Null 相关的很多逻辑都需要特殊处理，比如 Join， 聚合等算子，一些函数，谓词，四则运算 和 逻辑运算等。 而在向量化执行中， Null 和 Nullable 对性能的影响也很大。

Nullable 对性能的影响主要是两点：

null 需要特殊判断，可能会需要很多 if else , 导致一些地方不能向量化和分支预测错误
null 的数据需要占一个 column 或者 bitmap，会有额外的存储和计算开销。

StarRocks 对 Nullable 的优化主要体现在下面几点：

优化器对 Nullable 熟悉进行判断，如果可以确定表达式的结果一定是 Non-nullable 的，就会告诉执行层这个信息，这样执行层处理时完全不需要考虑 Null。比如 StarRocks 的这个PR： https://github.com/StarRocks/starrocks/pull/15380/files 当确定 cast 一定可以成功，且输入是 Non-nullable 的column时，结果就一定是 Non-nullable 的

利用 has_null 标识进行快速短路，如果一个chunk 里面的数据都没有null，就走 Non-nullable 的处理逻辑，在很多算子和函数中可以看到大量这种优化

利用 SIMD 指令快速对 全是 null 和 全不是 null 的 case 进行处理，在 StarRocks 的nullable_aggregate.h 可以看到大量这种优化

在表达式计算中，对 null 的 数组和 data 的数组分别进行向量化处理。

元数据优化

In Memory MetaData

利用元数据加速查询

全表 Count, Sum, Max, Min 的聚合查询可以直接从元数据查询 https://github.com/StarRocks/starrocks/pull/15542

利用元数据加速 统计信息计算的查询

Small Materialized Aggregates: A Light Weight Index Structure for Data Warehousing 
https://www.vldb.org/conf/1998/p476.pdf

利用元数据改写查询

Big Metadata: When Metadata is Big Data 
http://vldb.org/pvldb/vol14/p3083-edara.pdf

分区分桶裁剪

常见的RBO 优化

各种表达式的重写和化简
Cast 消除
谓词化简
公共谓词提取
列裁剪
Shuffle 列裁剪 （确保任何多余的列不要参与网络传输）
谓词下推
等价谓词推导（常量传播）
Outer Join 转 Inner Join
Limit Merge
Limit 下推
聚合 Merge
Intersect Reorder
常量折叠
公共表达式复用
子查询改写
Lateral Join 化简
Empty Node 优化
Empty Union, Intersect, Except 裁剪
In 转 Semi Join 或者 Inner Join  （http://mysql.taobao.org/monthly/2023/01/01/）
聚合算子复用
  # 比如对于下面的 SQL:
  # SELECT AVG(x), SUM(x) FROM table
  #我们可以让 AVG(x) 复用 SUM(x) 的计算结果，减少计算量
Primary Key 相关优化
冗余 Group By 消除
Sum 常量转 Count

常见的 CBO 优

多阶段聚合优化
Join 左右表 Reorder
Join 多表 Reorder
Join 分布式执行选择
Shuffle Join
Broadcast Join
Bucket Shuffle Join
Colocate Join
Replication Join
Join 和 Aggregate Runtime Colocate, 避免 Shuffle
CTE 复用
CTE 列裁剪
Agg 上拉
Agg 下推 Join
Agg 下推 GroupingSets
窗口下推 Group By
算子融合
物化视图选择与改写
利用基数信息进行优化

统计信息

统计信息的收集方式
统计信息的收集频率
统计信息 Cache

查询执行器优化点

多机执行模型
多核执行模型
单核执行模型
SIMD (https://perf.bcmeng.com/4%20optimization-points/simd.html)
多核并行优化点 (https://perf.bcmeng.com/4%20optimization-points/multi-core.html)
C++ Low Level (https://perf.bcmeng.com/4%20optimization-points/c-plus-plus.html)
列式布局
Batch 操作
按列处理
Shuffle By Column
虚函数调用

查询调度器优化点

Fragment 批量投递
Fragment 元数据 Cache
延迟调度
亲和性调度 Soft Affinity Scheduling
感知负载的调度
查询准入控制
CTE 调度优化
Union 调度优化

本文由 mdnice 多平台发布