顯示具有 PG獨特技術及特點 標籤的文章。 顯示所有文章
顯示具有 PG獨特技術及特點 標籤的文章。 顯示所有文章

2009-07-05

PostgreSQL 8.4 正式發佈公告

PostgreSQL 全球開發團隊正式對 8.4 版進行發佈,PostgreSQL 是持續長期且快速發展的全球最先進開放源始碼資料庫。本新聞稿中包含了豐富的功能,目標在使 PostgreSQL 資料庫管理,查詢和程序開發可以比以往任何時候都更易於使用。著重於:

  1. 增強高穩定性
  2. 提供更安全可靠的系統
  3. 對執行效能的再優化
  4. 新增與改進管理和監測工具及命令
我們的開發隊團隊花了長達 16 個月,增加了 293 項增強與改進各方面的資料庫功能,協助使用者在每一個 PostgreSQL 小型或大型的應用中。

每次新 PostgreSQL 發佈釋出的功能都隨著比以前來的更多且豐富,這主要來自歸功於我們有著日益增加的全球不同組織對 PostgreSQL 捐助。 8.4 版本增強了 293 項,從實作新的功能所需要的大至數百行 Code(如 Windows Function) ,小至補丁安全性增強,又如作出能讓系統管理員的生活更輕鬆一點(如改進欄位顯示在 psql )。諸多改進,我們無法一一說明他們,您可以參考更詳細的發佈內容說明,但其中有許多人較重視的列於其下。

  • 資料庫級別校對的支持,使得PostgreSQL有更多有用的多語言環境
  • 就地通過 pg_migrator (beta)升級,從而使升級從 8.3版至 8.4版降低大範圍停機過程
  • 新的查詢監控工具,以給予系統管理者更多了解查詢活動訊息
  • 大副減少 VACUUM 經由可視性Map
  • 對目前的查詢,查詢負載和死鎖訊息提供新的監測工具
  • 遞迴查詢運用 recursive queries (for doing trees etc.)
  • 提昇工具使用功能 a beta in-place upgrade tool
  • 改良主機網域空間運作 a host of administrative improvements

8.4版本還使資料分析更容易通過先進的 ANSI SQL 2003 特色視窗函式運用 windowing functions (for doing reports),共用資料表表達式和遞歸查詢。增強的存儲程序,如默認參數和 variadic 參數,讓資料庫服務器的程式開發更簡單,更緊湊。當然,也有一些性能方面的改進包括在此版本。

除此之外,若您需要了解更多訊息,官方新聞稿張貼了8.4版具有高達200多項新功能介紹與資料庫操作的改善,下載版本8.4,並開始使用PostgreSQL的享受更!

或快速下載及安裝PostgreSQL 8.4 版本由 EnterpriseDB 公司提供的一鍵安裝檔:

EnterpriseDB--Installer version Version 8.4.0-1—Max、Linux、Windows

2007-07-18

"分享即學習"的良性互動, 是提升知識的原動力.

