在不知道如何運行某個數據庫的情況下，請不要在該數據庫上運行基準測試。本篇案例很好的解釋了原因。
EnterpriseDB贊助OnGres用MongoDB與PostgreSQL做基準測試時，在使用MongoDB過程中出現了很多基本錯誤。但如果應用幾分鐘的MongoDB最佳實踐，就會避免這種錯誤，MongoDB執行次數的數量級會更好。
OLAP基準** 後面會談到D查詢
正如MongoDB工程團隊在調查時發現的那樣，在OnGres的報告中重複了這種草率的方法。
• OnGres在MongoDB上使用了一個不受支持的實驗性驅動程序，且沒有連接池，而它使用了生產級驅動程序和PostgreSQL的第三方連接池；
• OnGres明確表示他們在廣泛調優PostgreSQL時沒有調整MongoDB；
• OnGres沒有遵循經過證明的MongoDB最佳實踐；
• OnGres使用不切實際的工作負載創建了自定義的綜合基準測試；
• OnGres創建了索引或在測試的數據庫上有不同的索引，卻沒有使用這些索引
• OnGres的自定義基準測試包含有缺陷的查詢。
當我們的團隊應用最佳實踐並糾正錯誤的索引時，發現MongoDB在相同的基準測試中運行速度比PostgreSQL快。實際上，Ongres也知道這一點：
“對於此測試，如果完全不用[Postgres]連接池，除了最優性能點外，MongoDB在所有情況下表現最佳。”——OnGres報告中的註釋
OnGres運行了三個基準測試：測試事務，OLTP和OLAP性能，但在執行每個基準測試時都出了錯，導致每個基準測試都存在致命缺陷。所以，MongoDB也強烈呼籲：進行基準測試的供應商應該只使用行業標準基準，來對他們的產品進行基準測試。並重復這些基準測試，公佈全部測試結果。只有這樣，用戶、客戶和獨立分析師才能對結果進行比較。
以下是我們在OnGres的基準測試中發現的其他錯誤：
使用不受支持的驅動程序
首先是事務測試。運行的MongoDB驅動程序具有連接池，但 OnGres卻使用了一個實驗性的、不受支持的、非生產的Lua驅動程序來為他們創建的sysbench執行事務測試。 Lua驅動程序沒有連接池，最近一次更新還是在兩年前。正常情況下，任何明智的測試人員都會尋找替代的基準，而不是在這種不公平的情景下實施測試。
然而OnGre更進一步，在PostgreSQL實例前使用了pgBouncer連接池，使他們能夠重用連接並獲得比MongoDB更高的性能。根據OnGres的說法，Sysbench是OLTP性能測試的唯一選擇，但是我們的專家在他們的基準測試庫中發現OnGres已經在各方面運行了YCSB測試和生產驅動程序，可他們沒有公佈這些結果。而 MongoDB的YCSB基準測試於2015年發佈，客戶端代碼可用。
OnGres在分析其摘要時非常依賴這些sysbench基準測試，但考慮到在沒有連接池設施的情況下使用非生產型的、實驗性的MongoDB驅動程序對比生產型的PostgreSQL驅動程序和pgbouncer連接池，沒有合理的依據可以比較這些結果。
現成品v.s完整調試品
對於所有測試，OnGres將MongoDB與現成品進行了比較，並將其與嚴格調整過的PostgreSQL進行了比較，並且他們還忽略了MongoDB最佳實踐。其實任何基準測試都應該在應用於所有測試產品的相同級別的配置下進行，並且配置級別的任何不對稱都會在測試結果中引入偏差。但OnGres竟在報告中這樣寫道：“一般來說，MongoDB不需要或從重大調優中受益”——所有軟件都可以從調整工作負載中受益，這可以通過PostgreSQL的調優參數頁面來證明。
“通常，MongoDB不需要或從重要調優中受益。”——OnGres報告中的一項聲明
當我們的專家將數據庫和查詢調整到相同的級別，對比不存在不對稱性時（像這樣的調優在我們的工作筆記中都有記錄，這是MongoDB文檔的一部分），MongoDB的執行速度比OnGres在PostgreSQL上的速度提高了240倍，查詢時間從幾小時縮短到幾秒。
自定義基準測試
基準測試應儘可能接近實際工作負載，這樣才有意義。定製合成基準測試通常可以放大一個系統中的特性，或者被寫成一個系統優於另一個系統。在OnGres的案例中，他們自己創造了兩個基準。 OLTP基準測試基於MongoDB開發人員中的倡導者編寫的Python用戶教學示例; 它是為了展示一種將關係事務代碼遷移到到MongoDB的方法而編寫的，並沒有針對性能進行優化，而是針對可讀性進行了優化。
Ongres接受了這個基準，將它導入Java，然後在此基礎上構建基準測試。這導致在MongoDB中不必要地使用了$ lookup（JOIN）聚合和其他關係特徵，由於MongoDB不是關係數據庫，這肯定會影響其性能。文檔模型的強大功能和靈活性意味著MongoDB開發人員不會將數據建模成單獨表格，也不會受到OnGres指示的性能限制。
索引是必須的
其次是OLTP基準測試。在每個受測試數據庫上創建的索引之間應該存在奇偶校驗。索引是數據庫中的驅動器性能。構建OLTP基準測試的原始代碼沒有索引，因為它沒有進行優化。相反，OnGres創建的索引放在四個表格中，只有其中一個表格的索引被編入MongoDB和PostgreSQL。
在MongoDB上，一些集合沒有索引，在PostgreSQL上，添加了一系列額外的索引來優化連接。缺乏有效的索引會導致任何數據庫要按照記錄來掃描每個表或集合記錄，從而大大降低性能。這是OnGres嚴重不對稱調優的另一個案例。
有缺陷的基準測試
最後是OLAP基準測試。OLAP基準測試僅針對JSON數據運行了四個查詢，顯然PostgreSQL比MongoDB更快。雖然這次在兩個數據庫上都創建了索引，但在MongoDB上運行的查詢卻沒有使用這些索引。
通過添加一個簡單的提示來指示查詢使用索引，MongoDB查詢比PostgreSQL快得多。 MongoDB還建議使用複合索引，但PostgreSQL文檔反對。對於MongoDB，添加一些複合索引得到一個查詢比PostgreSQL快98％。
因為當我們發現查詢D的索引在20毫秒內返回時，而不是Ongres報告的2小時23分44秒或我們報告的42分鐘時，團隊意識到有一個查詢沒有任何意義，並且在MongoDB和PostgreSQL上是不同的。事實證明，除了其他錯誤之外，在查詢D中查詢的字段在數據庫記錄中不存在。當我們為該字段添加複合索引時，MongoDB和PostgreSQL都可以立即回答“這裡沒有什麼可搜索的”。
TPC-C: 公認的基準測試
在我們為MongoDB構建事務之後，MongoDB 公司的Asya Kamsky採用了TPC-C來提供性能基準。與OnGres的方式不同，Asya展示了遵循MongoDB最佳實踐如何在更現實的事務工作負載上實現高性能。您可以觀看Asya 在MongoDB World上的演講，或者查看她在8月份將在VLDB上發表的論文，來了解更多細節。（閱讀原文可下載相關PPT）
結論
MongoDB喜歡被專家測試，這會督促我們做得更好，可以為用戶和客戶帶來回報。不幸的是，測試MongoDB的並不總是專家。有時我們會被不懂MongoDB的人測試，更糟糕的是，人們並不關心測試MongoDB的人是否瞭解MongoDB。完成被錯誤構建和錯誤運行的基準測試，耗費了我們工程師很多精力和時間，儘管如此，我們仍然要採取措施來解決這種被不熟練執行的基準測試所產生的混亂。
MongoDB中文社區(mongoing-mongoing),一個mongoers都會來的社區
進入MongoDB技術交流群請添加運營同學微信 cyqcyl ，添加請備註
關鍵字: PostgreSQL 做到 連接池
