云重新定義數據庫 機器學習運行它

在預測游戲中，是我們再次進行清理的時候了。關注Big on Data兄弟安德魯·布魯斯(Andrew Brust)從行業高管的跨部門對人工智能相關的預測進行綜述，現在輪到我們了。我們將主要關注這對數據庫意味著什么，這是一種在Y2K被認為進入完成狀態之后的技術。

在2019年，我們認為AI和云是最偉大的顛覆者。

讓我們先描繪一下大局。在Ovum，我們一直預測，到2019年，所有新的大數據工作負載中有一半將在云中運行。根據我們的最新數據，這種情況已經出現，我們的調查顯示大約45%%的受訪者表示在云中至少運行了一些大數據工作負載。

云對數據庫的影響在于它正在重新定義如何設計和管理數據的基本架構假設。在本地，所有這些都是關于確定足夠的容量來充分利用，但沒有太多的能力來觸發軟件審計或導致過多的許可證費用。對于大數據而言，一切都是為了將??計算帶入數據，因為移動所有這些太字節的網絡開銷并不是特別合理。

進入云，商品基礎設施，低價存儲，更快的網絡互連，最重要的是，幾乎無限的規模，對于數據庫供應商，它又回到了繪圖板，例如將存儲與計算分離。為火災添加一些燃料：我們相信從云數據庫部署中實現價值的最佳方式是通過托管數據庫即服務(DBaaS)進行補丁，升級，備份，故障轉移，以及由云提供商進行配置和處理而不是DBA。這為我們的第一次預測提供了依據，順便提一下，這恰好符合流行語。

使用ML的自動駕駛數據庫將激增

云數據庫提供商將應用機器學習(ML)使其DBaaS產品自行運行。就在一年多以前，甲骨文開啟了大門，首先是自治數據倉庫18c，大約六個月后，隨著自治交易數據庫18c。不要在家里嘗試這個，Oracle只在其公共云中提供自治數據庫，而不是DBA控制環境。

由于幾個原因，將ML應用于數據庫操作是不費腦子的。首先，數據庫操作生成大量的日志數據以提供模型。其次，數據庫操作(特別是在托管云服務中)是一個有限的問題，可以抵抗漂移或范圍蔓延。最后，ML自動化的工作，例如如何為不同的負載模式配置數據庫，或者如何優化查詢，對于DBA而言，它不會增加價值。

毫不奇怪，自治數據庫的出現給DBA帶來了關于其工作安全性的重大擔憂。正如我們在Oracle OpenWorld postmortem中所提到的，我們看到的任何突破的最長行是DBA與自治數據庫會話。正如我們在那篇文章中所指出的那樣，除非他們的雇主是愚蠢的，否則他們仍然會有工作 - 你仍然需要DBA對數據庫將涵蓋的內容做出戰略決策，設計架構，并設置(并負責)與運行相關的策略并保護數據庫。

我們預計2019年將有更多云數據庫提供商遵循Oracle的領先優勢。使用ML運行數據庫將成為任何DBaaS產品的標準復選框項目; 我們還希望一些數據庫提供商能夠與Oracle區分開來，并將其中一些概念應用于內部部署。

無服務器成為復選框選項

我們還期望通過無需使用自動擴展來配置服務器，最初與AWS Lambda一起引入的無服務器計算將簡化應用程序開發，并將通過云DBaaS服務變得越來越普遍。在此方案中，DBA指定上限和下限閾值，然后指定數據庫自動標量。示例包括Amazon DynamoDB，其中無服務器是設計的核心，以及Amazon Aurora，其中無服務器最近作為選項用于尖峰很少或難以預測的應用程序。Google Cloud Firestore也是無服務器的; 在過去的一年中，MongoDB為其Atlas推出了Stitch無服務器產品 云服務。

無服務器不適用于所有用例; 例如，如果您的負載是可預測的或穩定的，那么保留容量將更加經濟。盡管如此，開發人員的需求將使2019年所有云運營數據庫成為無服務器的選擇。