更新:2007-07-18
對映章節:
感謝 鄧大哥對這篇文章中的觀念指正
PostgreSQL 與 地理資訊系統 ( Geographic Information Syste...
受制於 Blogger 版面功能的不足, 怕更多想對 PostgreSQL 了解的朋友,
因為阿益的文章中的錯誤, 且可能未留意到 鄧大哥在該篇文章裡留的珍貴意見,
阿益特地將該篇的意見搬上文章區,
順道一提: 我們需要更多像 鄧大哥“分享即學習”的良性互動.……

原意見內容:

阿益,你好
無意中,因為在寫一個教案而查到你的Blog,你們果然是PostgreSQL的專家,Blog的內容很充實,獲益良多。

但本篇關於GIS的部份,有幾點需澄清的:
1.GIS並非只是圖資系統。GIS是一種集合大量處理空間資訊函式庫的系統,以用來分析、儲存、展示地理空間資訊,地圖只是其中一項展示功能。

2.PostgreSQL並非唯一在開放源碼中擁有地理資訊處理能力的。Free/Open Source Software for Geoinformatics(地理資訊開放源碼自由軟體)不下20種,除了PostgreSQL/PostGIS之外,還有GRASS, MapServer, GeoServer, QGIS, OpenEV, DeeGee, Geotools.......,詳細的資訊可到www.osgeo.org查詢。而mySQL with Spatial extension與PostgreSQL/PostGIS對空間資訊也有類似的處理能力。雖然本人為PostgreSQL/PostGIS的愛用者,但 PostgreSQL/PostGIS並非是唯一的選擇。

3.OpenGIS並非是架構上的地理SQL標準。OpenGIS始於北 美,加拿大政府更是極積地發展,Refractions接受加拿大BC省政府不少補助而投入開發符合OpenGIS標準制度的地理資料運算函式,進而發展 出依附在PostgreSQL上的PostGIS。事實上,OpenGIS是一種地理資料開放的概念,OGC(Open Geospatial Consortium)是為了達成此一概念而成立的組織,專門訂立地理空間的標準,這一系列的標準可分為資訊架構(含資訊編碼)和服務架構,其中 PostgreSQL/PostGIS採用對於地理空間資料以Simple Feature for SQL為標準(資訊編碼),並可以接受WKT、WKB、GML等資料格式I/O。


鄧東波
Dongpo Deng
Co-founder, OSGeo Taiwan
dongpo@iis.sinica.edu.tw
My Blog: http://geocyber.org
OSGeo Taiwan: http://wiki.osgeo.org/index.php/Taiwan


延伸閱讀(Link):
PostgreSQL 與 地理資訊系統 ( Geographic Information Syste...

2007-07-08

PostgreSQL 與 地理資訊系統 ( Geographic Information Systems,GIS )

更新:2007-07-08
對映章節:

內容:
前天收到一位關注到 PostgreSQL 功能的長官來信,
問到除了購買 Oracle 數百萬NTD幣值產品外,
是否有更值得投入研究發展的解決方案...
答案是有的 PostgreSQL 在 GIS 上的應用, 另外阿益個人建議這數百萬NTD
幣另加上聘用 Oracle DBA 的每月開發固定成本,
若是全數拿來投入開放源碼的 PostgreSQL 並加以回饋技術與問題到 PostgreSQL
開發團隊中, PostgreSQL 的先進程度一定會更加速進展...
在此順便整理一下 PostgreSQL 這部份的功能強項:

地理資訊系統 ( Geographic Information Systems,GIS )
又被譯為圖資系統, 空間信息系統, 大多用於大型商業地理的研究專案中...

PostgreSQL 是目前最開放且唯一在開放源碼中擁有地理資訊處理能力的
物件關聯型資料庫管理系統,
除了內置的豐富的地理定位用的資料類型(Types)與函數群可用外,
更有獨立的相關地理資訊研究專案 PostGIS, 您可以參考
http://postgis.refractions.net/


OpenGIS 是一個架構上的地理 SQL 標準, 由 OGC 通過生成向量資料(矢量數據)解決了這些問題,向量資料也指幾何物件,如點、線、多邊形及其組合,可以在啟用三維資料庫的 PostgreSQL 中存取(PostgreSQL 的 OpenGIS 實現標準稱為 PostGIS)。
存儲在 PostgreSQL 資料庫中的 GIS 資料完全可以使用 SQL-92 來搜尋。

PostgreSQL 最具體的研究機構是在本站2月份中的文章中
PostgreSQL 子專案與相關站點(彙報篇)中提到的

IGN--法國國家地理學院
http://postgis.refractions.net/documentation/casestudies/ign/

在 PostgreSQL 中已經定義了一些基本的集合實體類型,這些類型包括: 點(POINT)、線(LINE)、線段(LSEG)、方形(BOX)、多邊形(POLYGON)和圓(CIRCLE)等;
另外,PostgreSQL定義了一系列的函數和操作符來實現幾何類型的操作和運算; 同時,PostgreSQL引入空間數據索引 R-tree。

PostGIS 還提供以下功能:

  • 資料庫的坐標變換計算
  • 球型體長度運算
  • 三維的幾何資料類型(Types)
  • 地理空間的聚集函數
  • 地理網格(柵格)標示數據類型
PostGIS 不論在功能還是擴展性方面都不落後於商業 GIS 平台的空間資料庫,
且由於其源始碼的公開性,更加容易吸引廣大愛好者參與到 PostGIS 的開發中,
不斷完善並持續改良現有的功能同時進一步擴展新的特性。
當然也更歡迎您成為其中的一份力量...

延伸閱讀(Link):
IBM - Find your way around open source GIS
PostGIS开启开源空间数据库的未来

2007-06-07

PostgreSQL 系統安全認證(一)

更新:2007-06-07
對映章節:

內容:
PostgreSQL 是一個非常重視安全性與反饋修補快速的資料庫系統...
也是目前唯一取得 ISO/IEC15408 安全認證的開放源碼專案產品
PostgreSQL 日本NTT協助取得 ISO/IEC15408 安全認證

PostgreSQL 最主要的設計理由:
開發真正能運作在大型企業與政府組織的資料倉儲系統,
因為涉及的使用人數鉅多與強調安全性,
必須擁有嚴密的控管機制存在,
且必須保持快速反應安全性問題修正的能力.

系統安全依賴SA/DBA(系統工程師/資料庫管理師)的經驗累積與能力培養,
安全性調校-涉及的知識與相關操作, 是必須擁有對其基本管理者再進階時,
加以探討的強化部份, 而非本末倒置空談安全性議題,
卻對SA/DBA工作內容半知不解之人.

除了原使用的系統OS的安全防護, 依靠您對使用的作業系統的管理程度能力外,
PostgreSQL 使用了下述幾個層級來進行有關安全性的層級防制力.

層級

  1. SSL連線加密模式(postgreslq.conf)
    • 透過啟用PostgreSQL組態檔的 SSL 加密模式, 來防止封包監聽程序.
  2. 連接用戶認證模式與種類(pg_hba.conf)
    • 可各別對特定的 user, DB, IP, IP-Sub, 使用不同的用戶認證模式.
    • 認證模式的種類包括(詳情->密碼學):
      trust, password, crypt, MD5, Krb4, Krb5, Reject, inetd.
  3. 資料庫物件權限(GRANT, REVOKE)
    1. 對特定的資料庫, 資料表, 進行SQL使用授權管理.
在下個講次, 說明如何進行....

延伸閱讀(Link):

2007-04-23

pgpool-II使用指南-并发查询(二)(簡體)

更新:2007-
對映章節:
本文翻译自源代码包中的“pgpool-II Tutorial”文档

定义数据分布规则
我们将定义把pgbench生成的示例数据分布在三个数据库节点的分布规则,在这个小节中创建名为“bench_parallel”的数据库,并且使用“pgbench -i -s 3”生成示例数据。

在pgpool-II源代码的sample目录能够找到dist_def_pgbench.sql文件,使用这个文件创建数据分布规则,执行如下命令:
$ psql -f sample/dist_def_pgbench.sql -p 5432 pgpool

以下是dist_def_pgbench.sql文件内容的解释。

插入四行数据到数据表“dist_def”中。每个数据表(前边提到过的accounts、branches、tellers以及history)各自有一个不同的分布函数。分别为branches、tellers、accounts 定义bid、tid、aid作为他们的key-columns字段(这几个字段也是他们的主键),history以tid作为key-columns字段。

INSERT INTO pgpool_catalog.dist_def VALUES (
'bench_parallel',
'public',
'branches',
'bid',
ARRAY['bid', 'bbalance', 'filler'],
ARRAY['integer', 'integer', 'character(88)'],
'pgpool_catalog.dist_def_branches'
);

INSERT INTO pgpool_catalog.dist_def VALUES (
'bench_parallel',
'public',
'tellers',
'tid',
ARRAY['tid', 'bid', 'tbalance', 'filler'],
ARRAY['integer', 'integer', 'integer', 'character(84)'],
'pgpool_catalog.dist_def_tellers'
);

INSERT INTO pgpool_catalog.dist_def VALUES (
'bench_parallel',
'public',
'accounts',
'aid',
ARRAY['aid', 'bid', 'abalance', 'filler'],
ARRAY['integer', 'integer', 'integer', 'character(84)'],
'pgpool_catalog.dist_def_accounts'
);

INSERT INTO pgpool_catalog.dist_def VALUES (
'bench_parallel',
'public',
'history',
'tid',
ARRAY['tid', 'bid', 'aid', 'delta', 'mtime', 'filler'],
ARRAY['integer', 'integer', 'integer', 'integer', 'timestamp without time zone', 'character(22)'],
'pgpool_catalog.dist_def_history'
);


接下来,必须为每个表定义分布函数,不同的表可以使用同一个分布函数,并且使用过程语言(PL/pgSQL、PL/Tcl等等)定义而不是SQL。
下边是由pgbench -i -s 3生成的数据概要:

数据表名 数据行数
branches 3
tellers 30
accounts 300000
history 0

继续定义4个函数将上述数据平分到三个节点,根据给出的参数返回0、1或者2

CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_branches(anyelement)
RETURNS integer AS $$
SELECT CASE WHEN $1 > 0 AND $1 <= 1 THEN 0 WHEN $1 > 1 AND $1 <= 2 THEN 1 ELSE 2 END; $$ LANGUAGE sql; CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_tellers(anyelement) RETURNS integer AS $$ SELECT CASE WHEN $1 > 0 AND $1 <= 10 THEN 0 WHEN $1 > 10 AND $1 <= 20 THEN 1 ELSE 2 END; $$ LANGUAGE sql; CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts(anyelement) RETURNS integer AS $$ SELECT CASE WHEN $1 > 0 AND $1 <= 100000 THEN 0 WHEN $1 > 100000 AND $1 <= 200000 THEN 1 ELSE 2 END; $$ LANGUAGE sql; CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_history(anyelement) RETURNS integer AS $$ SELECT CASE WHEN $1 > 0 AND $1 <= 10 THEN 0 WHEN $1 > 10 AND $1 <= 20 THEN 1 ELSE 2 END; $$ LANGUAGE sql;


检验并发查询
重新启动pgpool-II载入pgpool.conf的变化,然后我们来检验一下并发查询是否在正常运行。

首先,命名为“bench_parallel”的分布数据库,通过pgpool-II创建到每一个节点上:
$ createdb -p 9999 bench_parallel

接下来,生成测试数据:
$ pgbench -i -s 3 -p 9999 bench_parallel

预想的数据分布情况:
数据表名 Key-Column名值
节点1 节点2 节点3
branches bid 1 2 3
tellers tid 1 - 10 11 - 20 21 - 30
accounts aid 1 - 100000 100001 - 200000 200001 - 300000
history tid 1 - 10 11 - 20 21 - 30

简单的验证脚本,比较每个节点的结果和pgpool-II的结果:
$ for port in 5432 5433 5434 9999; do
> echo $port
> psql -c "SELECT min(aid), max(aid) FROM accounts" -p $port bench_parallel
> done

(accounts有30万数据,这个愚蠢的脚本不是我写的,除非你是超人,否则用这个脚本什么也不能做。)

今天不在状态,脑子很乱,可能是放假综合症发作。黄金周到来,暂时不再写什么东西,放松几天。后边可能(仅仅是可能)会写写关于pgbench方面的,毕竟前边的文章已经涉及到,了解一下也好。这几天的帖子都没有经过仔细校正,基本上写完就commit,难免有错别字语意不通之类。
这几天各种事情缠绕(真的是缠绕)着我,脑筋有点不够用,手头的project马上进入编码阶段,后边时间也许会很紧张没时间写东西。


延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

pgpool-II使用指南-并发查询(一)(簡體)

更新:2007-
對映章節:
本文翻译自源代码包中的“pgpool-II Tutorial”文档

正如我们前边提到的,复制系统把每一个查询转发到每个数据库节点,而这些节点都保存有全部数据。而并发查询(Parallel query)则是根据预定义的规则将特定范围的数据分布到各个节点。
为了能够启用pgpool-II的并发查询功能,必须设置另外一个叫做“System Database”的数据库(我们称之为SystemDB)。SystemDB保存决定数据如何在各节点中保存的用户定义规则,另一个用途是合并使用数据库链(dblink)从数据库节点返回的结果。

设置并发查询
将pgpool.conf文件中的parallel_mode参数设置为true开启数据库复制功能:
parallel_mode = true
这样并不能自动开始并发查询,pgpool-II还需要SystemDB以及分布规则来知道如何在各节点中分布数据。

另外,SystemDB使用数据库链连接pgpool-II,因此,需要设置listen_addresses参数好让pgpool-II接受这些连接请求:
listen_addresses = '*'

注意:并发查询和复制是不能共存的,使用并发查询功能时,replication_mode必须设置为false。此外,并发查询和复制采用不同的格式储存数据,这样前边我们创建的“bench_replication”数据库无法被重用(reuse)。
replication_mode = false
load_balance_mode = false


在本节中,parallel_mode设置为true、listen_addresses设置为'*'、replication_mode和load_balance_mode设置为false。

配置SystemDB
SystemDB仅仅是另一个安装有数据库链的数据库,数据表“dist_def”被用来保存数据分布规则。可以在单独的电脑中放置SystemDB,也可以与数据库节点之一共存。

我们将在5432端口的节点上创建SystemDB,下边是SystemDB的参数设置列表:
system_db_hostname = 'localhost'
system_db_port = 5432
system_db_dbname = 'pgpool'
system_db_schema = 'pgpool_catalog'
system_db_user = 'pgpool'
system_db_password = ''


事实上,这是pgpool.conf中的缺省设置。
然后创建叫做“pgpool”的用户,再创建所有者为“pgpool”的数据库“pgpool”:
$ createuser -p 5432 pgpool
$ createdb -p 5432 -O pgpool pgpool


安装数据链
接下来,必须将数据库链安装到“pgpool”数据库,它是包含在PostgreSQL源代码contrib目录下的工具之一。

执行如下命令安装数据库链:
$ USE_PGXS=1 make -C contrib/dblink
$ USE_PGXS=1 make -C contrib/dblink install


安装完毕以后,在“pgpool”数据库中定义数据库链函数。如果PostgreSQL安装在/usr/local/pgsql,dblink.sql(函数定义文件)会被放置在/usr/local/pgsql/share/contrib中,运行如下命令创建函数:
$ psql -f /usr/local/pgsql/share/contrib/dblink.sql -p 5432 pgpool

定义dist_def数据表
再接下来,定义数据库表“dist_def”存放数据分布规则。安装pgpool-II时,system_db.sql文件放置在/usr/local/share/system_db.sql(这里我们使用缺省安装路径),它包括了一些包括“dist_def”在内的特殊用途数据表,执行下边的命令创建dist_def数据表:
$ psql -f /usr/local/share/system_db.sql -p 5432 -U pgpool pgpool

在system_db.sql文件里,dist_def被创建在叫做pgpool_catalog的schema中,如果参数system_db_schema设置为其他的schema,需要相应的修改system_db.sql。

下边是dist_def的定义语句:
CREATE TABLE pgpool_catalog.dist_def (
dbname text, -- database name
schema_name text, -- schema name
table_name text, -- table name
col_name text NOT NULL CHECK (col_name = ANY (col_list)), -- distribution key-column
col_list text[] NOT NULL, -- list of column names
type_list text[] NOT NULL, -- list of column types
dist_def_func text NOT NULL, -- distribution function name
PRIMARY KEY (dbname, schema_name, table_name)
);


dist_def中的每一行数据分为两个部分:

  • 数据分布规则(col_name、dist_def_func)
  • 数据表的meta-information(dbname、schema_name、table_name, col_list、type_list)
分布规则决定了数据如何在各节点中分布,也就是按照“col_name”字段的值分布。“dist_def_func”以“col_name”值为参数的函数,返回数据应该被储存在哪个节点的ID。

meta-information用来重写查询,并发查询必须重写查询以便能够将个节点返回的结果合并为一个结果。


延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

pgpool-II使用指南-复制(簡體)

更新:2007-04-25
對映章節:
本文翻译自源代码包中的“pgpool-II Tutorial”文档

(服务器采用上一节安装的结构,单机三DB)

配置复制系统
将pgpool.conf文件中的replication_mode参数设置为true开启数据库复制功能:
replication_mode = true

replication_mode设置为true时,pgpool-II将收到的查询请求转发到每一个数据库节点。

load_balance_mode设置为true时,pgpool-II在数据库节点之间分布SELECT查询。
load_balance_mode = true

在这里我们将这两个参数都设置为true。


验证复制系统
为了能够响应pgpool.conf的修改,必须重新启动pgpool-II。
在重新启动完成后,测试一下复制系统运行是否正常。

首先,创建一个用来复制的数据库,命名为“bench_replication”,它应该在每个节点上创建。
通过pgpool-II使用createdb命令,就会在每个节点创建数据库:
$ createdb -p 9999 bench_replication

接下来,使用带有-i选项的pgbench以预定义的数据表和数据初始化数据库:
$ pgbench -i -p 9999 bench_replication

下边的表格是pgbench -i 创建的数据表和数据的概要信息,如果数据表和数据在所有节点上被正确创建,复制系统将会正常工作。

数据表名 数据行数
branches 1
tellers 10
accounts 100000
history 0

用一个简单的shell脚本来检查每个节点,显示上述4个数据表的数据行数:
$ for port in 5432 5433 5434; do
> echo $port
> for table_name in branches tellers accounts history; do
> echo $table_name
> psql -c "SELECT count(*) FROM $table_name" -p $port bench_replication
> done
>done

关于复制的文档比较简单,就这么多。

题外话,我并不是专门作pgsql的,对它的了解也很肤浅,一边上班一边学习它而已。因为很少在实际工作中使用,所以经验很少。翻译这些东西,也是为了自己能够知道更多关于pgsqld的内容。如果有问题,可以mail给我,并请同时cc给阿益,大家共同探讨。同时我们也在寻求更多的交流渠道供大家使用,希望朋友越来越多,社群越来越大,加强交流使我们进步。

延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

pgpool-II使用指南-安装与配置(簡體)

更新:2007-04-24
對映章節:
本文翻译自源代码包中的“pgpool-II Tutorial”文档

安装pgpool-II
安装pgpool-II是件非常容易的事情,在解压缩的源代码tar包目录中运行如下命令:
$ ./configure
$ make
$ make install

configure命令收集系统信息并将它们用在编译过程中,可以传递命令行参数给configure脚本来控制它的行为,比如安装目录,缺省情况下将安装到/usr/local之下。
make命令编译源代码,make install安装编译后的可执行文件,在要安装的目录中必须具有写权限。
本指南将使用缺省安装目录/usr/local。

注意:pgpool-II需要PostgreSQL 7.4或者更高版本的libpq库(第三版本协议),如果configure脚本显示类似下边的错误信息,可能是没有安装libpq库或者它不支持第三版协议:
configure: error: libpq is not installed or libpq is old
(这里与前边讲最低支持6.4的说法冲突,看起来这个更可信。)

如果确信是支持第三版协议的libpq库,但是仍然收到这样的错误信息,可能是因为configure脚本没有正确识别它。
configure脚本在/usr/local/pgsql下搜索libpq库,如果PostgreSQL安装在其他目录,使用--with-pgsql或者是--with-pgsql-includedir和--with-pgsql-libdir命令行参数来指定它。

配置文件
pgpool-II的配置参数保存在pgpool.conf文件中,每一行采用"parameter = value"格式。安装pgpool-II时,自动创建pgpool.conf.sample文件,推荐将它拷贝并且重命名为pgpool.conf再编辑:
$ cp /usr/local/etc/pgpool.conf.sample /usr/local/etc/pgpool.conf

pgpool-II仅使用9999端口接受本地连接,如果需要接受其他主机的连接请求,将listen_addresses设置为“*”:
listen_addresses = 'localhost'
port = 9999

本指南将使用缺省参数。

配置PCP命令
pgpool-II有一个出于管理目的可以通过网络查询数据库节点信息、关闭pgpool-II等功能的接口(interface)。使用PCP命令首先必须通过用户验证,它不同于PostgreSQL的用户验证,需要在pcp.conf中定义用户名和密码。文件中的用户名/密码成对出现在每一行,用冒号隔开,密码是md5格式:
postgres:e8a48653851e28c69d0506508fb27fc5

安装pgpool-II时,自动建立pcp.conf.sample文件,推荐拷贝并且重命名以后再编辑:
$ cp /usr/local/etc/pcp.conf.sample /usr/local/etc/pcp.conf

使用pg_md5命令可以将密码加密为md5格式,它是作为pgpool-II可执行部分安装的,pg_md5使用一个文本作为参数,然后显示出这个文本的md5加密文本。
例如: 将“postgres”作为参数传递给pg_md5,pg_md5将把md5加密过文本打印到标准输出:
$ /usr/bin/pg_md5 postgres
e8a48653851e28c69d0506508fb27fc5


PCP命令通过网络执行,因此必须在pcp.conf文件中使用pcp_port设置监听端口。
本指南将使用pcp_port的缺省值:
pcp_port = 9898

设置数据库节点
现在,我们要设置pgpool-II的后端数据库,它们可以跟pgpool-II在同一台主机上,也可以在独立的机器上。如果放在同一主机之上,每个数据库服务器必须使用不同的端口。如果放在其他独立的机器上,必须设置它允许接受来自pgpool-II的连接请求。

本指南中,我们将在pgpool-II的同一个服务器上放置三个数据库,分别使用5432、5433、5434端口。在pgpool-II的配置文件pgpool.conf中作如下设置:

backend_hostname0 = 'localhost'
backend_port0 = 5432
backend_weight0 = 1
backend_hostname1 = 'localhost'
backend_port1 = 5433
backend_weight1 = 1
backend_hostname2 = 'localhost'
backend_port2 = 5434
backend_weight2 = 1

backend_hostname、backend_port、backend_weight分别设置节点的主机名、端口号、负载平衡比率,每一个参数名字符串的最后必须描述一个从0开始(1、2、3···)的节点ID。

backend_weight参数全部设置为1,意味着SELECT查询将平均分配到三个数据库中。

启动/关闭pgpool-II

启动pgpool-II,在终端之上使用如下命令:
$ pgpool
这个命令会把日志输出在终端上,因此推荐使用如下选项:
$ pgpool -n -d > /tmp/pgpool.log 2>&1 &
使用-n选项,pgpool-II作为非deamon进程运行,不会与终端脱离,这个选项需要将日志信息重定向至某个文件中。选项-d指令生成debug信息。

停止pgpool-II,使用如下命令:
$ pgpool stop
如果有客户端正在连接,pgpool-II会等待他们断开,然后才停止。如果需要强制终止,使用下边的命令:
$ pgpool -m fast stop


延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

pgpool-II不能处理的语句(簡體)

更新:2007-04-24

INSERT
不能在分区字段中使用DEFAULT,比如,如果x是数据表t的分区字段,下边的语句无效:
INSERT INTO t(x) VALUES (DEFAULT);
同样,函数也不能作为值使用:
INSERT INTO t(x) VALUES (func());
在这里必须使用常量。
另外,也不能支持SELECT INTO和INSERT INTO ... SELECT 语句。

UPDATE
如果更新分区列可能会丧失数据一致性,pgpool-II不能对更新过的数据重新分区。
如果查询因为违反约束(constraint)而引发错误,那么事务不能回滚(rollback)。
如果从WHERE子句中调用函数,更新可能无法正确执行。比如:
UPDATE branches set bid = 100 where bid = (select max(bid) from beances);

SELECT ... FOR UPDATE
如果从WHERE子句中调用函数,查询可能无法正确执行。比如:
SELECT * FROM branches where bid = (select max(bid) from beances) FOR UPDATE;

COPY
不支持COPY BINARY,也不支持从文件中copy,只能支持COPY FROM STDIN和COPY TO STDOUT。

ALTER/CREATE TABLE
更新分区规则(partition rule)以后,必须重新启动pgpool-II从系统DB中读入新设置。

Transaction
在事务块中执行的SELECT语句将被放在分离的事务块中执行,例如:
BEGIN;
INSERT INTO t(a) VALUES (1);
SELECT * FROM t ORDER BY a; <-- 上边的INSERT结果在这个SELECT语句中不可见 END;


Views / Rules
对于视图和规则,后端数据库将创建相同的定义。
SELECT * FROM a, b where a.i = b.i
像上边这样的联合(join)将在每一个后端数据库运行,然后合并它们的结果,无法建立跨越节点的视图和规则。
(看起来这里有个问题,如果存在分区,那么a和b的必须基于i而且必须一样。)

Functions / Triggers
相同的函数定义在每一个后端数据库创建,跨越节点的联合(join)和其它节点上的数据无法在函数内部操作。

Extended Query Protocol
不支持被JDBC驱动等程序使用的扩展查询协议(extended query protocol),必须使用简单查询协议(simple query protocols)。

Multi-byte Characters
pgpool-II不能进行不同字符集之间的转换,因此客户端、后端数据库和pgpool-II系统DB的字符集编码必须相同。

Deadlocks
跨越后端服务器的死锁无法被检测,例如:
(tellers数据表按照以下规则分区
-partition)
tid <= 10 --> node 0
tid >= 10 --> node 1
A) BEGIN;
B) BEGIN;
A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;


