SQL與NoSQL區別--商業SQL數據庫衰落--oracle面臨困境

轉自：商用數據庫之死：Oracle 面臨困境

這二十年來，商業數據庫市場仍然是 IT 行業最穩定、最具黏性的領域之一，Oracle、IBM 和微軟三家廠商瓜分了 80% 的份額。然而，咱們認爲這個領域衰退的速度和幅度可能會讓許多投資者大吃一驚。

已經影響數據庫市場的通貨緊縮壓力剛剛開始體現，包括：

• 遷移到軟件即服務（SaaS），大多數產品使用免費開源數據庫；
• 社交媒體、物聯網和非結構化/半結構化數據等使用場合迎來更快速的增加，這些使用場合不適合 SQL 標準，而數據庫寡頭們偏偏有賴於這項標準；
• 衆多的免費開放源代碼選項日益穩定、功能日益強大，其中大多數選項是「Not Only SQL」（NoSQL），所以極其適合上述使用場合；以及
• 因爲摩爾定律帶來了處理器、內存、固態存儲和網絡吞吐量等方面的改進，NoSQL 數據庫繼續得到異常顯著的好處――這些改進提高了同時快速處理 NoSQL 使用場合和 SQL 使用場合的能力，並逐漸使純 SQL 數據庫淪爲邊緣化，正如純 SQL 數據庫在 80 年代末和 90 年代使基於大型機的數據庫淪爲邊緣化。）

微軟和 IBM 將只是略微受到傷害，由於數據庫軟件只佔每家廠商總收入的區區5% 左右。

　　若是不採起積極的行動來大幅提升非數據庫收入，咱們認爲 Oracle 沒法足夠快地抵消商業數據庫收入即將降低的頹勢，以保持其目前的市值。

　　具體來講，咱們認爲 Oracle 須要實行更激進、更快速的組織轉型和文化轉型，變成一家「雲優先」的企業，激勵銷售隊伍和客戶向雲積極邁進。該公司還須要整合各類自家開發和收購而來的雲/ SaaS 產品，整合到單個平臺，以便未來得到經營槓桿效應。將來幾年，這些項目會在幾個方面帶來痛苦，尤爲是財務方面。爲了部分抵消痛苦，Oracle 應該剝離剩餘的硬件及其餘非核心業務。

　　主題說明　　

　　對於那些對技術深究更有興趣的人來講，下面從歷史的角度更深刻地解釋了五個相互關聯的趨勢，這些趨勢愈演愈烈，將共同致使商業數據庫市場到 2021 年收縮 20% 至 30%。

　　企業繼續遷移到 SaaS/雲

　　除了幾款創建在 Oracle 數據庫基礎上的初期 SaaS 產品（即 Salesforce.com、NetSuite 和 Oracle 自己）外，很難找到使用任何商業數據庫的 SaaS 提供商。對於 2005 年之後創辦的公司而言，這個數字幾乎爲零。

　　現在絕大多數的 SaaS 提供商使用開源數據庫，或者像 SaaS 人力資本管理（HCM）提供商 Workday 那樣，開發本身的數據庫。許多用戶以前使用內部部署型企業應用軟件，包括五個核心客戶端/服務器應用軟件類別中的一個：ERP（企業資源規劃）、CRM（客戶關係管理）、HCM（人力資本管理）、SCM（供應鏈管理）和 BI（商業智能）應用軟件，改用 SaaS 模式後，消除了商業數據庫席位（seat），於是消除了本來帶來的維護/支持收入和將來升級收入。連改用 Salesforce.com 的企業席位給 Oracle 創造的收入也將比當初部署在企業內部環境時少得多。

　　所以，咱們認爲企業遷移到 SaaS/雲對商業數據庫收入而言是很是不利的趨勢。此外，咱們仍處在從客戶端/服務器到 SaaS/雲的早期階段。據不一樣的研究公司聲稱，這種遷移只完成了 10% 至 25%，只是剛剛開始影響更重要的關鍵任務應用軟件（好比 ERP），它們更有可能在更高端的 SQL 數據庫（包括 Oracle 和 IBM 的那些數據庫以及微軟的一小部分數據庫）上運行。　

　　商業 SQL 數據庫不是很適合處理最有吸引力的新興使用場景

　　SQL 在 1987 年成爲標準後，20 年來它在定義如何組織、搜索和排序數據方面的地位無可撼動。然而，到 2000 年年中，各大科技公司在處理數據的絕對數量和不一樣結構方面開始遇到了 SQL 數據庫存在的限制，它們想按照須要來保留、瀏覽、分析數據，並將數據提供給用戶/客戶。

　　亞馬遜、谷歌、LinkedIn 和 Facebook 各自經過開發和實施本身的數據庫軟件――這種數據庫軟件打破了 SQL 標準的制約，解決了本身的擴展問題。

　　此外，不久後每家公司都發布了開源版本的數據庫。所以，2008 年和 2009 年它們開發出了衆多新的開源數據庫，致使了《下一代數據庫》的做者蓋伊·哈里遜（Guy Harrison）所說的「某種寒武紀大爆炸」現象。因爲紛紛遠離 SQL，這些數據庫都屬於「NoSQL」這類數據庫――儘管大多數數據庫彼此大不相同，就像它們跟 SQL 大不相同那樣。

