雖然我是PG的鐵桿粉絲，但是關系數據庫背負了ACID的重型裝甲，在性能上居然能打敗輕裝上陣的NoSQL數據庫總覺得有點離譜。
所以我在自己的環境裏驗證了壹下EnterpriseDB的測試結果，並且小探壹下PG取勝的原因。
1. EnterpriseDB的測試結果
以下是EnterpriseDB的測試結果(數據量為5000萬)
/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality
（還可以參考這篇譯文： /78215/）
2. 我的驗證結果
測試觀點
為了使測試結果更加單純，我準備單純比拼CPU消耗(盡量排除IO和網絡的幹擾)，設定以下測試條件。
1）所有數據都要放進內存
2）C/S都跑在同壹臺單機上
所以，只在單機上進行10萬條小數據量的測試。
註）EnterpriseDB的測試環境是32G內存的Amazon Web Services M3.2XLARGE實例，總數據量超過內存了。
測試環境
測試環境為個人PC上的VMware虛擬機
PC
CPU:Intel Core i5-3470 3.2G(4核)
MEM:6GB
SSD:OCZ-VERTEX4 128GB(VMware虛擬機所在磁盤，非系統盤)
OS:Win7
VMware虛擬機
CPU:4核
MEM:1GB
OS:CentOS 6.5
PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默認值)
MG:MongoDB 3.0.2
測試步驟
測試步驟非常簡單,可以參考：
/EnterpriseDB/pg_nosql_benchmark
但是，在測試前，有些東西要改。
1)把數據量減小到10萬
pg_nosql_benchmark-master/pg_nosql_benchmark:
declare -a json_rows=(10000000)
==>
declare -a json_rows=(100000)
2)修改mongo的壹處腳本(註)
pg_nosql_benchmark-master/lib/mongo_func_lib.sh:
collectionsize="$(echo ${output}|awk -F"," '{print $5}'|cut -d":" -f2)"
==>
collectionsize="$(echo ${output}|awk -F"," '{print $6}'|cut -d":" -f2)"
註)pg_nosql_benchmark原來是基於MongoDB 2.6設計的，MongoDB 3.0的db.json_tables.stats()輸出可能變了，所以這邊要修改壹下。
/uid-20726500-id-4960138.html