这个例子,单一节点无法检测思锁,pgpool-II会一直等待响应,这个现象发生在其他检索获得行级锁(row level lock)时。可以设置replication_timeout参数避免这个问题。
同样,如果某个节点发生死锁,每个节点的事务状态会变得不一致,所以,如果检测到死锁pgpool-II会中止处理。
pool_read_kind: kind does not match between master(84) slot[1] (69)

Schemas
public之外的schema的对象必须用全名引用:
schema.object
否则,当设置路径set search_path = xxx并且在查询中省略schema名时,pgpool-II无法解析正确的schema。

关于pgpool-II的一些特点就写完了,后边准备写一点使用指南。
建议不要使用分区功能,因为它看起来很不健壮,会带来意想不到的问题,相信大家从文档中也能看到这一点。我认为它更适合于大型查询系统而不是有频繁更新的地方,不然维护数据一致性对采用它的project来讲是一个非常繁重的工作,而且有太多限制,有些几乎是致命的,会导致某些功能根本无法实现。


延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

About pgpool-II(簡體)

更新:2007-04-23

题外话:pgpool以及pgpool-II又是日本人对pgsql的贡献,他们真的做了大量工作。

pgpool的相关网站请在延伸阅读里边查找,这篇文章是基于pgpool-II文档所写,来自源代码包,完整版本请自行下载观看,时间所限我只能简单提及部分内容。