分布式數據庫：寫得到尊重

云計算的另一項創新是分布式數據庫。今年，我們將看到分布式數據庫使寫入一等公民與讀取相提并論。

我們來解釋一下。分布式數據庫并不是從云開始的 - 早期的例子包括關系方面的Clustrix(最近被MariaDB收購)，Aerospike和NuoDB，以及像MongoDB，Couchbase和Apache Cassandra這樣的NoSQL 支持者。在這些玩家中，MongoDB一直是最大突破，主要是因為它的開發者友好性使其傳播病毒，盡管Cassandra已經獲得了一些像Netflix這樣的大型互聯網名稱。

但是云為分布式數據庫提供了一些不公平的優勢。首先，它消除了IT組織建立自己的數據中心和廣域骨干的需求。其次，大部分此類數據(如日志，產品目錄，物聯網數據等)已經存在于云中。最后，但并非最不重要的是，云增加了一些不公平的架構優勢：云提供商可以在自動復制，智能存儲和自動擴展到他們的平臺的本地工程。

那么，這與寫入和讀取性能有什么關系呢?大多數分布式數據庫都使用主/從體系結構進行操作，這些體系結構具有用于提交寫入或更新的集中主節點，由可以在地理上分布的只讀副本包圍。這使得可以在任何本地副本上執行的讀取比寫入快得多。

我們已經看到了新方法，例如多主機，它允許本地節點被聲明為特定事務的寫主機，或者一致性算法，輪詢節點以指定寫主機，以克服全局分布式數據庫上的寫入瓶頸。Amazon Aurora和DynamoDB; Google Cloud Spanner ; Microsoft Azure Cosmos DB ; 和Cockroach DB已經支持這些功能(或者提供測試版)，但除了Cloud Spanner和Cosmos DB之外，這些功能僅在區域內支持，而不是在區域內支持。在2019年，我們預計多區域支持將變得更加普遍。

由GDPR等數據隱私法規和許多國家強制要求數據保留在原產國內的地方法規所帶來的相關開發將是將數據庫分割為本地或區域主人的角色。這種做法將變得更加普遍。

喬治·阿納迪奧蒂斯得到了證明：星星終于與圖形數據庫保持一致

好吧，你可能聽過的不僅僅是我的Big on Data兄弟喬治·阿納多蒂斯(George Anadiotis)，他已經履行了自己的職責，在圖形數據庫上教育市場。他深入研究了知識圖，向我們介紹了新的圖形數據庫播放器，啟發了圖形查詢語言，并冒險了解圖形可以將網絡表示為數據庫的瘋狂概念。

正如Anadiotis 大約18個月前提出的那樣，“Graph技術正在從邊緣領域走向成為主流。” 好吧，早在2017年初，這種說法有點為時過早。

圖數據庫所解決的業務問題非常簡單。解讀影響社交網絡的模式，使領先品牌能夠識別和培養意見領袖; 繪制和優化供應鏈運作的復雜性; 或者了解網絡威脅的傳播，這些只是現實世界問題的幾個例子，它們都有一個共同點：它們的特點是多對多關系，不易被關系數據庫所代表。挑戰在于，作為數據庫，圖形是不熟悉的。他們缺乏構建關系模式的數十年知識，鍵值結構的簡單性或來自JavaScript社區的JSON文檔的現有知識庫的優勢。直到最近，

在過去一年中發生的變化是越來越多地接受事實上的標準，例如Apache TinkerPop框架和相關的Gremlin查詢語言，它為開發人員提供了一個共同的目標。我們看到來自Neo4J和TigerGraph的競爭 正在引入他們自己的更像SQL的變種。我們看到云巨頭進入該領域，亞馬遜推出海王星，而微軟的Azure Cosmos DB包括其支持的數據模型系列之一。但由于必要性是發明之母，在2019年，我們預計客戶360，物聯網應用和網絡安全將成為圖形數據庫需求的驅動力，現在這些數據庫比以往更容易獲取。