域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

我們都知道數(shù)據(jù)在緩存中訪問(wèn)遠(yuǎn)比在磁盤(pán)中訪問(wèn)速度要快，那么我們?cè)趺丛趐g中將指定的數(shù)據(jù)加載到緩存中呢，這有點(diǎn)類似于Oracle的in-memory。

當(dāng)然要注意并不是把數(shù)據(jù)加載到內(nèi)存中就一定是好的，因?yàn)橄噍^于磁盤(pán)，內(nèi)存總是有限的，所以一幫我們只是在特殊場(chǎng)合下將需要的數(shù)據(jù)加載到內(nèi)存中來(lái)加快訪問(wèn)的速度。

我們可以使用pg_prewarm插件來(lái)將指定的表加載到OS Buffer或者pg shared buffer中。

安裝：

bill=# create extension pg_prewarm ;
CREATE EXTENSION

性能測(cè)試：

構(gòu)建測(cè)試表t1，t2，分別插入1000W條測(cè)試數(shù)據(jù)

bill=# create table t1(id int,info text);
CREATE TABLE
bill=# create table t2(id int,info text);
CREATE TABLE
bill=# insert into t1 select generate_series(1,10000000),md5(random()::text);
INSERT 0 10000000
bill=# insert into t2 select generate_series(1,10000000),md5(random()::text);
INSERT 0 10000000

測(cè)試前先清空shared_buffer，可以使用下面sql查看shared_buffer使用情況：

安裝pg_buffercache插件：

bill=# create extension pg_buffercache;
CREATE EXTENSION

查詢shared_buffer使用情況：

SELECT
    c.relname,
    count(*) AS buffers
FROM pg_buffercache b
INNER JOIN pg_class c
   ON b.relfilenode = pg_relation_filenode(c.oid)
    AND b.reldatabase IN (0, (SELECT oid FROM pg_database
WHERE datname = current_database()))
GROUP BY c.relname
ORDER BY 2 DESC;
                 relname                 | buffers
-----------------------------------------+---------
 pg_attribute                            |      36
 pg_proc                                 |      27
 pg_class                                |      15
 pg_operator                             |      14
 pg_depend_reference_index               |      13
 pg_depend                               |      11
 pg_attribute_relid_attnum_index         |      10
 pg_proc_proname_args_nsp_index          |       9
......

可以看到t1和t2表均不在shared_buffer中，我們來(lái)手動(dòng)將t2表加載到shared_buffer中。

bill=# SELECT pg_prewarm('t2');
 pg_prewarm
------------
      83334
(1 row)

性能測(cè)試：

可以看到全表掃描t2表的性能要提升不少。

bill=# explain analyze select * from t1;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..183334.80 rows=10000080 width=37) (actual time=0.060..772.902 rows=10000000 loops=1)
 Planning Time: 0.294 ms
 Execution Time: 1044.922 ms
(3 rows)

Time: 1045.722 ms (00:01.046)

bill=# explain analyze select * from t2;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Seq Scan on t2  (cost=0.00..183334.80 rows=10000080 width=37) (actual time=0.012..519.691 rows=10000000 loops=1)
 Planning Time: 0.280 ms
 Execution Time: 790.607 ms
(3 rows)

Time: 791.314 mspg_prewarm其它介紹：

下面主要介紹下pg_prewarm函數(shù)：

該函式的創(chuàng)建語(yǔ)句如下：

CREATE FUNCTION pg_prewarm(regclass,
mode text default buffer,
fork text default main,
first_block int8 default null,
last_block int8 default null)
RETURNS int8
AS MODULE_PATHNAME, pg_prewarm
LANGUAGE C

參數(shù)如下：

regclass：要做prewarm的表名

mode：prewarm模式。prefetch表示異步預(yù)取到os cache；read表示同步預(yù)??；buffer表示同步讀入PG的shared buffer

fork：relation fork的類型。一般用main，其他類型有visibilitymap和fsm

first_block & last_block：開(kāi)始和結(jié)束塊號(hào)。表的first_block=0，last_block可通過(guò)pg_class的relpages字段獲得

RETURNS int8：函數(shù)返回pg_prewarm處理的block數(shù)目（整型）

可能有人會(huì)想：我直接將表select *全表查詢一遍不就可以將數(shù)據(jù)加載到緩存中了嘛，為什么還需要使用pg_prewarm呢？因?yàn)閷?duì)于大小超過(guò)shared_buffer/4的表進(jìn)行全表掃描時(shí)，pg一般不會(huì)使用全部的shared_buffer，而是只使用很少一部分的shared_buffer。所以，將大表加載到緩存中不能用一個(gè)查詢來(lái)直接實(shí)現(xiàn)的，而pg_prewarm正好可以滿足這個(gè)需求。

文章來(lái)源：腳本之家

來(lái)源地址：https://www.jb51.net/article/209711.htm

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！