什么是pgpool-II
pgpool-II是一个工作于PostgreSQL服务器和PostgreSQL客户端之间的中间件(middleware),具有如下特性:

pgpool-II使用PostgreSQL的前端(frontend)和后端(backend)协议进行会话,在它们之间维持一个连接。这样,数据库应用程序(前端)会认为pgpool-II是一个真实的PostgreSQL服务器,而服务器(后端)会认为pgpool-II是一个客户端。因为pgpool-II对于服务器和客户端是透明的,一个现存的数据库复制系统几乎不用作任何改动就可以同pgpool-II协同工作。

支持平台
pgpool-II可以在Linux、Solaris、FreeBSD以及大多数类UNIX架构上正常运行,目前还不能支持Windows平台。此外需要PostgreSQL 6.4或者更高版本,如果想使用并发查询,则必须使用7.4或者更高版本。

pgpool-II功能与工作模式支持矩阵
这是很重要的部分,因为涉及到pgpool-II的运行设置,我只简单放个对应矩阵,其它请自行查阅文档。此外值得注意:这里的O和X并不是能不能够支持,比如复制模式也能支持“故障恢复”。
功能/模式 raw 模式 连接池模式 复制模式 主从模式 并发查询模式
连接池 X O O O O
复制 X X O X X
负载平衡 X X O O X
Degeneration X X O O X
故障恢复 O O X X X
并发查询 X X X X O
需要服务器数目 1 or higher 1 or higher 2 or higher 2 or higher 2 or higher
是否需要系统DB? no no no no yes

