如果打算為項目選擇一款免費、開源的數據庫,那么你可能會在MySQL與PostgreSQL之間猶豫不定。MySQL與PostgreSQL都是

專注于為中小企業提供成都網站制作、成都網站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業成華免費做網站提供優質的服務。我們立足成都,凝聚了一批互聯網行業人才,有力地推動了成百上千家企業的穩健成長,幫助中小企業通過網站建設實現規模擴充和轉變。
免費、開源、強大、且功能豐富的數據庫。你主要的問題可能是:哪一個才是最好的開源數據庫,MySQL還是PostgreSQL呢?該選擇哪一個開源數據
庫呢?
在選擇數據庫時,你所做的是個長期的決策,因為后面如果再改變決定將是非常困難且代價高昂的。你希望一開始就選擇正確。兩個流行的開源數據庫MySQL與PostgreSQL常常成為最后要選擇的產品。對這兩個開源數據庫的高層次概覽將會有助于你選擇最適合自己需要的。
MySQL
MySQL
相對來說比較年輕,首度出現在1994年。它聲稱自己是最流行的開源數據庫。MySQL就是LAMP(用于Web開發的軟件包,包括
Linux、Apache及Perl/PHP/Python)中的M。構建在LAMP棧之上的大多數應用都會使用MySQL,包括那些知名的應用,如
WordPress、Drupal、Zend及phpBB等。
一開始,MySQL的設計目標是成為一個快速的Web服務器后端,使用快速的
索引序列訪問方法(ISAM),不支持ACID。經過早期快速的發展之
后,MySQL開始支持更多的存儲引擎,并通過InnoDB引擎實現了ACID。MySQL還支持其他存儲引擎,提供了臨時表的功能(使用MEMORY存
儲引擎),通過MyISAM引擎實現了高速讀的數據庫,此外還有其他的核心存儲引擎與第三方引擎。
MySQL的文檔非常豐富,有很多質量不錯的免費參考手冊、圖書與在線文檔,還有來自于Oracle和第三方廠商的培訓與支持。
MySQL
近幾年經歷了所有權的變更和一些頗具戲劇性的事件。它最初是由MySQL
AB開發的,然后在2008年以10億美金的價格賣給了Sun公司,Sun公司又在2010年被Oracle收購。Oracle支持MySQL的多個版
本:Standard、Enterprise、Classic、Cluster、Embedded與Community。其中有一些是免費下載的,另外一
些則是收費的。其核心代碼基于GPL許可,對于那些不想使用GPL許可的開發者與廠商來說還有商業許可可供使用。
現在,基于最初的
MySQL代碼還有更多的數據庫可供選擇,因為幾個核心的MySQL開發者已經發布了MySQL分支。最初的MySQL創建者之一 Michael
"Monty"
Widenius貌似后悔將MySQL賣給了Sun公司,于是又開發了他自己的MySQL分支MariaDB,它是免費的,基于GPL許可。知名的
MySQL開發者Brian Aker所創建的分支Drizzle對其進行了大量的改寫,特別針對多CPU、云、網絡應用與高并發進行了優化。
PostgreSQL
PostgreSQL標榜自己是世界上最先進的開源數據庫。PostgreSQL的一些粉絲說它能與Oracle相媲美,而且沒有那么昂貴的價格和傲慢的客服。它擁有很長的歷史,最初是1985年在加利福尼亞大學伯克利分校開發的,作為Ingres數據庫的后繼。
PostgreSQL
是完全由社區驅動的開源項目,由全世界超過1000名貢獻者所維護。它提供了單個完整功能的版本,而不像MySQL那樣提供了
多個不同的社區版、商業版與企業版。PostgreSQL基于自由的BSD/MIT許可,組織可以使用、復制、修改和重新分發代碼,只需要提供一個版權聲
明即可。
可靠性是PostgreSQL的最高優先級。它以堅如磐石的品質和良好的工程化而聞名,支持高事務、任務關鍵型應用。
PostgreSQL的文檔非
常精良,提供了大量免費的在線手冊,還針對舊版本提供了歸檔的參考手冊。PostgreSQL的社區支持是非常棒的,還有來自于獨立廠商的商業支持。
數
據一致性與完整性也是PostgreSQL的高優先級特性。PostgreSQL是完全支持ACID特性的,它對于數據庫訪問提供了強大的安全性
保證,充分利用了企業安全工具,如Kerberos與OpenSSL等。你可以定義自己的檢查,根據自己的業務規則確保數據質量。在眾多的管理特性
中,point-in-time
recovery(PITR)是非常棒的特性,這是個靈活的高可用特性,提供了諸如針對失敗恢復創建熱備份以及快照與恢復的能力。但這并不是
PostgreSQL的全部,項目還提供了幾個方法來管理PostgreSQL以實現高可用、負載均衡與復制等,這樣你就可以使用適合自己特定需求的功能
了。
平臺
MySQL與PostgreSQL都出現在一些高流量的Web站點上:
MySQL:Slashdot、Twitter、Facebook與Wikipedia
PostgreSQL:Yahoo使用了一個修改的PostgreSQL數據庫來處理每天數以億計的事件,還有Reddit和Disqus
MySQL
與PostgreSQL都能運行在多個操作系統上,如Linux、Unix、Mac OS
X與Windows。他們都是開源、免費的,因此測試他們時的唯一代價就是你的時間與硬件。他們都很靈活且具有可伸縮性,可用在小型系統和大型分布式系統
上。MySQL在一個領域上要比PostgreSQL更進一步,那就是它的觸角延伸到了嵌入式領域,這是通過libmysqld實現的。
PostgreSQL不支持嵌入式應用,依然堅守在傳統的客戶端/服務器架構上。
MySQL通常被認為是針對網站與應用的快速數據庫后端,
能夠進行快速的讀取和大量的查詢操作,不過在復雜特性與數據完整性檢查方面不太盡如人意。
PostgreSQL是針對事務型企業應用的嚴肅、功能完善的數據庫,支持強ACID特性和很多數據完整性檢查。他們二者都在某些任務上具有很快的速
度,MySQL不同存儲引擎的行為有較大差別。MyISAM引擎是最快的,因為它只執行很少的數據完整性檢查,適合于后端讀操作較多的站點,不過對于包含
敏感數據的讀/寫數據庫來說就是個災難了,因為MyISAM表最終可能會損壞。MySQL提供了修復MySQL表的工具,不過對于敏感數據來說,支持
ACID特性的InnoDB則是個更好的選擇。
與之相反,PostgreSQL則是個只有單一存儲引擎的完全集成的數據庫。你可以通過調整postgresql.conf文件的參數來改進性能,也可以調整查詢與事務。PostgreSQL文檔對于性能調優提供了非常詳盡的介紹。
MySQL與PostgreSQL都是高可配置的,并且可以針對不同的任務進行相應的優化。他們都支持通過擴展來添加額外的功能。
一個常見的誤解就是MySQL要比PostgreSQL更容易學習。關系數據庫系統都是非常復雜的,這兩個數據庫的學習曲線其實是差不多的。
標準兼容性
PostgreSQL
旨在實現SQL兼容性(當前標準是ANSI-SQL:2008)。MySQL則兼容大部分SQL,不過還有自己的擴展,可以支
持NoSQL特性,這在參考手冊中都有介紹。每種方式都有優缺點。兼容標準會讓數據庫管理員、數據庫開發者與應用開發者更舒服一些,因為這意味著他們只需
學習一套標準、一套特性和命令即可。這會節省時間,提升效率,也不會被鎖定在特定的廠商上。
支持使用非標準的自定義功能的人們認為這樣可
以快速采用新的特性,而不必等待標準進程完成。ANSI/ISO標準在不斷演化,因此標準兼容性也是個
變化的目標:知名的關系型數據庫Microsoft SQL Server、Oracle與IBM DB2也只是部分兼容于標準。
結論
雖
然有不同的歷史、引擎與工具,不過并沒有明確的參考能夠表明這兩個數據庫哪一個能夠適用于所有情況。很多組織喜歡使用PostgreSQL,因為
它的可靠性好,在保護數據方面很擅長,而且是個社區項目,不會陷入廠商的牢籠之中。MySQL更加靈活,提供了更多選項來針對不同的任務進行裁剪。很多時
候,對于一個組織來說,對某個軟件使用的熟練程度要比特性上的原因更重要。
一、 PostgreSQL 的穩定性極強, Innodb 等引擎在崩潰、斷電之類的災難場景下抗打擊能力有了長足進步,然而很多 MySQL 用戶都遇到過Server級的數據庫丟失的場景——mysql系統庫是MyISAM的,相比之下,PG數據庫這方面要好一些。
二、任何系統都有它的性能極限,在高并發讀寫,負載逼近極限下,PG的性能指標仍可以維持雙曲線甚至對數曲線,到頂峰之后不再下降,而 MySQL 明顯出現一個波峰后下滑(5.5版本之后,在企業級版本中有個插件可以改善很多,不過需要付費)。
三、PG 多年來在 GIS 領域處于優勢地位,因為它有豐富的幾何類型,實際上不止幾何類型,PG有大量字典、數組、bitmap 等數據類型,相比之下mysql就差很多,instagram就是因為PG的空間數據庫擴展POSTGIS遠遠強于MYSQL的my spatial而采用PGSQL的。
四、PG 的“無鎖定”特性非常突出,甚至包括 vacuum 這樣的整理數據空間的操作,這個和PGSQL的MVCC實現有關系。
五、PG 的可以使用函數和條件索引,這使得PG數據庫的調優非常靈活,mysql就沒有這個功能,條件索引在web應用中很重要。
六、PG有極其強悍的 SQL 編程能力(9.x 圖靈完備,支持遞歸!),有非常豐富的統計函數和統計語法支持,比如分析函數(ORACLE的叫法,PG里叫window函數),還可以用多種語言來寫存儲過程,對于R的支持也很好。這一點上MYSQL就差的很遠,很多分析功能都不支持,騰訊內部數據存儲主要是MYSQL,但是數據分析主要是HADOOP+PGSQL。
七、PG 的有多種集群架構可以選擇,plproxy 可以支持語句級的鏡像或分片,slony 可以進行字段級的同步設置,standby 可以構建WAL文件級或流式的讀寫分離集群,同步頻率和集群策略調整方便,操作非常簡單。
八、一般關系型數據庫的字符串有限定長度8k左右,無限長 TEXT 類型的功能受限,只能作為外部大數據訪問。而 PG 的 TEXT 類型可以直接訪問,SQL語法內置正則表達式,可以索引,還可以全文檢索,或使用xml xpath。用PG的話,文檔數據庫都可以省了。
九,對于WEB應用來說,復制的特性很重要,mysql到現在也是異步復制,pgsql可以做到同步,異步,半同步復制。還有mysql的同步是基于binlog復制,類似oracle golden gate,是基于stream的復制,做到同步很困難,這種方式更加適合異地復制,pgsql的復制基于wal,可以做到同步復制。同時,pgsql還提供stream復制。
十,pgsql對于numa架構的支持比mysql強一些,比MYSQL對于讀的性能更好一些,pgsql提交可以完全異步,而mysql的內存表不夠實用(因為表鎖的原因)
最后說一下我感覺 PG 不如 MySQL 的地方。
第一,MySQL有一些實用的運維支持,如 slow-query.log ,這個pg肯定可以定制出來,但是如果可以配置使用就更好了。
第二是mysql的innodb引擎,可以充分優化利用系統所有內存,超大內存下PG對內存使用的不那么充分,
第三點,MySQL的復制可以用多級從庫,但是在9.2之前,PGSQL不能用從庫帶從庫。
第四點,從測試結果上看,mysql 5.5的性能提升很大,單機性能強于pgsql,5.6應該會強更多.
第五點,對于web應用來說,mysql 5.6 的內置MC API功能很好用,PGSQL差一些。
另外一些:
pgsql和mysql都是背后有商業公司,而且都不是一個公司。大部分開發者,都是拿工資的。
說mysql的執行速度比pgsql快很多是不對的,速度接近,而且很多時候取決于你的配置。
對于存儲過程,函數,視圖之類的功能,現在兩個數據庫都可以支持了。
另外多線程架構和多進程架構之間沒有絕對的好壞,oracle在unix上是多進程架構,在windows上是多線程架構。
很多pg應用也是24/7的應用,比如skype. 最近幾個版本VACUUM基本不影響PGSQL 運行,8.0之后的PGSQL不需要cygwin就可以在windows上運行。
至于說對于事務的支持,mysql和pgsql都沒有問題。
gp數據庫全稱是Creenplum。
GP數據庫是業界最快最高性價比的關系型分布式數據庫,它在開源的PostgreSQL的基礎上采用MPP架構(Massive Parallel Processing,海量并行處理),具有強大的大規模數據分析任務處理能力,其主要關注在數據倉庫和商業智能方面。
分布式數據庫系統通常使用較小的計算機系統,每臺計算機可單獨放在一個地方,每臺計算機中都可能有DBMS的一份完整拷貝副本,或者部分拷貝副本,并具有自己局部的數據庫,位于不同地點的許多計算機通過網絡互相連接,共同組成一個完整的、全局的邏輯上集中、物理上分布的大型數據庫。
GP數據庫特點:
1.greenplum是一個關系型數據庫集群,是由數個獨立的數據庫服務組合成的邏輯數據庫。
2.greenplum采用Shared-Nothing架構,整個集群由很多個數據節點(Segment Sever)和控制節點(master server)組成,其中每個數據節點上可以運行多個數據庫。
簡單來說,Shared-Nothing是一個分布式的架構,每個節點相對獨立。在典型的Shared-Nothing中,每一個節點上所有的資源(CPU,內存,磁盤)都是獨立的,每個節點都只有全部數據的一部分,也只能使用本節點的資源。
一、索引的類型:
PostgreSQL提供了多種索引類型:B-Tree、Hash、GiST和GIN,由于它們使用了不同的算法,因此每種索引類型都有其適合的查詢類型,缺省時,CREATE INDEX命令將創建B-Tree索引。
1. B-Tree:
CREATE TABLE test1 (
id integer,
content varchar
);
CREATE INDEX test1_id_index ON test1 (id);
B-Tree索引主要用于等于和范圍查詢,特別是當索引列包含操作符" 、=和"作為查詢條件時,PostgreSQL的查詢規劃器都會考慮使用B-Tree索引。在使用BETWEEN、IN、IS NULL和IS NOT NULL的查詢中,PostgreSQL也可以使用B-Tree索引。然而對于基于模式匹配操作符的查詢,如LIKE、ILIKE、~和 ~*,僅當模式存在一個常量,且該常量位于模式字符串的開頭時,如col LIKE 'foo%'或col ~ '^foo',索引才會生效,否則將會執行全表掃描,如:col LIKE '%bar'。
2. Hash:
CREATE INDEX name ON table USING hash (column);
散列(Hash)索引只能處理簡單的等于比較。當索引列使用等于操作符進行比較時,查詢規劃器會考慮使用散列索引。
這里需要額外說明的是,PostgreSQL散列索引的性能不比B-Tree索引強,但是散列索引的尺寸和構造時間則更差。另外,由于散列索引操作目前沒有記錄WAL日志,因此一旦發生了數據庫崩潰,我們將不得不用REINDEX重建散列索引。
3. GiST:
GiST索引不是一種單獨的索引類型,而是一種架構,可以在該架構上實現很多不同的索引策略。從而可以使GiST索引根據不同的索引策略,而使用特定的操作符類型。
4. GIN:
GIN索引是反轉索引,它可以處理包含多個鍵的值(比如數組)。與GiST類似,GIN同樣支持用戶定義的索引策略,從而可以使GIN索引根據不同的索引策略,而使用特定的操作符類型。作為示例,PostgreSQL的標準發布中包含了用于一維數組的GIN操作符類型,如:、=、等。
二、復合索引:
PostgreSQL中的索引可以定義在數據表的多個字段上,如:
CREATE TABLE test2 (
major int,
minor int,
name varchar
}
CREATE INDEX test2_mm_idx ON test2 (major, minor);
1. B-Tree類型的復合索引:
在B-Tree類型的復合索引中,該索引字段的任意子集均可用于查詢條件,不過,只有當復合索引中的第一個索引字段(最左邊)被包含其中時,才可以獲得最高效率。
2. GiST類型的復合索引:
在GiST類型的復合索引中,只有當第一個索引字段被包含在查詢條件中時,才能決定該查詢會掃描多少索引數據,而其他索引字段上的條件只是會限制索引返回的條目。假如第一個索引字段上的大多數數據都有相同的鍵值,那么此時應用GiST索引就會比較低效。
3. GIN類型的復合索引:
與B-Tree和GiST索引不同的是,GIN復合索引不會受到查詢條件中使用了哪些索引字段子集的影響,無論是哪種組合,都會得到相同的效率。
使用復合索引應該謹慎。在大多數情況下,單一字段上的索引就已經足夠了,并且還節約時間和空間。除非表的使用模式非常固定,否則超過三個字段的索引幾乎沒什么用處。
三、組合多個索引:
PostgreSQL可以在查詢時組合多個索引(包括同一索引的多次使用),來處理單個索引掃描不能實現的場合。與此同時,系統還可以在多個索引掃描之間組成AND和OR的條件。比如,一個類似WHERE x = 42 OR x = 47 OR x = 53 OR x = 99的查詢,可以被分解成四個獨立的基于x字段索引的掃描,每個掃描使用一個查詢子句,之后再將這些掃描結果OR在一起并生成最終的結果。另外一個例子是,如果我們在x和y上分別存在獨立的索引,那么一個類似WHERE x = 5 AND y = 6的查詢,就會分別基于這兩個字段的索引進行掃描,之后再將各自掃描的結果進行AND操作并生成最終的結果行。
為了組合多個索引,系統掃描每個需要的索引,然后在內存里組織一個BITMAP,它將給出索引掃描出的數據在數據表中的物理位置。然后,再根據查詢的需要,把這些位圖進行AND或者OR的操作并得出最終的BITMAP。最后,檢索數據表并返回數據行。表的數據行是按照物理順序進行訪問的,因為這是位圖的布局,這就意味著任何原來的索引的排序都將消失。如果查詢中有ORDER BY子句,那么還將會有一個額外的排序步驟。因為這個原因,以及每個額外的索引掃描都會增加額外的時間,這樣規劃器有時候就會選擇使用簡單的索引掃描,即使有多個索引可用也會如此。
四、唯一索引:
CREATE UNIQUE INDEX name ON table (column [, ...]);
五、表達式索引:
表達式索引主要用于在查詢條件中存在基于某個字段的函數或表達式的結果與其他值進行比較的情況,如:
SELECT * FROM test1 WHERE lower(col1) = 'value';
此時,如果我們僅僅是在col1字段上建立索引,那么該查詢在執行時一定不會使用該索引,而是直接進行全表掃描。如果該表的數據量較大,那么執行該查詢也將會需要很長時間。解決該問題的辦法非常簡單,在test1表上建立基于col1字段的表達式索引,如:
CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';
和上面的例子一樣,盡管我們可能會為first_name和last_name分別創建獨立索引,或者是基于這兩個字段的復合索引,在執行該查詢語句時,這些索引均不會被使用,該查詢能夠使用的索引只有我們下面創建的表達式索引。
CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
CREATE INDEX命令的語法通常要求在索引表達式周圍書寫圓括弧,就像我們在第二個例子里顯示的那樣。如果表達式只是一個函數調用,那么可以省略,就像我們在第一個例子里顯示的那樣。
從索引維護的角度來看,索引表達式要相對低效一些,因為在插入數據或者更新數據的時候,都必須為該行計算表達式的結果,并將該結果直接存儲到索引里。然而在查詢時,PostgreSQL就會把它們看做WHERE idxcol = 'constant',因此搜索的速度等效于基于簡單索引的查詢。通常而言,我們只是應該在檢索速度比插入和更新速度更重要的場景下使用表達式索引。
六、部分索引:
部分索引(partial index)是建立在一個表的子集上的索引,而該子集是由一個條件表達式定義的(叫做部分索引的謂詞)。該索引只包含表中那些滿足這個謂詞的行。
由于不是在所有的情況下都需要更新索引,因此部分索引會提高數據插入和數據更新的效率。然而又因為部分索引比普通索引要小,因此可以更好的提高確實需要索引部分的查詢效率。見以下三個示例:
1. 索引字段和謂詞條件字段一致:
CREATE INDEX access_log_client_ip_ix ON access_log(client_ip)
WHERE NOT (client_ip inet '192.168.100.0' AND client_ip inet '192.168.100.255');
下面的查詢將會用到該部分索引:
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
下面的查詢將不會用該部分索引:
一個不能使用這個索引的查詢可以是
SELECT * FROM access_log WHERE client_ip = inet '192.168.100.23';
2. 索引字段和謂詞條件字段不一致:
PostgreSQL支持帶任意謂詞的部分索引,唯一的約束是謂詞的字段也要來自于同樣的數據表。注意,如果你希望你的查詢語句能夠用到部分索引,那么就要求該查詢語句的條件部分必須和部分索引的謂詞完全匹配。 準確說,只有在PostgreSQL能夠識別出該查詢的WHERE條件在數學上涵蓋了該索引的謂詞時,這個部分索引才能被用于該查詢。
CREATE INDEX orders_unbilled_index ON orders(order_nr) WHERE billed is not true;
下面的查詢一定會用到該部分索引:
SELECT * FROM orders WHERE billed is not true AND order_nr 10000;
那么對于如下查詢呢?
SELECT * FROM orders WHERE billed is not true AND amount 5000.00;
這個查詢將不像上面那個查詢這么高效,畢竟查詢的條件語句中沒有用到索引字段,然而查詢條件"billed is not true"卻和部分索引的謂詞完全匹配,因此PostgreSQL將掃描整個索引。這樣只有在索引數據相對較少的情況下,該查詢才能更有效一些。
下面的查詢將不會用到部分索引。
SELECT * FROM orders WHERE order_nr = 3501;
3. 數據表子集的唯一性約束:
CREATE TABLE tests (
subject text,
target text,
success boolean,
...
);
CREATE UNIQUE INDEX tests_success_constraint ON tests(subject, target) WHERE success;
該部分索引將只會對success字段值為true的數據進行唯一性約束。在實際的應用中,如果成功的數據較少,而不成功的數據較多時,該實現方法將會非常高效。
七、檢查索引的使用:
見以下四條建議:
1. 總是先運行ANALYZE。
該命令將會收集表中數值分布狀況的統計。在估算一個查詢返回的行數時需要這個信息,而規劃器則需要這個行數以便給每個可能的查詢規劃賦予真實的開銷值。如果缺乏任何真實的統計信息,那么就會使用一些缺省數值,這樣肯定是不準確的。因此,如果還沒有運行ANALYZE就檢查一個索引的使用狀況,那將會是一次失敗的檢查。
2. 使用真實的數據做實驗。
用測試數據填充數據表,那么該表的索引將只會基于測試數據來評估該如何使用索引,而不是對所有的數據都如此使用。比如從100000行中選1000行,規劃器可能會考慮使用索引,那么如果從100行中選1行就很難說也會使用索引了。因為100行的數據很可能是存儲在一個磁盤頁面中,然而沒有任何查詢規劃能比通過順序訪問一個磁盤頁面更加高效了。與此同時,在模擬測試數據時也要注意,如果這些數據是非常相似的數據、完全隨機的數據,或按照排序順序插入的數據,都會令統計信息偏離實際數據應該具有的特征。
3. 如果索引沒有得到使用,那么在測試中強制它的使用也許會有些價值。有一些運行時參數可以關閉各種各樣的查詢規劃。
4. 強制使用索引用法將會導致兩種可能:一是系統選擇是正確的,使用索引實際上并不合適,二是查詢計劃的開銷計算并不能反映現實情況。這樣你就應該對使用和不使用索引的查詢進行計時,這個時候EXPLAIN ANALYZE命令就很有用了。
您高興能幫助您 1.安裝PostgreSQL 首先根據服務器架構添加PostgreSQL庫: CentOS 6.x 32bit: rpm -Uvh 1.noarch.rpm CentOS 6.x 64bit: rpm -Uvh
.安裝PostgreSQL
首先根據服務器架構添加PostgreSQL庫:
于其發行版查看鏈接并建立庫:
使用命令更新庫:
yum update
使用命令安裝PostgreSQL:
yum install postgresql93-server postgresql93-contrib
使用命令初始化PostgreSQL數據庫:
CentOS 6.x 系統:
service postgresql-9.3 initdb
CentOS 7系統:
/usr/pgsql-9.3/bin/postgresql93-setup initdb
啟PostgreSQL服務并使機自啟:
CentOS 6.x 系統:
service postgresql-9.3 start
chkconfig postgresql-9.3 on
CentOS 7系統:
systemctl enable postgresql-9.3
systemctl start postgresql-9.3
2.調整Iptables/Firewall
接調整防火墻站規則:
CentOS 6.x系統:
vi /etc/sysconfig/iptables
并添加行
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5432 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
退并保存文件重啟iptables服務:
service iptables restart
CentOS系統:
firewall-cmd --permanent –add-port=5432/tcp
firewall-cmd --permanent –add-port=80/tcp
firewall-cmd --reload
3.訪問PostgreSQL用命令提示符
默認情況數據庫名用戶名都postgres切換至用戶執行相關操作:
su – postgres
輸入命令登陸:
psql
例輸:
psql (9.3.5)
Type "help" for help.
Postgres=#
通輸入\q退postgresql返命令終端:
4.設置用戶密碼
登陸至postgres命令提示符界面
su – postgres
psql
使用命令設置密碼
postgres=# \password postgres
Enter new password:
Enter it again:
postgres=# \q
輸入命令建立PostgreSQL系統管理工具
postgres=# CREATE EXTENSION adminpack;
CREATE EXTENSION
5.創建用戶數據庫
例:用戶名:senthil 密碼:centos 數據庫名:mydb
轉postgres用戶
su – postgres
創建用戶senthil
$ createuser senthil
創建數據庫
$ createdb mydb
現登陸至psql提示符界面用戶senthil設置密碼及授權數據庫mydb訪問:
$ psql
psql (9.3.5)
Type "help" for help.
postgres=# alter user senthil with encrypted password 'centos';
ALTER ROLE
postgres=# grant all privileges on database mydb to senthil;
GRANT
postgres=#
6.刪除用戶數據庫
首先轉postgres界面
su – postgres
輸入命令
$ dropdb database-name
刪除用戶名輸入
$ dropuser user-name
7.配置PostgreSQL-MD5認證
MD5認證需要客戶端提供MD5-encrypted 密碼便身份驗證需要編輯 /var/lib/pgsql/9.3/data/pg_hba.conf文件:
vi /var/lib/pgsql/9.3/data/pg_hba.conf
添加或修改行:
[...]
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.1.0/24 md5
# IPv6 local connections:
host all all ::1/128 md5
[...]
重啟postgresql服務應用更改
CentOS 6.x系統
service postgresql-9.3 restart
CentOS 7系統
systemctl restart postgresql-9.3
8.配置PostgreSQL-Configure TCP/IP
默認情況TCP/IP連接行所其計算機用戶能連接postgresql編輯文件 /var/lib/pgsql/9.3/data/postgresql.conf允許連接:
vi /var/lib/pgsql/9.3/data/postgresql.conf
找面行:
[...]
#listen_addresses = 'localhost’
[...]
#port = 5432
[...]
兩行都取消并設置postgresql服務器IP址或設置*監聽所客戶端所示:
listen_addresses = '*'
port = 5432
重啟應用更改
CentOS6.x系統:
/etc/init.d/postgresql-9.3 restart
CentOS7系統:
systemctl restart postgresql-9.3
9.使用phpPgAdmin管理PostgreSQL
phpPgAdmin使用PHP編寫基于web管理工具用于管理PostgreSQL適用與PostgreSQL RPM庫
沒添加PostgreSQL庫添加EPEL庫
使用命令更新庫
yum update
現輸入命令安裝phpPgAdmin:
yum install phpPgAdmin httpd
注意phpPgAdmin區寫要準確使用面所示寫
編輯文件/etc/httpd/conf.d/phpPgAdmin.conf
vi /etc/httpd/conf.d/phpPgAdmin.conf
修改加粗部:
[...]
Alias /phpPgAdmin /usr/share/phpPgAdmin
Location /phpPgAdmin
IfModule mod_authz_core.c
# Apache 2.4
Require all granted
#Require host example.com
/IfModule
IfModule !mod_authz_core.c
# Apache 2.2
Order deny,allow
Allow from all
# Allow from .example.com
/IfModule
/Location
啟或重啟Apache服務
CentOS 6.x系統
service httpd start
chkconfig httpd on
CentOS 7系統
systemctl enable httpd
systemctl start httpd
現打瀏覽器并轉終于看面界面
使用前創建用戶登錄我用戶senthil密碼CentOS
能遇:Login failed
SELLinux能限制用戶連接PostgreSQL需輸入命令更改即:
setsebool -P httpd_can_network_connect_db 1
現應該能登錄
我phpPgAdimn:
OK現使用圖形化界面phpPgAdmin創建、刪除管理數據庫
您高興能幫助您 1.安裝PostgreSQL 首先根據服務器架構添加PostgreSQL庫: CentOS 6.x 32bit: rpm -Uvh 1.noarch.rpm CentOS 6.x 64bit: rpm -Uvh .安裝PostgreSQL
網頁題目:postgresql架構的簡單介紹
新聞來源:http://www.yijiale78.com/article18/dschedp.html
成都網站建設公司_創新互聯,為您提供動態網站、ChatGPT、網站營銷、商城網站、域名注冊、服務器托管
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