在數據庫世界中沒有銀彈，選擇哪個數據完全取決于你自己，你要實現的目標，有多少數據需要存儲，你應用程序使用的操作系統和語言平臺，你的預算，以及是否需要數據倉庫，BI或決策支持系統等。

　　背景

　　我的許多朋友，開發人員，應用和系統架構師，有時甚至是系統管理員經常問我同類型的問題：“Bo，在我的應用中該使用SQL Server還是使用Oracle數據庫？”，“BO，我應該將我的Sybase數據庫遷移到SQL Server嗎？”，“哪個數據庫（平臺）是最好的？”，“為什么我們不使用開源數據庫，如MySQL或PostgreSQL？”。所有這些問題基本上都是相同的 —— 哪個數據庫平臺最適合某個應用程序，或是哪個數據庫平臺對IT和業務最有意義？

　　為了回答這些問題，在我推薦任何數據庫平臺之前，我會問他們更多的問題（通常是十多個），很多時候人們不理解為什么一個簡單的問題會引發這么多問題。

　　其實很多人不知道為什么他/她需要一個數據庫，什么是關系數據庫，數據庫與電子表格之間的差異（以及各自的優缺點），該用Access數據庫還是SQL Server數據庫，或應用程序能從數據庫平臺獲得什么好處。

　　雖然我不是在這里宣傳數據庫是什么，但我知道對IT和非IT人員談論數據庫完全不是一回事，我不想被稱為以數據庫為中心的呆子，不過我認為在21世紀，人們一直在談論BI（商業智能），我也認為最靈活，最復雜和最易維護的系統是由數據驅動的，產生的數據量多了就得用數據庫來保存。下面我對最流行的數據庫平臺只做簡要的介紹，并根據我的經驗和與其它IT界朋友的互動，介紹一下人們是怎么使用這些數據庫的。

　　下面我19年來使用過的數據庫：
　　• dBase/FoxBase/FoxPro in the DOS/Novell/Windows 3.x world

　　• MS SQL Server (6.5,7.0,2000,2005 and 2008)

　　• Oracle (7, 8/8i,9i,10g)

　　• Sybase SQL/ASE Servers (4.9.2, 10, 11, 11.9.2, 12/12.5, 15.x)

　　• Sybase IQ 12.6/12.7

　　• Informix/Dynamic (6, 7)

　　• MySQL (4, 5/5.1)

　　• PostGreSQL (8.3.5)/EnterpriseDB

　　此外，我參加了一系列的數據庫選型評估，如Vhayu和OneTick，我在各行業也有過內存數據庫使用經歷，如Oracle TimesTen和Sybase ASE內存版本（Sybase RAP商業版的一部分，它已成為時間序列數據庫領域的一個強力競爭者，特別是去年初和CEP集成后，影響越來越大）。

　　我曾經擔任過公司全職員工或不同公司不同項目的顧問，真的覺得在數據庫世界中確實沒有銀彈，選擇什么數據庫主要取決于以下幾方面因素：

　　• 你是誰；

　　• 你要實現的目標（業務/功能要求，性能/可靠性/可擴展性/可用性要求）；

　　• 當前數據庫存儲了多少數據；

　　• 應用程序要選擇的操作系統和語言平臺；

　　• 你的預算有多少；

　　• 你是否想/需要構建一個數據倉庫，BI或決策支持系統。

　　比較不同的數據庫系統就象比較不同的開發平臺和操作系統平臺：