制约
验证与访问控制
复制模式下的函数等对象
不能保证那些每次查询会返回不同值的数据(比如:随机数、事务ID、OID、
SERIAL、序列号、CURRENT_TIMESTAMP)能够正确地在多个后端节点中被复制。
CREATE TEMP TABLE
创建的临时表不会在会话(session)结束后删除,这是因为连接池的原因,从后端服务器看起来会话仍然在活动。为避免这一点,必需显式使用DROP TABLE删除临时表,或者在事务块中使用CREATE TEMP TABLE ... ON COMMIT DROP创建临时表。
语句
部分语句不能被
pgpool-II处理。(比较多,准备另开篇写)

Over.

写在最后,大家如果有什么好的心得或者翻译文章,请发mail给阿益或者给我,分享知识才能得到更多知识。
我的文章一般都写得很匆忙,难免有些错误和不适当的表达,如果发现请一定指出好让我校正,在blog留言即可。又或者看完以后有些什么建议也请写下来,无论是批评还是建议,都是对我的鼓励。翻译过程也是学习过程,您如果发现有什么关于pgsql比较有趣的东西,也请来信告诉我。
英文技术文档阅读对程序员来讲我认为是基本技能,而我也没有时间去翻译全部细节,所以只写一点我知道的肤浅内容,更多内容请大家自行阅读相关英文,一般我都会给出连接地址。

延伸閱讀(Link):
pgpool官方英文网站
pgpool-II官方英文网站

2007-04-06

PostgreSQL 架構模式中 Domain 用途與功能

更新:2007-04-05
對映章節:

內容:
詞彙翻譯: DOMAIN(共同值域), Schema(架構模式)

CREATE DOMAIN 允許使用者(用戶)為當前的資料庫庫在 PostgreSQL 中註冊登記一個新的使用者資料共同值域(Domain), 定義共同值域(Domain)的使用者預定也成為其物件擁有人.

