Services Management”即“服務(wù)”中停止相應(yīng)的PostgreSQL服務(wù) 方式二：通過命令行“NET STOPpostgresql-x64-9.1”停止相應(yīng)的PostgreSQL服務(wù)Step 2:修改注冊表對應(yīng)鍵值位置在"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \postgresql-x64-9。
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、印臺網(wǎng)絡(luò)推廣、微信小程序定制開發(fā)、印臺網(wǎng)絡(luò)營銷、印臺企業(yè)策劃、印臺品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供印臺建站搭建服務(wù)，24小時(shí)服務(wù)熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
序列數(shù)可以增加postgresql數(shù)據(jù)表的檢索速度，同時(shí)降低數(shù)據(jù)查詢時(shí)的資源消耗。那么如何在postgresql中創(chuàng)建序列數(shù)并且應(yīng)用呢？下面我給大家分享一下。
工具/材料
pgAdmin4
創(chuàng)建序列數(shù)
首先打開pgAdmin4，展開postgresql數(shù)據(jù)庫，找到模式下面的public選項(xiàng)，如下圖所示
接下來在public下面右鍵單擊序列，然后點(diǎn)擊Create下面的sequence選項(xiàng)，如下圖所示
在彈出的創(chuàng)建Sequence界面中首先給序列數(shù)起一個名字，如下圖所示，注意都用英文
然后切換到Definition頁卡，定義一下序列的增加量，如下圖所示，其中maximum根據(jù)自己的需要進(jìn)行設(shè)置
最后回到數(shù)據(jù)庫主界面，你會看到序列下面多出了一個項(xiàng)，這就是我們創(chuàng)建的序列數(shù)了，如下圖所示
在數(shù)據(jù)表中應(yīng)用序列數(shù)
首先選中一個數(shù)據(jù)表，點(diǎn)擊右側(cè)的編輯按鈕，如下圖所示
在彈出的編輯界面中切換到Columns頁卡，點(diǎn)擊ID簽名的編輯按鈕，如下圖所示
最后在字段的編輯界面中切換到Variables選項(xiàng)卡，然后在Value列中通過nextval函數(shù)帶入剛才定義的序列數(shù)即可，如下圖所示
PostgreSQL自帶有一個簡易的全文檢索引擎，可以實(shí)現(xiàn)小規(guī)模數(shù)據(jù)量的全文檢索功能。本文我們將引導(dǎo)介紹一下這個功能，對于小數(shù)據(jù)量的搜索這個功能是足夠使用的，而無需搭建額外的ES等重量級的全文檢索服務(wù)器。
PG的全文檢索操作符是 @@ ，當(dāng)一個 tsvector (文檔)和 tsquery (條件)匹配時(shí)返回 true ，并且前后順序無影響:
和普通的SQL查詢一樣，只要在 WHERE 條件中使用這個符號就代表使用全文檢索條件篩選文檔了。如:
@@ 操作符支持隱式轉(zhuǎn)換，對于 text 類型可以無需強(qiáng)類型轉(zhuǎn)換( ::tsvector 或 to_tsvector(config_name, text) )，所以這個操作符實(shí)際支持的參數(shù)類型是這樣的:
tsquery 查詢條件并不是簡單的正則，而是一組搜索術(shù)語，使用并且使用布爾操作符 （AND）、 | （OR）和 ! （NOT）來組合它們，還有短語搜索操作符 - （FOLLOWED BY）。更詳細(xì)的語法參見 此文檔 。
此外，PostgreSQL還提供了兩個相對簡化的版本 plainto_tsquery 和 phraseto_tsquery 。
plainto_tsquery ( plainto_tsquery([ config regconfig, ] querytext text) returns tsquery )用戶將未格式化的 text 經(jīng)過分詞之后，插入 符號轉(zhuǎn)為 tsquery :
phraseto_tsquery ( phraseto_tsquery([ config regconfig, ] querytext text) returns tsquery )行為和 plainto_tsquery 行為類似，但是分詞之后不是插入 而是 - (FOLLOWED BY):
使用索引可以加快全文檢索的速度。對于全文檢索來說，可選的索引類型是 GIN (通用倒排索引)和 GIST (通用搜索樹)，官方文檔更推薦使用 GIN索引 。創(chuàng)建一個 GIN 索引的范例:
也可以是一個連接列:
還可以單獨(dú)創(chuàng)建一個 tsvector 列，為這個列創(chuàng)建索引:
除了普通的 ORDER BY 條件之外，PostgreSQL為全文檢索提供了兩個可選的排序函數(shù) ts_rank([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4 和 ts_rank_cd([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4 ，以便實(shí)現(xiàn)基于 權(quán)重 的排序。
此外，對于PostgreSQL 9.6以上的版本還可以使用 RUM index 排序。(注意，這個是擴(kuò)展，默認(rèn)不包含)。
PostgreSQL默認(rèn)的分詞字典中并不包含中文分詞字典，因此我們必須手工引入。目前一個比較好的項(xiàng)目是 zhparser ，同時(shí)這個插件也是阿里云的RDS默認(rèn)包含的。安裝和啟用沒什么好說的。值得一提的是分詞配置參數(shù)。
在 CREATE EXTENSION 之后，必須配置分詞參數(shù)才能正確進(jìn)行分詞和查找，否則什么都查不到。官方文檔提供的一個配置策略是:
n,v,a,i,e,l 這幾個字母分別表示一種token策略，只啟用了這幾種token mapping，其余則被屏蔽。具體支持的參數(shù)和含義可以用 \dFp+ zhparser 顯示:
WITH simple 表示詞典使用的是內(nèi)置的simple詞典，即僅做小寫轉(zhuǎn)換。根據(jù)需要可以靈活定義詞典和token映射，以實(shí)現(xiàn)屏蔽詞和同義詞歸并等功能。
比如我們看下面這個例子:
可以看到 江淮 這個詞組在查詢的時(shí)候被忽略了，我們啟用 j (abbreviation,簡稱)再看看結(jié)果:
所以實(shí)際使用中要設(shè)置合理的token types，過少將導(dǎo)致搜索結(jié)果不準(zhǔn)確，過多將導(dǎo)致性能下降。此外，還有一些諸如 短詞復(fù)合: zhparser.multi_short = f 這一類的控制分詞結(jié)果的選項(xiàng)，根據(jù)實(shí)際使用酌情開啟。
壓縮表從名字上來看，簡單理解為壓縮后的表，也就是把原始表根據(jù)一定的壓縮算法按照一定的壓縮比率壓縮后生成的表。
1.1 壓縮能力強(qiáng)的產(chǎn)品
表壓縮后從磁盤占用上看要比原始表要小很多。如果你熟悉列式數(shù)據(jù)庫，那對這個概念一定不陌生。比如，基于 PostgreSQL 的列式數(shù)據(jù)庫 Greenplum；早期基于 MySQL 的列式數(shù)據(jù)庫 inforbright；或者 Percona 的產(chǎn)品 tokudb 等，都是有壓縮能力非常強(qiáng)的數(shù)據(jù)庫產(chǎn)品。
1.2 為什么要用壓縮表？
情景一：磁盤大小為 1T，不算其他的空間占用，只能存放 10 張 100G 大小的表。如果這些表以一定的比率壓縮后，比如每張表從 100G 壓縮到 10G，那同樣的磁盤可以存放 100 張表，表的容量是原來的 10 倍。情景二：默認(rèn) MySQL 頁大小 16K，而 OS 文件系統(tǒng)一般塊大小為 4K，所以在 MySQL 在刷臟頁的過程中，有一定的概率出現(xiàn)頁沒寫全而導(dǎo)致數(shù)據(jù)壞掉的情形。比如 16K 的頁寫了 12K，剩下 4K 沒寫成功，導(dǎo)致 MySQL 頁數(shù)據(jù)損壞。這個時(shí)候就算通過 Redo Log 也恢復(fù)不了，因?yàn)閹缀跤兴械年P(guān)系數(shù)據(jù)庫采用的 Redo Log 都記錄了數(shù)據(jù)頁的偏移量，此時(shí)就算通過 Redo Log 恢復(fù)后，數(shù)據(jù)也是錯誤的。所以 MySQL 在刷臟數(shù)據(jù)之前，會把這部分?jǐn)?shù)據(jù)先寫入共享表空間里的 DOUBLE WRITE BUFFER 區(qū)域來避免這種異常。此時(shí)如果 MySQL 采用壓縮表，并且每張表頁大小和磁盤塊大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，這部分開銷就可以規(guī)避掉了。查看文件系統(tǒng)的塊大小：
root@ytt-pc:/home/ytt#??tune2fs?-l?/dev/mapper/ytt--pc--vg-root??|?grep?-i?'block?size'Block size: ? ? ? ? ? ? ? 4096
1.3 壓縮表的優(yōu)勢
壓縮表的優(yōu)點(diǎn)非常明顯，占用磁盤空間??！由于占用空間小，從磁盤置換到內(nèi)存以及之后經(jīng)過網(wǎng)絡(luò)傳輸都非常節(jié)省資源。
簡單來講：節(jié)省磁盤 IO，減少網(wǎng)絡(luò) IO。
1.4 壓縮表的缺陷
當(dāng)然壓縮表也有缺點(diǎn)，壓縮表的寫入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 資源。
壓縮表的寫入涉及到解壓數(shù)據(jù)，更新數(shù)據(jù)，再壓縮數(shù)據(jù)，比普通表多了解壓和再壓縮兩個步驟，壓縮和解壓縮需要消耗一定的 CPU 資源。所以需要選擇一個比較優(yōu)化的壓縮算法。
1.5 MySQL 支持的壓縮算法
這塊是 MySQL 所有涉及到壓縮的基礎(chǔ)，不僅僅用于壓縮表，也用于其它地方。比如客戶端請求到 MySQL 服務(wù)端的數(shù)據(jù)壓縮；主從之間的壓縮傳輸；利用克隆插件來復(fù)制數(shù)據(jù)庫操作的壓縮傳輸?shù)鹊取?/p>
從下面結(jié)果可以看到 MySQL 支持的壓縮算法為 zlib 和 zstd，MySQL 默認(rèn)壓縮算法為 zlib，當(dāng)然你也可以選擇非 zlib 算法，比如 zstd。至于哪種壓縮算法最優(yōu)，暫時(shí)沒辦法簡單量化，依賴表中的數(shù)據(jù)分布或者業(yè)務(wù)請求。
1. 概述
cstore_fdw實(shí)現(xiàn)了 PostgreSQL 數(shù)據(jù)庫的列式存儲。列存儲非常適合用于數(shù)據(jù)分析的場景，數(shù)據(jù)分析的場景下數(shù)據(jù)是批量加載的。
這個擴(kuò)展使用了Optimized Row Columnar (ORC)數(shù)據(jù)存儲格式，ORC改進(jìn)了Facebook的RCFile格式，帶來如下好處:
壓縮:將內(nèi)存和磁盤中數(shù)據(jù)大小削減到2到4倍。可以擴(kuò)展以支持不同壓縮算法。
列投影:只提取和查詢相關(guān)的列數(shù)據(jù)。提升IO敏感查詢的性能。
跳過索引:為行組存儲最大最小統(tǒng)計(jì)值，并利用它們跳過無關(guān)的行。
2. 使用
cstore_fdw的安裝和使用都非常簡單，可以參考官方資料。
thub.com/citusdata/cstore_fdw
注)注意cstore_fdw只支持PostgreSQL9.3和9.4 。
下面做幾個簡單的性能對比，看看cstore_fdw究竟能帶來多大的性能提升。
2.1 數(shù)據(jù)加載
2.1.1 普通表
CREATE TABLE tb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
);
注:要和普通表的全表掃描作對比，所以不建主鍵和索引。
[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy tb1 from STDIN with CSV"
COPY 10000000
1.56user 1.00system 6:42.39elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
776inputs+0outputs (17major+918minor)pagefaults 0swaps
real 6m42.402s
user 0m15.174s
sys 0m14.904s
postgres=# select pg_total_relation_size('tb1'::regclass);
pg_total_relation_size
------------------------
1161093120
(1 row)
postgres=# \timing
Timing is on.
postgres=# analyze tb1;
ANALYZE
Time: 11985.070 ms
插入1千萬條記錄，數(shù)據(jù)占用存儲大小1.16G，插入耗時(shí)6分42秒，分析耗時(shí)12秒。
2.1.2 cstore表
$ mkdir -p /home/chenhj/data94/cstore
CREATE EXTENSION cstore_fdw;
CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;
CREATE FOREIGN TABLE cstb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
)
SERVER cstore_server
OPTIONS(filename '/home/chenhj/data94/cstore/cstb1.cstore',
compression 'pglz');
[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text, id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy cstb1 from STDIN with CSV"
COPY 10000000
1.53user 0.78system 7:35.15elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
968inputs+0outputs (20major+920minor)pagefaults 0swaps
real 7m35.520s
user 0m14.809s
sys 0m14.170s
[postgres@node2 chenhj]$ ls -l /home/chenhj/data94/cstore/cstb1.cstore
-rw------- 1 postgres postgres 389583021 Jun 23 17:32 /home/chenhj/data94/cstore/cstb1.cstore
postgres=# \timing
Timing is on.
postgres=# analyze cstb1;
ANALYZE
Time: 5946.476 ms
插入1千萬條記錄，數(shù)據(jù)占用存儲大小390M，插入耗時(shí)7分35秒，分析耗時(shí)6秒。
使用cstore列存儲后，數(shù)據(jù)占用存儲大小降到普通表的3分之1。需要說明的是，由于所有TEXT列填充了隨機(jī)數(shù)據(jù)，壓縮率不算高，某些實(shí)際的應(yīng)用場景下壓縮效果會比這更好。
2.2 Text列的like查詢性能對比
2.2.1 普通表
清除文件系統(tǒng)緩存，并重啟PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# free
total used free shared buffers cached
Mem: 2055508 771356 1284152 0 9900 452256
-/+ buffers/cache: 309200 1746308
Swap: 4128760 387624 3741136
[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches
[root@node2 ~]# free
total used free shared buffers cached
Mem: 2055508 326788 1728720 0 228 17636
-/+ buffers/cache: 308924 1746584
Swap: 4128760 381912 3746848
對Text列執(zhí)行l(wèi)ike查詢
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.42 0.00 95.40
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.55 330.68 212.08 7351441 4714848
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)
real 0m7.051s
user 0m0.001s
sys 0m0.004s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.39
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.90 381.53 211.90 8489597 4714956
耗時(shí)7.1秒，產(chǎn)生IO讀1.14G,IO寫108K。
不清文件系統(tǒng)緩存，不重啟PostgreSQL，再執(zhí)行一次。消耗時(shí)間降到1.6秒，幾乎不產(chǎn)生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.39
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.81 332.20 213.06 7350301 4714364
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)
real 0m1.601s
user 0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.38
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.80 332.12 213.01 7350337 4714364
2.2.2 cstore表
清除文件系統(tǒng)緩存，并重啟PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches
對Text列執(zhí)行l(wèi)ike查詢
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.38 0.00 95.45
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.12 376.42 209.04 8492017 4716048
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)
real 0m2.786s
user 0m0.002s
sys 0m0.003s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.38 0.00 95.44
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.12 378.75 208.89 8550761 4716048
耗時(shí)2.8秒，產(chǎn)生IO讀59M,IO寫0K。執(zhí)行時(shí)間優(yōu)化的雖然不是太多，但I(xiàn)O大大減少，可見列投影起到了作用。
不清文件系統(tǒng)緩存，不重啟PostgreSQL，再執(zhí)行一次。消耗時(shí)間降到1.4秒，幾乎不產(chǎn)生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.36 0.00 95.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.75 376.33 207.58 8550809 4716524
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)
real 0m1.424s
user 0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.36 0.00 95.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.70 375.96 207.38 8550809 4716588
2.3 對Int列執(zhí)行=查詢
2.3.1 普通表
清除文件系統(tǒng)緩存，并重啟PostgreSQL后
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches
對Int列執(zhí)行=查詢
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.33 0.00 95.50
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.25 373.21 205.67 8560897 4717624
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------
1
(1 row)
real 0m6.844s
user 0m0.002s
sys 0m0.006s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.34 0.00 95.49
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.60 422.57 205.54 9699161 4717708
耗時(shí)6.8秒，產(chǎn)生IO讀1.14G,IO寫84K
不清緩存，再執(zhí)行一次。消耗時(shí)間降到1.1秒，幾乎不產(chǎn)生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.33 0.00 95.50
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.44 421.37 204.97 9699177 4718032
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------
1、在查詢的時(shí)候一般使用*查詢代表查詢所有字段信息，但表太大就不建議使用這種方式。
2、在查詢的時(shí)候也可以指定字段進(jìn)行查詢，如下圖只查詢表中的一部分字段信息。
3、不過最經(jīng)常使用的查詢是指定特殊的條件來進(jìn)行查詢，以便查詢結(jié)果更為精確。
4、在查詢的時(shí)候有時(shí)也需要對查詢結(jié)果進(jìn)行適當(dāng)?shù)呐判?，這樣可以快速定位要查詢數(shù)據(jù)的結(jié)果。
5、在查詢的時(shí)候也可以指定特殊的查詢范圍，根據(jù)指定的查詢范圍來查詢出特定結(jié)果。
重慶分公司
重慶分公司
