이 기사는 HUAWEI CLOUD 커뮤니티 " SQL 성능 최적화를 수행하는 것은 정말 눈길을 사로잡습니다 ", 저자: Shi Zhenzhen의 식료품점에서 공유됩니다.
많은 빅데이터 계산이 SQL로 구현되는데, 느리게 실행될 때는 SQL을 최적화해야 하는데, 사람을 현혹시키는 상황이 종종 발생합니다. 예를 들어 다음과 같은 저장 프로시저의 세 문은 실행 속도가 느립니다.
select a,b,sum(x) from T group by a,b where …;
select c,d,max(y) from T group by c,d where …;
select a,c,avg(y),min(z) from T group by a,c where …;
复制代码여기서 T는 수억 개의 행이 있는 거대한 테이블이며 세 가지 방법으로 그룹화해야 하며 그룹화 결과 집합이 크지 않습니다.
그룹핑 연산은 데이터 테이블을 순회해야 하며, 이 세 개의 SQL 문장은 큰 테이블을 세 번 순회해야 하며, 세 번은 말할 것도 없이 수억 행의 데이터를 순회하는 데 오랜 시간이 걸립니다. 이 그룹화 작업에서 CPU 컴퓨팅 시간은 하드 디스크를 탐색하는 시간에 비해 거의 무시할 수 있습니다. 하나의 순회에서 여러 그룹화 요약을 계산할 수 있다면 CPU 계산량은 줄어들지 않지만 하드 디스크에서 읽는 데이터 양은 크게 줄일 수 있고 속도는 두 배로 높일 수 있습니다. SQL이 다음과 같은 구문을 지원하는 경우:
from T -- 数据来自 T 表
select a,b,sum(x) group by a,b where … -- 遍历中的第一种分组
select c,d,max(y) group by c,d where … -- 遍历中的第二种分组
select a,c,avg(y),min(z) group by a,c where …; -- 遍历中的第三种分组
复制代码한 번에 여러 결과 집합을 반환할 수 있으면 성능이 크게 향상될 수 있습니다.
안타깝게도 SQL에는 이러한 구문이 없으므로 이러한 명령문을 작성하는 것은 불가능하며 해결 방법은 그룹 a, b, c, d의 작성 방법을 사용하여 먼저 더 자세한 그룹화 결과를 계산하는 것뿐입니다. 설정하지만 먼저 SQL을 사용하여 대상 결과를 계산하기 위해 임시 테이블로 저장합니다. SQL은 대략 다음과 같습니다.
create table T_temp as select a,b,c,d,
sum(case when … then x else 0 end) sumx,
max(case when … then y else null end) maxy,
sum(case when … then y else 0 end) sumy,
count(case when … then 1 else null end) county,
min(case when … then z else null end) minz
group by a,b,c,d;
select a,b,sum(sumx) from T_temp group by a,b where …;
select c,d,max(maxy) from T_temp group by c,d where …;
select a,c,sum(sumy)/sum(county),min(minz) from T_temp group by a,c where …;
复制代码이것은 한 번만 통과하면 되지만 이전의 경우로 다른 WHERE 조건을 전달하려면 코드가 훨씬 복잡해지고 계산량이 늘어납니다. 또한, 임시 테이블의 그룹핑 필드의 수가 많아지면 결과 집합이 매우 커질 수 있으며, 마지막으로 임시 테이블을 여러 번 탐색하게 되어 계산 성능이 빠르지 않다. 큰 결과 집합 그룹화 계산에도 하드 디스크 캐시가 필요하며 성능도 매우 나쁩니다.
저장 프로시저의 데이터베이스 커서를 사용하여 계산을 위해 데이터를 하나씩 가져올 수도 있지만 WHERE 및 GROUP 작업을 모두 직접 구현해야 합니다. 쓰기가 너무 번거롭고 데이터베이스 커서의 성능이 데이터를 트래버스하면 더 나빠질 것입니다! 응시만 가능!
TopN 작업에서도 이러한 종류의 무력감이 발생합니다. 예를 들어 Oracle의 SQL을 사용하여 top5를 작성하는 것은 대략 다음과 같습니다.
select * from (select x from T order by x desc) where rownum<=5
复制代码表 T 有 10 亿条数据，从 SQL 语句来看，是将全部数据大排序后取出前 5 名，剩下的排序结果就没用了！大排序成本很高，数据量很大内存装不下，会出现多次硬盘数据倒换，计算性能会非常差！
避免大排序并不难，在内存中保持一个 5 条记录的小集合，遍历数据时，将已经计算过的数据前 5 名保存在这个小集合中，取到的新数据如果比当前的第 5 名大，则插入进去并丢掉现在的第 5 名，如果比当前的第 5 名要小，则不做动作。这样做，只要对 10 亿条数据遍历一次即可，而且内存占用很小，运算性能会大幅提升。
这种算法本质上是把 TopN 也看作与求和、计数一样的聚合运算了，只不过返回的是集合而不是单值。SQL 要是能写成这样：select top(x,5) from T 就能避免大排序了。
然而非常遗憾，SQL 没有显式的集合数据类型，聚合函数只能返回单值，写不出这种语句！
不过好在全集的 TopN 比较简单，虽然 SQL 写成那样，数据库却通常会在工程上做优化，采用上述方法而避免大排序。所以 Oracle 算那条 SQL 并不慢。
但是，如果 TopN 的情况复杂了，用到子查询中或者和 JOIN 混到一起的时候，优化引擎通常就不管用了。比如要在分组后计算每组的 TopN，用 SQL 写出来都有点困难。Oracle 的 SQL 写出来是这样：
select * from
(select y,x,row_number() over (partition by y order by x desc) rn from T)
where rn<=5
复制代码这时候，数据库的优化引擎就晕了，不会再采用上面说的把 TopN 理解成聚合运算的办法。只能去做排序了，结果运算速度陡降！
假如 SQL 的分组 TopN 能这样写：
select y,top(x,5) from T group by y
复制代码把 top 看成和 sum 一样的聚合函数，这不仅更易读，而且也很容易高速运算。 可惜，不行。
还是干瞪眼！
关联计算也是很常见的情况。以订单和多个表关联后做过滤计算为例，SQL 大体是这个样子：
select o.oid,o.orderdate,o.amount
from orders o
left join city ci on o.cityid = ci.cityid
left join shipper sh on o.shid=sh.shid
left join employee e on o.eid=e.eid
left join supplier su on o.suid=su.suid
where ci.state='New York'
and e.title = 'manager'
and ...
复制代码订单表有几千万数据，城市、运货商、雇员、供应商等表数据量都不大。过滤条件字段可能会来自于这些表，而且是前端传参数到后台的，会动态变化。
SQL 一般采用 HASH JOIN 算法实现这些关联，要计算 HASH 值并做比较。每次只能解析一个 JOIN，有 N 个 JOIN 要执行 N 遍动作，每次关联后都需要保持中间结果供下一轮使用，计算过程复杂，数据也会被遍历多次，计算性能不好。
通常，这些关联的代码表都很小，可以先读入内存。如果将订单表中的各个关联字段预先做序号化处理，比如将雇员编号字段值转换为对应雇员表记录的序号。那么计算时，就可以用雇员编号字段值（也就是雇员表序号），直接取内存中雇员表对应位置的记录，性能比 HASH JOIN 快很多，而且只需将订单表遍历一次即可，速度提升会非常明显！ 也就是能把 SQL 写成下面的样子：
select o.oid,o.orderdate,o.amount
from orders o
left join city c on o.cid = c.# -- 订单表的城市编号通过序号 #关联城市表
left join shipper sh on o.shid=sh.# -- 订单表运货商号通过序号 #关联运货商表
left join employee e on o.eid=e.# -- 订单表的雇员编号通过序号 #关联雇员表
left join supplier su on o.suid=su.# -- 订单表供应商号通过序号 #关联供应商表
where ci.state='New York'
and e.title = 'manager'
and ...
复制代码可惜的是，SQL 使用了无序集合概念，即使这些编号已经序号化了，数据库也无法利用这个特点，不能在对应的关联表这些无序集合上使用序号快速定位的机制，只能使用索引查找，而且数据库并不知道编号被序号化了，仍然会去计算 HASH 值和比对，性能还是很差！
有好办法也实施不了，只能再次干瞪眼！
还有高并发帐户查询，这个运算倒是很简单：
select id,amt,tdate,… from T
where id='10100'
and tdate>= to_date('2021-01-10', 'yyyy-MM-dd')
and tdate<to_date('2021-01-25', 'yyyy-MM-dd')
and …
复制代码在 T 表的几亿条历史数据中，快速找到某个帐户的几条到几千条明细，SQL 写出来并不复杂，难点是大并发时响应速度要达到秒级甚至更快。为了提高查询响应速度，一般都会对 T 表的 id 字段建索引：
create index index_T_1 on T(id)
复制代码在数据库中，用索引查找单个帐户的速度很快，但并发很多时就会明显变慢。原因还是上面提到的 SQL 无序理论基础，总数据量很大，无法全读入内存，而数据库不能保证同一帐户的数据在物理上是连续存放的。硬盘有最小读取单位，在读不连续数据时，会取出很多无关内容，查询就会变慢。高并发访问的每个查询都慢一点，总体性能就会很差了。在非常重视体验的当下，谁敢让用户等待十秒以上！
容易想到的办法是，把几亿数据预先按照帐户排序，保证同一帐户的数据连续存储，查询时从硬盘上读出的数据块几乎都是目标值，性能就会得到大幅提升。
그러나 SQL 시스템을 사용하는 관계형 데이터베이스는 이러한 인식이 없으며 데이터 저장의 물리적 순서를 강제하지 않습니다! 이 문제는 SQL 구문에 의해 발생하는 것이 아니라 SQL의 이론적 근거와도 관련이 있으며 이러한 알고리즘은 관계형 데이터베이스에서 구현할 수 없습니다.
지금이게 뭐야? 그냥 쳐다봐도 돼?
더 이상 SQL 및 관계형 데이터베이스를 사용하여 다른 컴퓨팅 엔진을 사용할 수 없습니다.
오픈 소스 esProc SPL은 혁신적인 이론적 토대를 기반으로 하고 더 많은 데이터 유형과 작업을 지원하며 위의 시나리오에서 새로운 알고리즘을 설명할 수 있습니다. 간단하고 편리한 SPL로 코드를 작성하면 짧은 시간에 컴퓨팅 성능을 크게 향상시킬 수 있습니다!
위의 문제에 대해 SPL로 작성된 코드 샘플은 다음과 같습니다.
한 번에 여러 그룹 계산
집계로 Top5 계산
Complete Works Top5(다중 스레드 병렬 컴퓨팅)
Group Top5(다중 스레드 병렬 컴퓨팅)
일련 번호와 관련된 SPL 코드:
시스템 초기화
조회
높은 동시 계정 쿼리에 대한 SPL 코드:
데이터 전처리, 질서정연한 저장
계정 조회
이러한 간단한 예 외에도 SPL은 주문과 세부 정보 간의 연관을 실현하기 위한 순서 병합, 다차원 분석에서 다차원 테이블 연관을 실현하기 위한 사전 연관 기술 및 비트 저장과 같은 보다 고성능 알고리즘을 구현할 수도 있습니다. 수천 개의 레이블을 실현하는 기술 통계 및 부울 수집 기술은 여러 열거 값 필터 조건의 쿼리 속도를 높이고 시계열 그룹화 기술은 복잡한 깔때기 분석 등을 실현할 수 있습니다.
SQL 성능 최적화에 어려움을 겪고 있는 친구들이 와서 우리와 논의하십시오.
SPL 다운로드 주소 : c.raqsoft.com.cn/article/159…
SPL 오픈 소스 주소 : github.com/SPLWare/esP…