如果指出一個架構模式(Schema)名稱 (例如,CREATE DOMAIN myschema.mydomain ...), 那麼該共同值域是在指定的架構模式中創建的, 否則它會在當前架構模式中創建 (在搜索路徑中最前面的那個;參閱 CURRENT_SCHEMA()). 共同值域名稱必需在其所在架構模式中的現有類型和共同值域中唯一.

共同值域可以便於我們把不同表(Tables)之間的共同(公共)值抽取到一個集中位置進行維護, 一個電子郵件地址欄位(字段)可能在多個表中使用,所有的都是同樣的屬性, 我們可以定義並使用一個共同值域,而不是分別設置每個表的約束限制.

這個例子創建了 country_code 數據類型並且在 一個表定義中使用了該類型.

CREATE DOMAIN country_code char(2) NOT NULL;
CREATE TABLE countrylist (id INT4, country country_code);

2007-03-29

PostgreSQL 8.3 版新特性概觀(一)全文搜尋引擎-FTS

更新:2007-03-28
對映章節:

內容:
PostgreSQL 8.3 版新特性概觀
面對著即將到來的次版本的升級, 總是會帶給我們更棒的效能與更多商業型 DBMS 上的優越功能, 現在我將會開始整理對 8.3 版帶來的新特點, 簡要的介紹給中文(正/簡)使用的您, 當然也更希望您把這樣優秀且無任何版權費用的 DBMS 介紹給您身邊的好友, 更多人使用就更加速它的前進!!!

(一)全文搜尋引擎(Full-Text Search, FTS)
這個功能一直都是商業型 DBMS 主張的賣點, 現在我們也將可以大聲驕傲的說 FTS 是 Free 的, 即將到來的 8.3 已不再像之前的版本附加功能(Tsearch v1, Tsearch v2)的方式導入, 而是整合到 DBMS 成為系統一部分, 也伴隨著一系列的 SQL 命令, 大至如下:

  • CREATE FULLTEXT CONFIGURATION -- 創建全文配置
    DROP FULLTEXT CONFIGURATION -- 移除全文配置
    ALTER FULLTEXT CONFIGURATION -- 變更全文配置
    CREATE FULLTEXT DICTIONARY -- 創建全文字典
    DROP FULLTEXT DICTIONARY -- 移除全文字典
    ALTER FULLTEXT DICTIONARY -- 變更全文字典
    CREATE FULLTEXT MAPPING -- 創建聯結式(bind lexeme type)類型與字典
    ALTER FULLTEXT MAPPING -- 變更 binding for lexeme type
    DROP FULLTEXT MAPPING -- 移除聯結式(bind lexeme type)類型與字典
    CREATE FULLTEXT PARSER -- 創建全文搜尋語法分析器
    DROP FULLTEXT PARSER -- 移除全文搜尋語法分析器
    ALTER FULLTEXT PARSER -- 變更全文搜尋語法分析器
    ALTER FULLTEXT ... OWNER -- 變更全文物件擁有者
    COMMENT ON FULLTEXT -- 定義或變更全文物件的註釋
當然也連帶著許多 FTS 物件化的出現, 重要的是您必須先更新您對 FTS 的了解程度, 好迎接它的到來.

延伸閱讀(Link):

PostgreSQL 推薦手動 VACUUM 的時機與目的

更新:2007-03-29
對映章節:

內容:
PostgreSQL 在 8.1 版後雖然加上了自動執行空間清理與回收機制(autovacuum).
減少 DBA 去定期手動執行 VACUUM 的過程, 但有時我們可能更想更快反映這效果, 這時就必須以手動執行的方式來達到目的.

推薦運行 VACUUM

在 pgAdmin III 提供了一個很易觀察當前是否應進行手動 VACUUM 的判斷, 在下圖右邊的黃體標示區預測值:"資料列數(已估算)"與實際值:"資料列數(已計數)", 二個值若產生嚴重偏離實際行數, 就應該在這個資料表上運行 VACUUM ANALYZE。

除了手動運行 VACUUM ANALYZE 命令(也可以利用 pgAdminIII 的「維護」選單來做)之外,還應該考慮定期有規律或者自動地運行 VACUUM ANALYZE (8.1 版後預設值是已啟用)。使用排程程序也可以做到這一點,另外 PostgreSQL 也提供了一個叫做 pg_autovacuum 的後端程序,能夠跟蹤資料庫的變化並在適當時刻自動調用 vacuum 命令。在大多數情況下,pg_autovacuum 是最好的選擇。

(點圖可放大)


pgAdmin III 工作排程代理員:


VACUUM 有什麼好處?

PostgreSQL 的查詢計劃根據預測行數做出決定,如果實際行數與預測行數有太大差異,可能會作出錯誤判斷,造成查詢計劃不是最優化的,導致執行效率過低。

PostgreSQL 資料庫需要 VACUUM 修復表中的事務交易 ID。另外,由於更新和刪除操作而產生的過時資料直到在這個表上運行 VACUUM 命令才會被清理。按下 pgAdmin III VACUUM 介面中的 [幫助/說明] 按鈕,可以從線上文檔中看到更詳細資訊。

延伸閱讀(Link):

PostgreSQL 大型物件 BYTEA vs OID

更新:2007-03-29
Source : PostgresDAC

內容: (翻譯未校稿完)
PostgreSQL 大型物件(Large Objects) BYTEA vs OID

名詞:Binary Large OBjects (BLOBs)

在 PostgreSQL 有二種方式用來存放二進制大物件(BLOBs)。首先, 是使用 bytea 類型。第二是, 將使用大物件(Large Objects)的原有能力。

BYTEA 類型

BYTEA 類型或二進制串與簡單的字符串是非常相似, 像 varchar 和 text。但是, 他們由二個特徵上的區別:

  1. 二進制串具體地准許存放八進制值零和其它"非可印的" 八進制(通常, 八進制在範圍 32 到 126 之外) 。字符串禁止零的八進制, 和並且禁止的八進制值所有其它八進制值和序列是無效達成協議對資料庫的選擇的字符集合內碼。
  2. 操作在二進制串處理實際位元組(byte), 但是處理字符串取決於地點設置。在短, 二進制串是適當的為存放程式員作為"未加工的位元組" 認為的資料, 但是字符串是適當的為存放 text。

Similitude 意味, BYTEA 價值將包括對結果資料, 可以成本效率。換句話說, PostgresDAC 當地將裝載所有資料從伺服器並且用戶然後能工作與它。

開發商必須並且記住寄發 BYTEA 值到伺服器, 八進制某些值必須逃脫。總之, 逃脫八進制, 它被轉換成它的小數八進制價值三數字的八進制數等值, 和由二條斜線在之前, 即。 ' \\xxx '。因而在最壞的文件資料的大小被送通過網路也許被增加很多。

OID 類型(大物件)

