大多數(shù)用戶在體驗(yàn)數(shù)據(jù)庫時(shí)，接觸到的最早的sql語句就是count(*)，因此用戶判斷數(shù)據(jù)庫性能時(shí)通常也會(huì)通過count(*)進(jìn)行比較。但在執(zhí)行時(shí)通常會(huì)出現(xiàn)一個(gè)問題：對某個(gè)表做count(*)時(shí)需對全表數(shù)據(jù)進(jìn)行掃描，當(dāng)表中包含數(shù)據(jù)量較大的字段時(shí)，IO將會(huì)成為數(shù)據(jù)掃描的瓶頸。

數(shù)據(jù)掃描瓶頸有哪些優(yōu)化方式？

針對上述問題，為解決全表掃描帶來的IO開銷的方案大致可分為三類：

第一類是減少掃描數(shù)據(jù)；

第二類是通過并行方式掃描數(shù)據(jù)；

第三類是通過預(yù)估值計(jì)算方式獲取結(jié)果。

根據(jù)上述三種方案，我們給出以下四種優(yōu)化方式：

01

減少掃描數(shù)據(jù)

（1）使用列存

顧名思義，列存是按列存儲(chǔ)的。當(dāng)使用count(*)查詢時(shí)，只需要掃描一列數(shù)據(jù)做count統(tǒng)計(jì)，而并非全表，這樣，IO開銷幾乎是行存的1/列數(shù)，即效率是行存的列數(shù)倍。在實(shí)際使用中，因?yàn)槊苛凶侄伍L度的原因，使用列存時(shí)count(*)效率往往要比這個(gè)值還要高得多。

（2）使用Index only scan

使用主鍵的Index only scan，count(*)僅需掃描主鍵的索引鏈表即可，不必掃描所有的數(shù)據(jù)塊，因此可大大減少IO開銷。

02

并行掃描數(shù)據(jù)

（1）MPP架構(gòu)

使用MPP架構(gòu)的好處是讓數(shù)據(jù)分布到各個(gè)計(jì)算節(jié)點(diǎn)上。這樣，在使用count(*)查詢時(shí)，每個(gè)計(jì)算節(jié)點(diǎn)都會(huì)去統(tǒng)計(jì)該節(jié)點(diǎn)的數(shù)據(jù)量，最終匯聚返回總的數(shù)據(jù)量，這種方式可以更好地利用CPU和磁盤達(dá)到并行掃描的效果，節(jié)省掃描時(shí)間。

03

預(yù)估值計(jì)算

（1）Hyperloglog

HyperLogLog算法來源于論文《HyperLogLog the analysis of a near-optimal cardinality estimation algorithm》，可以使用固定大小的字節(jié)計(jì)算任意大小的distinct value。由于HLL是概率計(jì)算算法，它依賴于數(shù)據(jù)的均勻分布，在使用時(shí)往往需要我們首先利用HLL對每個(gè)元素進(jìn)行哈希，以使數(shù)據(jù)分布更加均勻。

因此，任何可以哈希的數(shù)據(jù)類型都可以使用HLL算法做統(tǒng)計(jì)估算，HLL算法在數(shù)據(jù)庫的估值統(tǒng)計(jì)計(jì)算方面起到了重要作用。

哪些產(chǎn)品能提供具體優(yōu)化方案？

綜合上述4種優(yōu)化方式，人大金倉悉心打造的MPP數(shù)據(jù)庫KADB具備以上所有特性方案，具體包括：

（1）列存

KADB支持可壓縮列存儲(chǔ)，壓縮比可達(dá)1:10。建表語句如下：

create table t_count(id uuid, num int) with

(appendonly=true,orientation=column,compresstype=zlib,compresslevel=5);

（2）Index only scan

KADB支持index only scan，執(zhí)行計(jì)劃如下：

explain select count(*) from t_count ;

QUERY PLAN

------------------------------------------------------------------------------------------------------------------

Aggregate (cost=17403254.38..17403254.39 rows=1 width=8)

-> Gather Motion 8:1 (slice1; segments: 8) (cost=17403254.27..17403254.37 rows=1 width=8)

-> Aggregate (cost=17403254.27..17403254.28 rows=1 width=8)

-> Index Only Scan using idx_t_count_id on t_count (cost=0.19..17153253.65 rows=12500031 width=0)

（3）MPP架構(gòu)

KADB是人大金倉基于Kingbase ES 單機(jī)數(shù)據(jù)庫打造的MPP數(shù)據(jù)庫，具有一切皆并行的特點(diǎn)。

（4）Hyperloglog

KADB集成了HLL插件。具體操作如下：

創(chuàng)建計(jì)數(shù)表，并插入1億條數(shù)據(jù)，id列重復(fù)值較少：

create table t_count(id uuid, num int);

--創(chuàng)建插入函數(shù)，id值為uuid，無重復(fù)值

create or replace function f_insert(i int) returns setof record as $$

select uuid_generate_v4(), generate_series(1,i);

$$ language sql;

--插入數(shù)據(jù)

insert into t_count select * from f_insert(100000000) as t(id uuid, num int);

創(chuàng)建HLL統(tǒng)計(jì)表，記錄唯一值：

create table daily_id_hll

as select

gp_hyperloglog_accum(id)

from

t_count;

最終通過HLL算法預(yù)估出t_count的條數(shù)

select gp_hyperloglog_get_estimate(gp_hyperloglog_accum) from daily_id_hll;

gp_hyperloglog_get_estimate

-----------------------------

99651193.2825577

(1 row)

誤差率在0.35%左右

select (100000000-99651193.2825577)/100000000;

?column?

------------------------

0.00348806717442300000

(1 row)

MPP數(shù)據(jù)庫KADB優(yōu)化效果如何？

在此，我們導(dǎo)入1億條數(shù)據(jù)進(jìn)行測試，數(shù)據(jù)總量大小為203GB，測試count(*)比對效率如下：

綜上總述，KADB具備以上所有優(yōu)化方式的解決方案能力，可根據(jù)不同需求優(yōu)化count(*)查詢。在用戶實(shí)際應(yīng)用場景中，

面對實(shí)時(shí)性要求較高但準(zhǔn)確度要求不太高的數(shù)據(jù)可視化服務(wù)，我們通常提供Hyperloglog優(yōu)化方案；

面對實(shí)時(shí)性要求不太高但準(zhǔn)確度要求高的統(tǒng)計(jì)服務(wù)，我們通常提供列存優(yōu)化方案。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的判断字段长度大于某长度_判断数据库性能只能通过count(*)？No，这些优化方案了解一下！...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。