　　鑑於數據的數量和種類迅猛增加――這歸因於更豐富的社交媒體內容、更多的社交媒體用戶以及自動獲取的物聯網數據激劇增多，另外鑑於企業日益渴望分析獲取的數據，咱們認爲，適合 NoSQL 的使用場合其數量很快就會遠遠超過適合 SQL 的使用場合。

　　這些新型使用場合的興起將推進大企業更多地採用開源 NoSQL 解決方案，結果商業 SQL 數據庫成了犧牲品。

　　NoSQL 數據庫和讀時模式（Schema-on-Read）方法遵循摩爾定律

　　SQL 數據庫和寫時模式（Schema-on-Write）未遵循摩爾定律。一般來講，NoSQL 數據庫所需的處理器、內存和存儲資源比 SQL 數據庫密集得多，即便考慮到這一事實：它們放鬆了 SQL 在數據組織方式方面的許多約束。雖然 NoSQL 數據庫架構早在 2005 年就已經存在――至少從理論上來講是這樣，但當時根本沒有足夠的處理能力、內存容量和存儲空間，好讓它們在學術界以外的領域投入實際應用。

　　在處理器/內存/帶寬資源相對匱乏的 20 世紀 80 年代和 90 年代，遵照更加嚴格的 SQL 標準其實是必須的，那樣才能確保企業將應用軟件從大型機和小型計算機遷移到更加分佈式、依賴網絡的客戶端/服務器架構所須要的那種性能和可靠性，尤爲是那些更重要的關鍵任務應用軟件。

　　得到 SQL 尚可接受的性能和可靠性須要付出代價，這主要是因爲：

• 名爲模式的數據結構總體上缺少靈活性；
• 在部署數據庫及相關應用程序以前定義該結構帶來的繁重要求；
• 隨着時間的推移，很難改變該結構，以便獲取不一樣類型的數據，以便更好地體現數據結構和企業組織方面的變化；以及
• 須要寫時模式方法，即在輸入數據時讓數據適合模式，而不是讀時模式，只是將數據倒到一隻大大的「容器」中，以後將它組織到模式中。

　　然而，隨着時間的推移，摩爾定律促使處理能力、內存容量及速度、存儲容量及速度以及網絡吞吐量都獲得了提高，這使得用戶愈來愈不須要僵硬的 SQL 標準和寫時模式方法，這股勢頭只會延續下去。所以，伴隨着每一個摩爾定律週期，SQL 及其節省資源的寫時模式方法愈來愈失去競爭優點，而 NoSQL 及其資源相對低效，但極其靈活的讀時模式方法變得日益擺脫當初阻礙它獲得採用的約束。

　　內存技術（In-Memory）帶來了大好前景，消除了傳統硬盤的缺點

　　SQL 成爲標準化時，傳統硬盤（HDD）是能夠實時訪問的惟一具備成本效益的存儲介質。所以，寫入到 SQL 數據庫軟件的許多基本代碼旨在忍受 HDD 的缺點，好比讀取請求的數據並將數據傳輸到內存中速度很慢，故障率比較高――至少，與系統的主要固態部件（好比 CPU、內存和網絡吞吐量）相比是這樣。如今因爲固態硬盤（SSD）正迅速成爲一種具備成本效益的 HDD 替代品，傳統 SQL 數據庫軟件的設計、固然還有大部分代碼如今毫無必要了――而當初作出這樣的妥協，是爲了適應速度慢得多的 HDD。

　　相比之下，開發的許多 NoSQL 數據庫是爲了最大限度地利用 SSD 存儲介質，這些數據庫可能會獲得更新，以便充分利用更新穎的非易失性內存技術，好比英特爾/美光聯合開發的 3D xPoint，這種內存正在推向市場。咱們認爲，鑑於繼續遵照 SQL 標準、保持本身的向後兼容性方面有着強烈的需求，SQL 數據庫廠商沒法像許多開源項目那樣迅速針對 SSD 優化其代碼，這讓它們進一步處於競爭劣勢――這是克萊頓·克里斯滕森（Clayton Christensen）所說的「創新者的困境」的一個典型例子。

　　市面上 「SQLMethadone」 解決方案愈來愈多，讓企業能夠擺脫昂貴的商業數據庫

　　咱們看到愈來愈多的軟件工具和服務旨在幫助企業從商業 SQL 數據庫遷移出去。隨着時間的推移，連在 Oracle 或 IBM 數據庫上運行的最重要的關鍵任務應用軟件也可能日益被包圍、「被隔離」、被拆卸，這一幕正如上世紀 90 年代向客戶端/服務器架構轉型期間許多傳統大型機應用軟件的遭遇那樣。

　　雖然來自 Oracle、IBM 和微軟等巨頭的 SQL 數據庫會在一些企業存活好多年――再度酷似大型機，可是它們會日益淪爲邊緣化，而且它們的成本會盡量被減小。咱們看到許多這樣的工具已經在 Hadoop 生態系統裏面日趨成熟，該生態系統已經有多種方法能夠與 SQL 數據庫集成起來，及/或將 SQL 接口和查詢功能放在 NoSQL 數據庫上。在咱們看來，這一幕與上世紀 90 年代初出現將大型機應用軟件與 PC 和客戶端/服務器應用軟件集成起來的多種方法何其類似。