PostgreSQL 有一種大物件設置, 提供串流形式(Stream-style)存取對於使用者資料被存放在一個特別的大物件結構中。串流中的存取是有效的當工作以太大的以至於不能方便地操作整體上的資料值時。

所有大物件被安置在一張唯一系統表叫做 pg_largeobject 。PostgreSQL 並且支持存儲系統叫做 "TOAST" 那自動地存放每個表值大比唯一資料庫頁入一個間接儲藏區域。這使大物件設施部份地過時。大物件設施的一剩餘好處是, 它提供價值 2 GB 在大小, 但是 TOAST 的欄位可能是在多數 1 GB 。並且, 大物件可能任意地被修改使用比進行這樣操作高效率的使用 TOAST 的讀寫 API 。

大物件實施打破大物件"大塊(chunks)" 和存放大塊在列在資料庫。B-tree 索引保證快速的查尋正確大塊數字當做隨機存取讀和寫。

它是可能的, pg_largeobject 表將舉行一些物件資料, 但它也許不被使用任何地方在資料庫。沒有暫時修造在方法去除這 ghosts, 依照被指出在 PostgreSQL 幫助。但有想法, 這也許由 VACUUM 命令做。但是, 這種功能不被實施。

比較表

特徵
BYTEAOID
最大允許的空間 1 GB 2 GB
資料存取 整體上 Stream-style
儲存
在被定義的表裡 在 pg_largeobject 系統表裡
資料操作 使用 SQL 和脫逸的 sequnces 只在事物交易區塊之內由特別函數
載入
預先 在要求時


延伸閱讀(Link):

2007-03-25

PostgreSQL 應用程序設計的效能要訣(二)

原文作者簡介:

Josh Berkus 在 2002年加入 PostgreSQL 的核心開發成員. 現在他在 Sun Microsystems 的開放源碼資料庫團隊中擔任領導者.
擁有 11 年的資料庫經驗, 同時亦曾工作於其它專案包括: OpenOffice.org, Microsoft SQL Server, Oracle PL/SQL, and (shudder) COM+...


更新:2007-03-27
對映章節:PostgreSQL Application Performance Tips

內容:
這是一篇由 Josh Berkus 撰寫的好文章, 阿益翻譯分享給大家參考:

為 PostgreSQL 性能的應用程序設計


Tip 4: DELETE 是昂貴的

一般的應用開發者認為 DELETE 宣告實際上是沒有成本的。您是合理的認同這些嗎?
相反的。DBMSes 不是檔案系統(Filesystems); 當您刪除一筆資料列(row), 索引需要被更新並且釋放空間需要被清掃, 使得 delete 在實際上比 insert 更昂貴。
因此應用程序習慣地 delete
全部詳細資料列並且取代它們及每一次使用新的製造任何改變的儲存結果在這應用的資料庫上。這應該是被複寫及更多區分 row-replacement 行為, 看似更新唯一修改過的列。
同樣的, 當清理一張完整資料表, 時常使用 TRUNCATE TABLE 宣告總是比 DELETE FROM TABLE 來的恰當。比以往要 100 次時間期要來的快速是由於它採用批量處理(batch processes)整張資料表代替比以一列一次為單位。


Tip 5: 查詢迴圈使用 PREPARE/EXECUTE
有時儘管您企圖統合相近似的查詢式到一個大宣告式裡, 它不可能正當的歸因於您的應用程序結構。那就用 PREPARE ... EXECUTE 來做; 它允許資料庫引擎略過解析和計劃對每個查詢疊代。就範例來說:

Prepare:
query_handle = query('SELECT * FROM TABLE WHERE id = ?')(parameter_type = INTEGER)

接著開始您的迴圈:
for 1..100
query_handle.execute(i);
end

Classes for prepared statements for C++ are explained in the libpqxx documentation.

This will reduce query execution time in direct proportion to the size of the looped set.


Tip 6: 使用連結池是有效地(connection pools)
由於網路應用程序, 您將發現您潛在的性能非常大約 50% 可能被受制於您經過的用途, 及適當的組態配置, 連線中的連結池(pooling). 這是因為創建與移除中的資料庫連線消耗重要的系統時間總量, 以及過多閒置空轉的連線仍請求著記憶體和系統資源.

There are a number of tools you can use to do connection pooling on PostgreSQL. 一個第三方的開放源碼工具非常受歡迎是 pgPool. 無論如何, 由於一個 C++ 應用程序 HA 必要條件, it's probably better to use libpqxx's native pseudo-pooling technique called "lazy connections" . I suggest contacting the libpqxx mailing list for more information on how to use this utility.

With PostgreSQL, you want to have as many persistent connections (or connection objects) defined as your normal peak concurrent connection usage. So if max normal usage (first thing in the morning, say) is 200 concurrent connections from agents, users and components, then you want to have that many defined so that your application does not have to wait for new connections during a peak when they will be slow to fork.


(未翻完....)

PostgreSQL 擁有勝過所有DBMS的高度客製化特點

更新:2007-03-25
對映章節:V

內容:
PostgreSQL 是目前支持最多編程語言(Server-side Progremming)的 DBMS, 支持高達 10種以上編程語言的高度客製化 DBMS, 換句話說您可以使用您熟悉的程序語言來構建"預儲程序(Stored Procedures)置於 DBMS 中, 相對其它 DBMS 僅提供自家專屬的語言, 就失色許多.
您可以使用包括:

  1. PL/Java
  2. PL/Perl
  3. PL/PHP
  4. PL/Python
  5. PL/Ruby
  6. PL/R
  7. Tcl
  8. C/C++
  9. PL/Proxy (Skype 公司貢獻)
  10. PL/pgSQL (自帶編程語言相仿於 PL/SQL, 讓您易於在 Oracle 間替換.)
    包括有它的標準子例程程式庫範圍從基本的算術和串操作對密碼學和 Oracle 兼容性的上百內部函數。觸發器和被存放的規程可能被寫在 C 和被裝載入資料庫作為 Library , 允許偉大的靈活性在擴大它的能力。

客戶端 API(Application Programming Interfaces)
正因許多語言被 PostgreSQL 支持, 並且有著許多 Library API, 允許各種各樣的語言被編寫和被解釋對接口與PostgreSQL 。

* DBD::Pg - Perl Driver
* JDBC - JDBC Driver
* libpqxx - C++ API
* Npgsql - .Net Data Provider
* ODBC - ODBC Driver
* PgOleDb - OLE-DB Driver
* pgtclng - Next generation interface for TCL
* Pgtcl - Tcl binding library
* Pgin - A Tcl interface to PostgreSQL written in Tcl
* PyGreSQL - Python interface for PostgreSQL
* psycopg - Another Python interface for PostgreSQL

延伸閱讀(Link):

2007-03-24

PostgreSQL 是對物件名稱的英文大小寫敏感的資料庫

更新:2007-03-25
對映章節:

內容:
下面這 2 張用 pgAdmin III 製作的圖說明了,
PostgreSQL 是對物件名稱的英文大小寫敏感的資料庫,
同時創建三個同名稱, 但大小寫不同的資料庫,
對 PostgreSQL 來說是三個分別持有不同物件序號(OID)
在使用上請多留心.





延伸閱讀(Link):

PostgreSQL 應用程序設計的效能要訣(一)

原文作者簡介:

Josh Berkus 在 2002年加入 PostgreSQL 的核心開發成員. 現在他在 Sun Microsystems 的開放源碼資料庫團隊中擔任領導者.
擁有 11 年的資料庫經驗, 同時也曾經工作於其它社群專案包括: OpenOffice.org, Microsoft SQL Server, Oracle PL/SQL, and (shudder) COM+...


更新:2007-03-25
對映章節:PostgreSQL Application Performance Tips

內容:
這是一篇由 Josh Berkus 撰寫的好文章, 阿益翻譯分享給大家參考:

為 PostgreSQL 性能的應用程序設計

查詢撰寫規則
所有資料庫管理系統(DBMSes), "往返"(round-trip)時間是很寶貴的。這是因為它取得 Query 回來時必須通過語言分析器(language parser)、驅動器, 穿透網路介面, 資料庫分析器(database parser), 計劃器, 執行器, 反譯分析器, 再返回穿透網路介面, 通過驅動資料處理器, 和對 Client 應用程序的時間。
DBMSes 總是在時間上跟 CPU 爭取進程來處理這個循環週期, 並且由於各式各樣的原因每次在"往返"(round-trip) 上, PostgreSQL 是很嚴苛在意時間和系統資源。

更進一步, PostgreSQL 有著重要特點一切全是事務交易(per-transaction), 每筆事務交易處理都包括日誌記錄的產出和各種需要被設置的可見性規則在內。當您認為您可以不使用事務交易處理下的單一唯讀(singleton read-only) SELECT 的宣告, 實際上每一個宣告對 PostgreSQL 都是在進行事務交易處理。在沒有一種明確事務交易處理時, 宣告也是一種隱藏事務交易處理。

補充這, PostgreSQL 是唯一不輸給 Oracle 在處理大型複雜的查詢式(queries)上, 並且有能力輕易地處理複雜多宣告(multi-statement)式的事務交易在併發同作時的衝突處理。我們並且支持游標(cursors), 包括可捲動式(scrollable)與非捲動式(non-scrollable)。


Tip 1: 永遠不使用多數的小型查詢在當一個大型查詢能執行任務時.
它是共同在 MySQL 應用裡討論後加入的應用代碼; 那是由於手工查詢當 ID 來自父級記錄及之後迴路經由子級記錄 ID。這可能導致來自每個用戶元件螢幕連續性上百或數以萬計的查詢。每筆這種查詢往返時間大約花費 2-6 milleseconds, 看起來似乎不重大但直到您把它增加到 1000 筆次查詢, 到時您丟失 3-5 秒對往返時間。比較之下, 檢索所有那些紀錄在一次唯一查詢時只消耗少於不到 100 milleseconds, 時間節省達 80%.


Tip 2: 群組化多數的小查詢 UPDATES, INSERTS 或 DELETEs 到一個大型的宣告, 或者沒有的話, 大型事務.
首先, 在 MySQL 的早期的版本缺乏子查詢(subselects)導致應用開發者設計他們的資料修改宣告(DML)在相似情況下加入在中介軟體(middleware)中。這對 PostgreSQL 同樣是一種壞方法為。反之, 您若想要利用子查詢並且加入您的 UPDATE、INSERT 及 DELETE 宣告設法修改成批次(batches)在一個單一宣告中。這可減少往返時間與事務交易之上。

在一些案例中, 無論如何,
單一查詢不能寫入所有資料到您要的查詢並且您必須使用一串連續宣告。在這種情況下, 您想要保證包裹您的一系列 DML 宣告在一種清楚的事務交易。 (例如. BEGIN; UPDATE; UPDATE; UPDATE; COMMIT;). 這是縮減事務交易成本支出且節省執行時間高達 50%。


Tip 3: 連續性的 INSERTS 考慮用塊裝堆疊式(bulk)導入.
PostgreSQL 提供一個塊裝堆疊式的機制稱為 COPY, 採取定位分隔(tab-delimited)製表或 CSV 檔從文件或導管(pipe)來輸入。
COPY
能夠被使用在代替上百或數以萬計的 INSERTS, 它能削減執行時間達 75% 以上。


延伸閱讀:
PostgreSQL 應用程序設計的效能要訣(二)

2007-03-22

PostgreSQL 全球開發團隊:我們不進行開發的特點

更新:2007-03-22
對映章節:
http://www.postgresql.org/docs/faqs.TODO.html

內容:
以下幾點是 PostgreSQL 開發團隊聲明不進行研究的項目:

  • 全部伺服端(backends)運行線程(threads)在一個單一進程(process).

    我們得到從當前的設定這是會消滅進程(process)的保護特徵。在現代系統上, 線程建立通常也同似進程建立, 因此它似乎愚笨的使用一個純淨的線程模型。

2007-03-20

PostgreSQL 表格空間(Tablespace)功能與未來特點

更新:2007-03-21
對映章節:

內容:
表格空間, 是整個系統的資料主體
PostgreSQL 使用 pg_global 來存放和系統有關的物件
使用 pg_default 表格空間來存放使用者建立的資料庫物件

表格空間決定著DBMS整體效能的重點調校之一
在以下的情況 DBA 就有必要考量 Tablespace 的分割與配置

  • 資料間具有競爭系統效能.
  • 大型物件資料表與小型物件資料表應該分別在不同的 Tablespace.
  • 分離資料和索引的存放空間是不錯的效能強化.
PostgreSQL 開發團隊對下個版本的工作目標:

Tablespaces
  • Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
    All objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.
  • Allow reporting of which objects are in which tablespaces
    This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.
  • -Add a GUC variable to control the tablespace for temporary objects and sort files
    It could start with a random tablespace from a supplied list and cycle through the list.
  • Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original
    (類似 Oracle 的 重作日誌表格空間的功能)
  • 允許對每個表格空間配額(quotas)
  • 允許 ALTER TABLESPACE 來移動表格空間到不同的目錄(directories)
  • 允許資料庫被移動到不同的表格空間
  • 允許移動系統表(global system tables)到其它的表格空間, where possible
    Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.

PostgreSQL & Google-Analytics Running...

::Planet PostgreSQL::

PostgreSQL Information Page

PostgreSQL日記(日本 石井達夫先生Blog)

PostgreSQL News

黑喵的家 - 資料庫相關

Google 網上論壇
PostgreSQL 8 DBA 專業指南中文版
書籍內容討論與更多下載區(造訪此群組)
目錄下載: PostgreSQL_8 _DBA_Index_zh_TW.pdf (更新:2007-05-18)

全球訪客分佈圖(Google)

全球訪客分佈圖(Google)