　　• Java/J2EE與(C#, VB)/.NET比較；

　　• Windows與Linux/UNIX比較；

　　• Linux與私有UNIX系統如AIX/HP-UX/Solaris/Tru64/Irix比較；

　　• Unix與OpenMVS/UniSys/Tandem/IBM Mainframe比較。

　　如果我們在前端辦公應用系統，如訂單錄入，銀行或電信系統中不需要數據庫（主要是擔憂鎖/阻塞，延遲和低I/O等），我們只希望使用數據庫來存儲事實數據，或使用數據庫來備份數據。

　　當然，所有關系數據庫都提供了不同的功能，即使它們都聲稱遵循ANSI SQL和SQL-92標準，但實際上都有自己的一套SQL語言，這就好比Websphere/Weblogic/Oracle App Server/Sybase Eserver/Jboss之間的關系，它們是J2EE的不同實現，都兼容J2EE規范，但也有自己的擴展和變化。

　　關鍵任務（OLTP）和高性能系統

 　　如果我們需要數據庫在關鍵業務系統中發揮更重要的作用，并希望做到無故障時間/高可用/集群，可靠性（性能和數據量），災難復制和自動生成報告等目標，或需要實現極端高速和低延遲（HPC，高性能計算）效果，那么我們可能需要數據庫的企業級功能，但這樣的成本也更高。

　　HA（高可用）集群功能

　　各數據庫平臺的集群功能如下：

　　• Oracle RAC最適合HA集群，負載均衡和擴展；

　　• MS SQL Server提供HA故障轉移功能，但無負載均衡；

　　• Sybase ASE 15集群與Oracle RAC功能相當；

　　• TeraData本身就是一個分布式數據庫平臺；

　　• MySQL集群聲稱TPC-C性能基準測試比Oracle RAC還高；

　　• IBM DB2/UDB在運行AIX HACMP（高可用集群多處理）的IBM P系列/Power服務器和Veritas VCS/Sun等集群上運行得很好。

　　高性能/低延遲/內存數據庫

　　• Oracle提供TimesTen內存數據庫；

　　• MySQL的集群使用內存存儲引擎；

　　• Sybase提供ASE內存數據庫；

　　• 另外，我們還可以使用RAMSAN/SSD（固態硬盤）安裝SQL Server數據庫，所有與數據庫相關的磁盤I/O都發生在SSD上，而不是傳統硬盤上，因此我們可以大大減少磁盤I/O延遲，提供I/O吞吐量，并提高數據庫的整體性能；

　　• 還有其它的內存數據庫，如SQLite或eXtremeDB，但它們大多數要么只支持嵌入式系統，要么同一時間只支持單用戶或單連接。

　　可擴展性/性能

　　• 使用Oracle RAC和Sybase ASE 15集群時，如果現有硬件不能滿足性能要求，我們只需要向集群添加一臺功能更強大的服務器，然后逐步替換掉其它節點；
　　• 使用SQL Server集群時，因為它僅僅支持主動/被動模式，在實例級沒有可擴展性，如果現有硬件滿足不了需要，我們必須更換整個集群；

　　• MySQL集群也支持向所有節點都處于活動的集群添加節點，但它是一個無共享集群，節點越多意味著有更多的數據庫副本，更多的存儲和在所有節點之間復制數據時需要更多的網絡流量。

　　復制
　　• Sybase：首先澄清一下，我不是Sybase的托兒。Sybase擁有最好的復制解決方案，超過了Oracle的數據衛士和SQL Server的復制解決方案（即使用它的鏡像/日志傳送/事務復制，SQL Server的復制仍然遠遠差于Sybase的復制服務器）；

　　Sybase的異構復制和同質復制是Sybase公司上世紀90年代被華爾街排除但卻受到許多大公司使用的主要原因之一。

　　Sybase復制可以在數據庫級（主動/主動復制，比SQL Server的鏡像更好），事務級（與SQL Server的事務復制類似），表級，存儲過程級，函數級，MSA（多站點可用）以及通過日志傳送（復制世界中窮人的解決方案）實現，它的鏡像激活器結合EMC/SRDF可以真正保證在計劃內和計劃外停機時ZDL（零數據丟失）。

　　• SQL Server：SQL Server復制可以通過日志傳送和數據庫鏡像實現（主動/被動，R/W或只讀），支持對象級（表）粒度事務復制。

　　• Oracle：Oracle的數據衛士是數據庫克隆和災難恢復最佳解決方案之一（使用RMAN）。

　　• MySQL：MySQL提供無共享集群，基本上所有活動節點都是同步復制的，它的異步復制也支持事務和對象級復制。

　　• 存儲級解決方案：使用EMC的BCV，NetApp的快照管理器，日立的快照，Veritas的卷復制器，數據復制可以發生在磁盤塊級和卷級。

　　混合系統

　　通常情況下，后端數據庫存儲了大量的數據，在檢索數據（數據排序，分組，匯總和計算）時會出現性能問題，當運行速度變慢時，會影響到數據寫入過程。

　　因此，對于這些類型的應用程序，我們希望數據庫能很好地處理大量數據，也可以很好地處理讀/寫阻塞問題。

　　• Oracle
　　Oracle是這種系統的最佳選擇，因為在Oracle中，讀/寫程序不會相互阻止對方，數據在整個讀取過程/會話/事務中都是一致的，系統開銷主要發生了內存鎖和重做日志上。

　　• SQL Server
　　SQL Server 2005的新快照隔離使用了Oracle同樣的行版本化功能，但在tempdb中會產生更多的IO。

　　• Sybase ASE
　　Sybase ASE的讀/寫程序會相互阻塞對方，但Sybase IQ使用快照版本化管理解決了這個阻塞問題。

　　• 其它數據庫
　　還有其它一些數據庫也不存在阻塞問題，但其中一些甚至不遵從ACID（原子性，一致性，隔離性和持久性）標準。

　　數據倉庫

　　企業建立數據倉庫存儲/歸檔所有歷史數據，以及他們認為需要放在數據庫中的數據，通常，非規范化的數據進入數據倉庫，多維度為OLAP和商業智能（BI）解決方案提供快速檢索。

　　數據倉庫也用于新的或增強的業務戰略回溯測試，此外，數據倉庫中的數據是呈指數增長而非線性增長的。

　　基于列的關系數據庫優勢

　　基于列的關系數據庫具有很大的優勢，因為它天生就是多維的，每一列都是自我索引的（B tree）。

　　典型的基于列的數據庫有Google的Big Table，Sybase IQ，Vertica和基于MySQL構建的KickFire。

　　平均而言，這些基于列的數據庫比傳統的基于行的關系數據庫（如Oracle，SQL Server，Sybase ASE，TeraData，DB2和MySQL）在數據檢索速度上要快60到100倍，但在基于行級進行數據更新時它們的速度較慢，到目前為止，Sybase IQ似乎是這一領域的領頭羊，號稱世界上最大的數據倉庫（超過1P字節）就是用的Sybase IQ。

　　請訪問這些數據庫的網站了解更詳細的信息：
　　• http://www.kickfire.com/Solutions/Resource-Center
　　• http://www.sybase.com/products/datawarehousing/sybaseiq

　　更多有關基于列的關系數據庫信息

　　用Oracle和SQL Server作數據倉庫時都需要建立多維數據立方體，需要的存儲空間也會更多，我個人認為，用基于行的關系數據庫作的數據倉庫將會很快被基于列的數據倉庫取代。

　　總體而言，基于行的關系數據（SQL Server，Oracle，Informix，DB2/UDB，MySQL，Sybase ASE等）適合OLTP應用，而基于列的關系數據庫（Sybase IQ，KickFire，Vertica等）更適合OLAP/DSS和數據倉庫應用。

　　注意：那些時間序列數據庫如OneTick，kdb+和Vhayu都不能算是關系數據庫，它們的存儲結構是基于文件的，每一列的數據都使用一個單獨的文件存儲，基本上算是基于列的數據庫，基于列的數據庫也可用于回溯測試。此外，基于行的數據倉庫（立方體）中的數據是呈指數級增長，但基于列的數據倉庫中的數據是呈線性增長的。

　　傳統上，Oracle在數據倉庫領域處于領先的優勢，但現在在基于列的關系數據庫（如Sybase IQ，Vertica和KickFire）面前已經失去優勢，Google正在使用的Big Table也是一種基于列的數據庫/存儲系統。

　　遷移思考

　　承受能力和現有數據庫上已有的投資是另一個需要考慮的事情。

　　我見過不少從Sybase遷移到SQL Server的成功案例，反之亦然，但還很少看到從Sybase/SQL Server遷移到Oracle的，反之亦然。
　　根據數據庫的規模和應用范圍，要遷移Sybase/SQL Server存儲過程，重寫應用程序并進行測試可能需要很長一段時間，即使有Oracle遷移工作臺的幫助（現在我們可以使用SQL Developer），每個存儲過程都得重寫，如果應用程序只使用了ODBC/JDBC/ADO.NET，并且無存儲過程/臨時表，那么遷移會比較容易。

　　原生支持的編程語言
　　前面已經說過，Oracle對Java的支持是最好的，我們可以在Oracle中存儲Java代碼，并將其作為原生Oracle功能使用，這使得Oracle的擴展性非常好（有點象開放源碼），此外，Sybase也原生支持Java代碼。SQL Server和Sybase支持擴展存儲過程，基本上是指數據庫中調用外部動態庫的一個接口，它可以用不同的編程語言實現。

　　擁有成本
　　當我們在研究這些數據庫的功能時，有一點必須要記住，那就是成本和時間范圍，即使你有一個經驗豐富的數據庫團隊，如果所選數據庫平臺超過了3個也就沒有什么意義了。此外，將所有數據庫合并到一個數據庫平臺也沒有太大意義，因為大部分異構數據庫都可以通過SQL Server的鏈接服務，Oracle網關，或使用一些數據庫復制和ETL工具代替。當你在考慮數據庫的維護成本時，不要孤立數據庫成本，相反，要將其作為你的應用程序和基礎設施的一部分看待。

　　我希望這篇文章對那些將要或正在為其應用程序挑選數據庫的人們有所幫助，不會為自己做出的選擇而后悔。