postgresqlredis緩存
特性 MySQL PostgreSQL
實例 通過執行 MySQL 命令（mysqld）啟動實例。一個實例可以管理一個或多個資料庫。一台伺服器可以運行多個 mysqld 實例。一個實例管理器可以監視 mysqld 的各個實例。
通過執行 Postmaster 進程（pg_ctl）啟動實例。一個實例可以管理一個或多個資料庫，這些資料庫組成一個集群。集群是磁碟上的一個區域，這個區域在安裝時初始化並由一個目錄組成，所有數據都存儲在這個目錄中。使用 initdb 創建第一個資料庫。一台機器上可以啟動多個實例。
資料庫 資料庫是命名的對象集合，是與實例中的其他資料庫分離的實體。一個 MySQL 實例中的所有資料庫共享同一個系統編目。 資料庫是命名的對象集合，每個資料庫是與其他資料庫分離的實體。每個資料庫有自己的系統編目，但是所有資料庫共享 pg_databases。
數據緩沖區 通過 innodb_buffer_pool_size 配置參數設置數據緩沖區。這個參數是內存緩沖區的位元組數，InnoDB 使用這個緩沖區來緩存表的數據和索引。在專用的資料庫伺服器上，這個參數最高可以設置為機器物理內存量的 80%。 Shared_buffers 緩存。在默認情況下分配 64 個緩沖區。默認的塊大小是 8K。可以通過設置 postgresql.conf 文件中的 shared_buffers 參數來更新緩沖區緩存。
資料庫連接 客戶機使用 CONNECT 或 USE 語句連接資料庫，這時要指定資料庫名，還可以指定用戶 id 和密碼。使用角色管理資料庫中的用戶和用戶組。 客戶機使用 connect 語句連接資料庫，這時要指定資料庫名，還可以指定用戶 id 和密碼。使用角色管理資料庫中的用戶和用戶組。
身份驗證 MySQL 在資料庫級管理身份驗證。 基本只支持密碼認證。 PostgreSQL 支持豐富的認證方法：信任認證、口令認證、Kerberos 認證、基於 Ident 的認證、LDAP 認證、PAM 認證
加密 可以在表級指定密碼來對數據進行加密。還可以使用 AES_ENCRYPT 和 AES_DECRYPT 函數對列數據進行加密和解密。可以通過 SSL 連接實現網路加密。 可以使用 pgcrypto 庫中的函數對列進行加密/解密。可以通過 SSL 連接實現網路加密。
審計 可以對 querylog 執行 grep。 可以在表上使用 PL/pgSQL 觸發器來進行審計。
查詢解釋 使用 EXPLAIN 命令查看查詢的解釋計劃。 使用 EXPLAIN 命令查看查詢的解釋計劃。
備份、恢復和日誌 InnoDB 使用寫前（write-ahead）日誌記錄。支持在線和離線完全備份以及崩潰和事務恢復。需要第三方軟體才能支持熱備份。 在數據目錄的一個子目錄中維護寫前日誌。支持在線和離線完全備份以及崩潰、時間點和事務恢復。 可以支持熱備份。
JDBC 驅動程序 可以從 參考資料 下載 JDBC 驅動程序。 可以從 參考資料 下載 JDBC 驅動程序。
表類型 取決於存儲引擎。例如，NDB 存儲引擎支持分區表，內存引擎支持內存表。 支持臨時表、常規表以及范圍和列表類型的分區表。不支持哈希分區表。 由於PostgreSQL的表分區是通過表繼承和規則系統完成了，所以可以實現更復雜的分區方式。
索引類型 取決於存儲引擎。MyISAM：BTREE，InnoDB：BTREE。 支持 B-樹、哈希、R-樹和 Gist 索引。
約束 支持主鍵、外鍵、惟一和非空約束。對檢查約束進行解析，但是不強制實施。 支持主鍵、外鍵、惟一、非空和檢查約束。
存儲過程和用戶定義函數 支持 CREATE PROCEDURE 和 CREATE FUNCTION 語句。存儲過程可以用 SQL 和 C++ 編寫。用戶定義函數可以用 SQL、C 和 C++ 編寫。 沒有單獨的存儲過程，都是通過函數實現的。用戶定義函數可以用 PL/pgSQL（專用的過程語言）、PL/Tcl、PL/Perl、PL/python 、SQL 和 C 編寫。
觸發器 支持行前觸發器、行後觸發器和語句觸發器，觸發器語句用過程語言復合語句編寫。 支持行前觸發器、行後觸發器和語句觸發器，觸發器過程用 C 編寫。
系統配置文件 my.conf Postgresql.conf
資料庫配置 my.conf Postgresql.conf
客戶機連接文件 my.conf pg_hba.conf
XML 支持 有限的 XML 支持。 有限的 XML 支持。
數據訪問和管理伺服器 OPTIMIZE TABLE —— 回收未使用的空間並消除數據文件的碎片
myisamchk -analyze —— 更新查詢優化器所使用的統計數據（MyISAM 存儲引擎）
mysql —— 命令行工具
MySQL Administrator —— 客戶機 GUI 工具 Vacuum —— 回收未使用的空間
Analyze —— 更新查詢優化器所使用的統計數據
psql —— 命令行工具
pgAdmin —— 客戶機 GUI 工具
並發控制 支持表級和行級鎖。InnoDB 存儲引擎支持 READ_COMMITTED、READ_UNCOMMITTED、REPEATABLE_READ 和 SERIALIZABLE。使用 SET TRANSACTION ISOLATION LEVEL 語句在事務級設置隔離級別。 支持表級和行級鎖。支持的 ANSI 隔離級別是 Read Committed（默認 —— 能看到查詢啟動時資料庫的快照）和 Serialization（與 Repeatable Read 相似 —— 只能看到在事務啟動之前提交的結果）。使用 SET TRANSACTION 語句在事務級設置隔離級別。使用 SET SESSION 在會話級進行設置。
MySQL相對於PostgreSQL的劣勢：
MySQL
PostgreSQL
最重要的引擎InnoDB很早就由Oracle公司控制。目前整個MySQL資料庫都由Oracle控制。
BSD協議，沒有被大公司壟斷。
對復雜查詢的處理較弱，查詢優化器不夠成熟
很強大的查詢優化器，支持很復雜的查詢處理。
只有一種表連接類型:嵌套循環連接(nested-loop),不支持排序-合並連接(sort-merge join)與散列連接(hash join)。
都支持
性能優化工具與度量信息不足
提供了一些性能視圖，可以方便的看到發生在一個表和索引上的select、delete、update、insert統計信息，也可以看到cache命中率。網上有一個開源的pgstatspack工具。
InnoDB的表和索引都是按相同的方式存儲。也就是說表都是索引組織表。這一般要求主鍵不能太長而且插入時的主鍵最好是按順序遞增，否則對性能有很大影響。
不存在這個問題。
大部分查詢只能使用表上的單一索引;在某些情況下，會存在使用多個索引的查詢,但是查詢優化器通常會低估其成本,它們常常比表掃描還要慢。
不存在這個問題
表增加列，基本上是重建表和索引，會花很長時間。
表增加列，只是在數據字典中增加表定義，不會重建表
存儲過程與觸發器的功能有限。可用來編寫存儲過程、觸發器、計劃事件以及存儲函數的語言功能較弱
除支持pl/pgsql寫存儲過程，還支持perl、python、Tcl類型的存儲過程：pl/perl，pl/python，pl/tcl。
也支持用C語言寫存儲過程。
不支持Sequence。
支持
不支持函數索引，只能在創建基於具體列的索引。
不支持物化視圖。
支持函數索引，同時還支持部分數據索引，通過規則系統可以實現物化視圖的功能。
執行計劃並不是全局共享的, 僅僅在連接內部是共享的。
執行計劃共享
MySQL支持的SQL語法(ANSI SQL標准)的很小一部分。不支持遞歸查詢、通用表表達式（Oracle的with 語句）或者窗口函數（分析函數）。
都 支持
不支持用戶自定義類型或域(domain)
支持。
對於時間、日期、間隔等時間類型沒有秒以下級別的存儲類型
可以精確到秒以下。
身份驗證功能是完全內置的，不支持操作系統認證、PAM認證，不支持LDAP以及其它類似的外部身份驗證功能。
支持OS認證、Kerberos 認證 、Ident 的認證、LDAP 認證、PAM 認證
不支持database link。有一種叫做Federated的存儲引擎可以作為一個中轉將查詢語句傳遞到遠程伺服器的一個表上,不過,它功能很粗糙並且漏洞很多
有dblink，同時還有一個dbi-link的東西，可以連接到oracle和mysql上。
Mysql Cluster可能與你的想像有較大差異。開源的cluster軟體較少。
復制(Replication)功能是非同步的,並且有很大的局限性.例如,它是單線程的(single-threaded),因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master.
有豐富的開源cluster軟體支持。
explain看執行計劃的結果簡單。
explain返回豐富的信息。
類似於ALTER TABLE或CREATE TABLE一類的操作都是非事務性的.它們會提交未提交的事務，並且不能回滾也不能做災難恢復
DDL也是有事務的。
PostgreSQL主要優勢：
1. PostgreSQL完全免費，而且是BSD協議，如果你把PostgreSQL改一改，然後再拿去賣錢，也沒有人管你，這一點很重要，這表明了PostgreSQL資料庫不會被其它公司控制。oracle資料庫不用說了，是商業資料庫，不開放。而MySQL資料庫雖然是開源的，但現在隨著SUN被oracle公司收購，現在基本上被oracle公司控制，其實在SUN被收購之前，MySQL中最重要的InnoDB引擎也是被oracle公司控制的，而在MySQL中很多重要的數據都是放在InnoDB引擎中的，反正我們公司都是這樣的。所以如果MySQL的市場范圍與oracle資料庫的市場范圍沖突時，oracle公司必定會犧牲MySQL，這是毫無疑問的。
2. 與PostgreSQl配合的開源軟體很多，有很多分布式集群軟體，如pgpool、pgcluster、slony、plploxy等等，很容易做讀寫分離、負載均衡、數據水平拆分等方案，而這在MySQL下則比較困難。
3. PostgreSQL源代碼寫的很清晰，易讀性比MySQL強太多了，懷疑MySQL的源代碼被混淆過。所以很多公司都是基本PostgreSQL做二次開發的。
4. PostgreSQL在很多方面都比MySQL強，如復雜SQL的執行、存儲過程、觸發器、索引。同時PostgreSQL是多進程的，而MySQL是線程的，雖然並發不高時，MySQL處理速度快，但當並發高的時候，對於現在多核的單台機器上，MySQL的總體處理性能不如PostgreSQL，原因是MySQL的線程無法充分利用CPU的能力。
目前只想到這些，以後想到再添加，歡迎大家拍磚。
PostgreSQL與oracle或InnoDB的多版本實現的差別
PostgreSQL與oracle或InnoDB的多版本實現最大的區別在於最新版本和歷史版本是否分離存儲，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分離了數據,索引本身沒有分開。
PostgreSQL的主要優勢在於：
1. PostgreSQL沒有回滾段，而oracle與innodb有回滾段，oracle與Innodb都有回滾段。對於oracle與Innodb來說，回滾段是非常重要的，回滾段損壞，會導致數據丟失，甚至資料庫無法啟動的嚴重問題。另由於PostgreSQL沒有回滾段，舊數據都是記錄在原先的文件中，所以當資料庫異常crash後，恢復時，不會象oracle與Innodb資料庫那樣進行那麼復雜的恢復，因為oracle與Innodb恢復時同步需要redo和undo。所以PostgreSQL資料庫在出現異常crash後，資料庫起不來的幾率要比oracle和mysql小一些。
2. 由於舊的數據是直接記錄在數據文件中，而不是回滾段中，所以不會象oracle那樣經常報ora-01555錯誤。
3. 回滾可以很快完成，因為回滾並不刪除數據，而oracle與Innodb，回滾時很復雜，在事務回滾時必須清理該事務所進行的修改，插入的記錄要刪除，更新的記錄要更新回來(見row_undo函數)，同時回滾的過程也會再次產生大量的redo日誌。
4. WAL日誌要比oracle和Innodb簡單，對於oracle不僅需要記錄數據文件的變化，還要記錄回滾段的變化。
PostgreSQL的多版本的主要劣勢在於：
1、最新版本和歷史版本不分離存儲，導致清理老舊版本需要作更多的掃描，代價比較大，但一般的資料庫都有高峰期，如果我們合理安排VACUUM，這也不是很大的問題，而且在PostgreSQL9.0中VACUUM進一步被加強了。
2、由於索引中完全沒有版本信息，不能實現Coverage index scan，即查詢只掃描索引，直接從索引中返回所需的屬性，還需要訪問表。而oracle與Innodb則可以;
進程模式與線程模式的對比
PostgreSQL和oracle是進程模式，MySQL是線程模式。
進程模式對多CPU利用率比較高。
進程模式共享數據需要用到共享內存，而線程模式數據本身就是在進程空間內都是共享的，不同線程訪問只需要控制好線程之間的同步。
線程模式對資源消耗比較少。
所以MySQL能支持遠比oracle多的更多的連接。
對於PostgreSQL的來說，如果不使用連接池軟體，也存在這個問題，但PostgreSQL中有優秀的連接池軟體軟體，如pgbouncer和pgpool，所以通過連接池也可以支持很多的連接。
② 為什麼 MySQL 使用多線程，而 Oracle 和 PostgreSQL 使用多進程
.NET平台很棒。真的很棒。直到它不再那麼棒。我為什麼不再用.NET？簡單來說，它限制了我們選擇的能力(對我來說很重要)，轉移了我們的注意力，使得我們向內認知它的安全性，替代了幫助我們認知外面廣闊世界的所有可能性。[系好安全帶：這個文章的長度幾乎成了一本書…]優點首先讓我開始說說.NET做得對的許多事吧，盡管這其中的大多數並不來自.NET本身，但卻是由.NET社區而來。C#C#令人驚嘆。我認為它是一個令人驚嘆的編程語言。從強大的C語言背景而來，我徹底地喜歡其語法，流和這門語言的所帶來的感覺。當然有我可能改變的事，但總體來說它是一門扎實的語言。並且基於開發人員使用的編程語言如此巨額的百分比和Windows操作系統的優越性，它是一門眾所周知的語言。ReSharper我也很喜歡Resharper。在JetBrains工作的開發者們都是奇跡般的人。如果沒有ReSharper和一些相關的工具，我可能並不會如此喜歡C#。BDDandMSpec我也很喜歡簡稱為機器規格(mspec)的BDD風格的框架。它是一個令人驚嘆的測試框架，真正支持在測試中使用正確的語言測試本身。在使用mspec之前，我的測試真是一團糟並且很礙我的事。另外，當我們創建GoConvey—基於Golang的BDD測試框架的時候，Mspec對於我的組織來說是一個巨大的靈感和激勵。多語言運行時我認為多語言的CLR(公共語言運行時)的觀念真得使得JVM的世界思考著。我不知道任何非java的JVM語言在CLR之前，但隨著「公共語言運行時」的到來，我的理解是這使得使用JVM的人們向前進並且最終創造了如Scala和Clojure這樣偉大的JVM編程語言。如果我錯了請糾正我。再者，CLR使得Sun公司的人們坐下來並關注它，因為Java有一點陳舊並且隨著Java8的到來，僅僅現在才在多個方面追趕著。競爭是一件非常好的事。NuGet另一個顯著的例子是NuGet。這個包在Windows中作為一個整體特別是在Windows的開發中，它的管理軼事是糟透的。NuGet解決了很多問題，他們也通過從Python和Ruby借用了很多東西去做了很多正確的事。有改進的餘地嗎？當然。但比起其他一些選擇在這兒或那兒的包升級來說，我還沒有感到使用NuGet有這許多痛楚。Mono對於Mono的開發者們，我不能不說太棒了。他們所創造的太驚奇了。沒有任何官方支持和不顧潛在的懸在他們頭上的法律問題，他們向前推進並創造了一個居然能替代官方運行時的實現。我已經有一些運行在產品中應用程序，在Mono下運行了幾乎一年而沒有任何問題。它的產品准備好了嗎？這可能取決於你的應用程序(見下文「Mono」)。CQRS和事件溯源可以認為，關於.NET最好事之一是，它是CQRS的誕生地並有相關的技術：事件溯源。就算這樣，CQRS+ES本身並沒有什麼很新的東西。正如GregYoung將會告訴你的，這是由一堆40年歷史原料為我們重新打包並更名的。對於大型代碼庫我有些非常嚴重的問題，當我5年前使用CQRS+ES的時候，它完全釋放了我的域。CQRS+ES現在是命名模式的並且其成長是顯而易見的。這可能是因為.NET已經能夠和其他的開發平台交互共享的原因。除了這個之外，大多數的創新是從外部來的。缺點優點先放在一邊，讓我們看看什麼出錯了和我為什麼不再用.NET框架。關於我最近開發平台的遷移，最能激勵我的事是我可以利用許多最好的部分而丟下不好的部分(如下文所說)。Windows正如前文所述，當面對基於網路的伺服器軟體時，Windows並不是一個好的選手。在我看來，Windows的另一個真正的大問題是傳統的Windows開發者是通常僅僅擅長於Windows，當他們離開安樂窩之後就會很快迷失，這對於Linux開發者來說卻不是問題。計算遠不止是Windows。開發者僅僅能操作單一的操作系統的一個問題是它不可避免得導致Windows的激增。換句話說，Windows生了Windows。沒法打破這個循環。另一方面，*NIX的開發者通常熟悉多操作系統(Linux，Unix，OSX，Windows等等)，一個操作系統的內部工作原理，不同的分布(基於Debian和基於Fedora)，窗口管理器，桌面管理器，文件系統，包管理，編譯，重新編譯，重新打包，命令行「fu」等等。我的一個心病是文件系統。NTFS並不是系統唯一的文件系統，對於任何給予的任務它幾乎都不是最好的選擇。ZFS，BTRFS，ReiserFs，ext*等等，有一些很酷的特性。我也很喜歡為了各種高速/透明的磁碟操作，能從BASH創建迴路設備或者創建RAM設備。這在Windows中不會發生—如果沒有第三方軟體的話。在AWS雲服務中，啟動一個Windows機器要花掉足足10多分鍾。我大約15-20秒就能啟動一個簡單的Linux機器。當涉及到雲計算規模，它能夠迅速擴展是很重要的，因為當擴展很重要時，10-15分鍾就像是永恆的。VisualStudio在我這另一根刺，當屬VisualStudio。我需要一個大大超出預期的IDE去做任何開發，這個想法困擾著我。它只是如Windows一樣龐大的資源豬。我有一個內核i73770K3.5GHZ的台式機，以16GB的內存和最大4512GB的固態硬碟去編譯。它差不多刷爆了Windows體驗指數，但Windows+VS仍然很慢。(是的，ReSharper使得它更慢了，但是ReSharper對這來說是值得的。)現在我在MacBookPro上開發，它比起我的強大的台式機來說只有更少的CPU馬力，但運行明顯更快，在一個短小的學習曲線之後，UX（用戶體驗）變得無限美好了。事實上，我甚至不再用滑鼠了—我的雙手一直在鍵盤或觸控板上，我可以用手勢操作我的電腦並讓它回應—不像在Windows。關於VS很酷的一個事是調試器。它的查看和使用，令人難以置信得方便。每隔一段時間會在監視窗口報告錯誤的值，導致花費時間去調試。同時，這也是很大的負面，因為CLR默認的，多線程的世界使得我一開始就需要一個調試器。沒有調試器是一個解脫的體驗，因為它迫使你以另一種方式編程。VS同樣也有創建「csproj」和「sln」文件的壞毛病。我恨這些。當然，C#必須知道編譯什麼和何時編譯。我理解這點。在Golang中，引用在代碼中使用了很重要的語句。如果它不是.NET中用到的工程文件，我可能使用簡單的文本編輯器編碼C#，並且對這門語言更流暢。使用gitrebase操作時，這些文件也有導致合並沖突。別讓我開始說換行符的差異。我不能相信直到今天我們還在處理這樣的事。如果VS解決方案文件以Linux行結束符結束，通過雙擊它並不能載入該解決方案，因為VS解決方案文件分析器讀不出它來。源代碼管理幸運的是，我早就跳出了微軟陣營的源代碼管理(版本控制系統VSS)。我早在2000年初，在VSS無數次丟失了我的提交之後，就使用了Subversion(譯者註：Subversion是開源的版本控制系統)。之後git(譯者註：git是開源的版本控制系統，內容管理系統等)出現了，我又迷上了它。不幸的是，沒有Windows的介面—對我來說是典型的遭遇。最終有人創建了一個介面，我就用了那個並且沒有回頭。Git是一把非常鋒利的刀，但當你正確運用它的時候，它是一個強大而高效的工具。我曾經在一個小工程中用過TFS(譯者註：TeamFoundationServer，工作流協作引擎)，它是一個怪物—和所有來自Redmond(譯者註：美國微軟總部)的產品一樣。它感染了我的項目文件並且污染了我的源代碼目錄。真可惡。不，還是謝謝你。給了我任意一天用命令行git…或者可能是SourceTree，如果你需要從GUI得到一點關愛。Mono是的，這是第二次提及Mono。正如Mono本身如此驚艷一樣。在.NET的世界，它仍然二等公民。無論什麼時候我嘗試在Mono上運行任何重要的東西，我通常都在和漏洞作斗爭。幸運的是，對下載代碼，查找問題，發送請求和在Linux上編譯代碼我沒有感到不舒服。但是這件事我都記不清做了多少遍了。是的，CLR是個巨大的怪物，並且對一個非官方的應用在不同的操作系統都有相同的行為，簡直是個類似於分開紅海的奇跡。但事實是，我不得不花費如此多的時間來填補漏洞以使我的代碼能夠正確運行，實在是很難為其辯護。Mono的特定區域也慢。也許它不是在慢在過載，但對我來說Web伺服器是關鍵所在。並且它非常慢，最後，慢到了最底下—即使是微不足道的東西。我想好消息是它只能從這兒得到更好的。我也應該提及Mono的開發者可能忘了Linux，比起我可能知道的還多，所以我不能太挑剔。IIS也許IIS在嘗試著為太多的應用程序做太多的事情。它從作為一個web伺服器變為像J2EE應用程序容器一樣的應用程序宿主。它也站在慢速這一邊。我猜如果我需要更高的性能，我應該編寫我自己的web伺服器，但我真的很想只關注我應用程序的代碼。可能利用Windows事件伺服器將是好的，但nginx(譯者註：一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP代理伺服器)和其他伺服器只是不喜歡在Windows中生產。虛擬的以JVM為基礎的實現，例如Netty(譯者註：JBOSS提供的一個java開源框架)，很容易處理每秒650K+/的請求量。IIS在運行一個簡單的CLR應用程序「Hello,World!」，處理大約每秒50K的請求量時就會壅塞。(有趣的題外話，參考基準開發者通過TCP套接字創建了一個簡單的C#的web伺服器，它能處理大約每秒120K的請求量。)狹隘的心理前些年有個運動叫做ALT.NET。該運動是全部是關於尋找我們自身之外的更廣闊的開發社區以作為一個整體，並匯聚不同的部分。有趣的是，那是StructureMap、Autofac、NuGet、ASP.NETMVC和許多其它工具的靈感來源。在傳統的.NET的圈子裡，這個運動受到了很多的不屑和鄙視。我把這看作是，作為一個整體的社區普遍的狹隘心理和怠惰的一個極大的例證。(的確，它們中的一些可能會消失，進而以包括Redis，MongoBD還有其它的不同的技術而出現。)有這么多很棒的方案在那裡。假定微軟已註定是唯一正確之路的想法是荒謬的。如果是這樣的話，我們就都還在使用VisualStudio的設計工具去拖放按鈕和鏈接元素到一個WebForm的界面上，我們會設定了該按鈕並且依賴ViewState以幫助我們與可怕的HTTP所帶來的恐懼隔開。我從我的一個部署的代碼庫中最後一個WebForm中擺脫的那一天，是個光榮的值得慶賀的日子。誰又曾想過「網路控制」是個好主意？很顯然我考慮過因為我喝了Kool-Aid(譯者註：卡夫公司出品的飲料，這里意指明知是註定的或有危險的仍然去做,有負面涵義)並且完全接受它。它狠咬了我。見過2MB的ViewState嗎？[註：當我寫這篇文章的時候，原來的標題，「為什麼我不再用.NET」，意味著整個.NET生態系統。標題感覺有點短於是我更新為「為什麼我不再用.NET框架」。我想.NET作為一個生態系統，包括了所有的工具，工程，平台，組織還有很多開發者。這就是為什麼有些更廣泛的.NET社區的元素在我的這篇文章中受到抨擊原因。]性能殺手C，Java和C#中典型的多線程範例都強烈推薦使用鎖和互斥。對於鎖來說有個隱藏的開銷：它們慢得難以忍受。使用Disruptor(JVM中的無鎖的環形緩存[譯者註：實際上就是擁有一個序號指向下一個可用元素的數組])，你可以很容易得每秒處理20M以上的事件。在.NET中使用規定的「最佳實踐」等任何超過每秒十幾次的傳輸，都被認為是體面又好的性能表現，在這一點上來說你僅僅需要更大/更好/的硬體設備。事實上，我見過第三方客戶端庫(Rabbit，Couch，Mongo等等)中鎖語句遍布整個代碼。即使在我的代碼中沒有任何的並發，默認的和首選的方法都用了鎖。無鎖的、事件驅動的方法允許你大幅降低硬體和資金支出。大部分應用程序可以輕易地運行在兩台機器上，第二台機器僅僅在冗餘和失效備援時是必須的，以防因為硬體相關的問題導致第一台機器不可用的時候起作用。這個問題的另一個方面是調用網路和磁碟子系統的傳統方式：同步，阻塞代碼。如果你需要多個並發的HTTP請求，你需要的線程。大多數人不知道的是，為維持線程多出的1-2MB和上下文切換線程的需求，使得CPU內核消耗所有的時間顛簸在上下文切換上而不是做真正的工作。所以現在我們得到了在一個應用程序中數百或數千的線程，佔用了RAM，並造成CPU停滯不前。還有個更好的方式。Netty/NIO(JVM)，Erlang，Node，Gevent(Python)和Go都支持使用事件驅動的子系統操作(選擇/epoll[譯者註：Linux內核中的一種可擴展IO事件處理機制]/kqueue[譯者註：FreeBSD的可擴展的事件通知介面])。這就意味著當等待數據包被tx/rx跨網路的時候，CPU可以自由地去做其它，重要的工作。因為JVM的成熟，Netty可以認為是做這項工作最快的，但我喜歡Go用Goroutines操作這個的方式—它簡單，優雅，很容易推理，沒有像義大利面條一樣的回調。SQLServer作為一名.NET開發者，當你開始一個新的工程時，有一些事是你通常會去做的：創建一個新的solution將其部署到TeamFoundationServer(譯者註：Microsoft應用程序生命周期管理(ALM)解決方案的核心協作平台)IIS中建立相應的網站入口創建一個新的SQLServer資料庫在solution中關聯EntityFramework(通常是2010年之後創建的工程)開始設計你的資料庫和ActiveRecord實體在大多數情況下這不是編寫代碼的正確方式。當然它可能在某些情況下有效，但是作為一個「默認的架構」它並不是你想要的。為什麼在我們甚至還沒理解問題領域之前已經做了任何技術上的選擇？這簡直是本末倒置了。微軟的生態系統鼓勵每個人使用SQLServer。在VisualStudio中和SQLService進行交互或者使用SQLManagementStudio(和它的前身，SQL查詢分析器)是如此令人難以置信的容易。這種以資料庫為中心的重點，是欽定的或唯一正確的方式的一部分。它使你更加迷戀微軟。廠商鎖定始終對廠商來說是好的。為什麼我們要如此開發？為什麼我們不地考慮應用程序的行為而不是它如何存儲的？現在我所有的項目都使用基於JSON的鍵/值存儲。有了這種功能，我可以選擇任何我想要的存儲引擎，包括SQLServer，Oracle，PostgreSQL，MySQL，Cassandra,CouchDB,CouchBase,Dynamo,SimpleDB,S3,Riak,BerkeleyDB,Firebird,Hypertable,RavenDB,Redis,TokyoCabinet/Tyrant,AzureBlobs，文件系統中的明文JSON文件等等等等。突然之間，我們能夠開始根據其優點而不是僅僅對其熟悉來選擇存儲引擎了。題外話：在AWSRDS的雲上運行過SQLServer嗎？別這么做。當然它會工作，但是一些例如復制這樣最簡單的事是不存在的。文章充斥著對SQLServer不能在AWSRDS上工作的引用。結論也許我在軟體開發中學到的兩件最重要的教訓是：邊界和封裝的重要性(以多種形式)付出代價以得到正確的模型和抽象許多年前我恨「模型」這個詞。每個人都會把它到處扔，它是一個如此過載的術語，很難理解它的含義和它為什麼這么重要。就這點來說，我僅僅會說模型是對你想要封裝的現實的一個有限的表示。也許最簡單的例子就是地球儀的墨卡托投影了。這很確切得說明了一件事：導航。如果你在其他的事情上使用它，它並不毫無價值。如果你不專注於付出代價去使模型正確，去封裝商業現實，那麼沒有任何技術能夠拯救你。我對.NET最大的抱怨是，「唯一正確的方式」引導你遠離理想的模型並把你推向關注實現細節和技術缺陷的方向。這樣的關注導致技術實施滲血並且感染模型，最終導致它腐爛變質，因為它不能適應不斷變化的商業需求。當這發生的時候，開發者掙扎著並蹬踢著，如同吸毒者一樣，他們從一個新技術轉向另一個，以期望下一個強大的技術能夠治癒他們的病痛。技術本身並不是靈丹妙葯，相反地，它是關於取捨和選擇。只有正確地理解了商業行為並把它們封裝進結構良好的，易於理解的模型中，以幫助保持技術堆棧在屬於它的地方—作為一個實現細節。這就是我為什麼不再用.NET框架，因為它不斷地重申自己(的主張)，不斷地想要比它的本身的：一個實現細節。
③ 如何擴大postgresql存儲空間
1. 概述
cstore_fdw實現了 PostgreSQL 資料庫的列式存儲。列存儲非常適合用於數據分析的場景，數據分析的場景下數據是批量載入的。
這個擴展使用了Optimized Row Columnar (ORC)數據存儲格式，ORC改進了Facebook的RCFile格式，帶來如下好處:
壓縮:將內存和磁碟中數據大小削減到2到4倍。可以擴展以支持不同壓縮演算法。
列投影:只提取和查詢相關的列數據。提升IO敏感查詢的性能。
跳過索引:為行組存儲最大最小統計值，並利用它們跳過無關的行。
2. 使用
cstore_fdw的安裝和使用都非常簡單，可以參考官方資料。
thub.com/citusdata/cstore_fdw
注)注意cstore_fdw只支持PostgreSQL9.3和9.4 。
下面做幾個簡單的性能對比，看看cstore_fdw究竟能帶來多大的性能提升。
2.1 數據載入
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 " 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千萬條記錄，數據佔用存儲大小1.16G，插入耗時6分42秒，分析耗時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, www.hnne.com id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c " 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千萬條記錄，數據佔用存儲大小390M，插入耗時7分35秒，分析耗時6秒。
使用cstore列存儲後，數據佔用存儲大小降到普通表的3分之1。需要說明的是，由於所有TEXT列填充了隨機數據，壓縮率不算高，某些實際的應用場景下壓縮效果會比這更好。
2.2 Text列的like查詢性能對比
2.2.1 普通表
清除文件系統緩存，並重啟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列執行like查詢
[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
耗時7.1秒，產生IO讀1.14G,IO寫108K。
不清文件系統緩存，不重啟PostgreSQL，再執行一次。消耗時間降到1.6秒，幾乎不產生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表
清除文件系統緩存，並重啟PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 > /proc/sys/vm/drop_caches
對Text列執行like查詢
[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
耗時2.8秒，產生IO讀59M,IO寫0K。執行時間優化的雖然不是太多，但IO大大減少，可見列投影起到了作用。
不清文件系統緩存，不重啟PostgreSQL，再執行一次。消耗時間降到1.4秒，幾乎不產生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列執行=查詢
2.3.1 普通表
清除文件系統緩存，並重啟PostgreSQL後
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 > /proc/sys/vm/drop_caches
對Int列執行=查詢
[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
耗時6.8秒，產生IO讀1.14G,IO寫84K
不清緩存，再執行一次。消耗時間降到1.1秒，幾乎不產生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、OracleDatabase
知名的Oracle資料庫，一直處於行業領先地位，是許多人認可的、世界上最流行的關系資料庫管理系統。
作為「十大資料庫管理系統排名榜」之首，Oracle資料庫使用方便、功能強大，可擴展性強、數據安全性強，系統可移植性好、穩定性佳，適用於各類大、中、小微機環境。2019年，艾媒金榜發布「企業服務品牌之HRM系統排行榜」，Oracle資料庫位列第一。
2、Navicat
Navicat是一套可創建多個連接的資料庫管理工具，可以方便管理Oracle、MySQL、PostgreSQL等多個不同類型的資料庫，並支持管理騰訊雲、阿里雲等雲資料庫。
整體而言，Navicat的功能可以滿足專業開發人員的需求，同時對資料庫伺服器初學者來說又相對容易。曾有一項數據統計，《財富》世界500強中有超過100家公司使用了Navicat。
3、DBeaver
DBeaver是一個通用的資料庫管理工具和SQL客戶端，具有相對較高的易用性，並且免費、支持跨平台使用、允許擴展插件。
支持的操作系統包括Windows、Linux、MacOS、Solaris、AIX、HPUX；基本特性編輯：支持資料庫元數據瀏覽，支持元數據編輯（包括表/列/鍵/索引），支持SQL語句和腳本的執行，支持SQL關鍵字高亮顯示，簡單友好的顯示頁面。
4、Mysql
MySQL是最流行的關系型資料庫管理系統之一，在WEB應用方面，MySQL也是最好的RDBMS應用軟體之一。
作為十大資料庫管理系統之一，MySQL所使用的SQL語言是用於訪問資料庫的最常用標准化語言；其軟體採用雙授權政策，分社區版、商業版，由於其速度快、體積小、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇MySQL作為網站資料庫。
5、phpMyAdmin
phpMyAdmin是一個以PHP為基礎，以Web-Base方式架構在網站主機上的MySQL的資料庫管理系統軟體，管理者可用Web介面管理MySQL資料庫。
功能特性包括但不限於：支持大多數MySQL功能；從CSV和SQL導入數據，將數據導出為各種格式；以各種格式創建資料庫布局的圖形；使用逐例查詢（QBE）創建復雜查詢；使用一組預定義的函數將存儲的數據轉換為任何格式。
6、IBMDB2
DB2是IBM公司開發的關系型資料庫系統，主要應用於大型應用系統，具有較好的可伸縮性，支持從大型機到單用戶環境。
DB2提供了高層次的數據利用性、完整性、安全性、可恢復性，以及小規模到大規模應用程序的執行能力，具有與平台無關的基本功能和SQL命令。DB2可以在Windows、UNIX和Linux操作系統上運行，是最強大的十大資料庫管理系統之一。
7、MSSQLServer
SQL Server是微軟推出的關系型資料庫管理系統，具有使用方便、可伸縮性佳、與相關軟體集成程度高等優點，可跨平台使用。SQL Serve最初是由微軟、Sybase 和Ashton-Tate三家公司共同開發的，於1988年推出了第一個OS/2版本。
在Windows NT推出後，Microsoft與Sybase在SQL Server的開發上就分道揚鑣了，Microsoft將SQL Server移植到Windows NT系統上，專注於開發推廣SQL Server的Windows NT版本。Sybase則較專注於SQL Server在Unix系統上的應用。
8、ApacheCassandra
資料庫管理軟體哪個好？ApacheCassandra是一款優秀的分布式資料庫軟體。
該DBMS軟體突出特點：一，模式靈活，使用時就像文檔存儲，用戶不必提前解決記錄中的欄位，可以在系統運行時隨意的添加或移除欄位，最終提升效率。
二，具有純粹意義上的水平擴展。為給集群添加更多容量，可以指向另一台計算機，用戶不必重啟任何進程，改變應用查詢，或手動遷移任何數據。三，多數據中心識別。
9、Redis
Redis是C語言開發的一個開源高性能鍵值對的內存資料庫，可以用來做資料庫、緩存、消息中間件等場景，是一種NoSQL的資料庫。
其主要特點：性能優秀，數據是存儲在內存中，讀寫速度非常快，可支持並發10WQPS；可作為分布式鎖；支持五種數據類型；支持數據持久化到磁碟；可以作為消息中間件使用等。數據緩存是Redis極其重要的一個場景。
10、Sybase
十大資料庫管理系統排名榜中的Sybase，是一種典型的UNIX或WindowsNT平台上客戶機/伺服器環境下的大型資料庫系統。系統具有完備的觸發器、存儲過程、規則以及完整性定義，支持優化查詢，具有較好的數據安全性。
Sybase還提供了一套應用程序編程介面和庫，可以與非Sybase數據源及伺服器集成，允許在多個資料庫之間復制數據，適於創建多層應用。