在最近前往荷蘭的商務旅程中，我開始沉思Baruch Spinoza(荷蘭)的深遠影響。Spinoza是文藝複興時期的偉大哲學家，與當時的同齡人不同，Spinoza強烈反對傳統的神學觀點。他的名言之一是：“不要對新思想感到驚訝。因為衆所周知，一件事不被許多人接受并不意味着它本身不是真的”。
他認為除了相對特定的情況，事物沒有本質上的好壞之分。這讓我聯想到紛繁的資料庫，它們從黑暗的“前雲時代”演化而來，盡管當今市場上有各種各樣的資料庫，但每個資料庫都有自己的用途。我們可以自由地從多個資料庫中選擇，選擇多方面的層，将龐然大物分解為微服務，通過利用各種雲資料管理工具和技術在建構現代雲應用程式方面進行創新。
雲計算前世(BC)
我們如何看待資料庫的曆史遺留問題：計算機資訊處理的早期，借由SQL資料庫的優點我們得以一統資料管理領域。在那些落後的年代，如果資料增長到幾GB，資料庫就會被認為相當龐大了。
然後到了中世紀時期，MySQL在1995年提出開源許可模式，并在資料管理領域産生了第一個連鎖反應。
随着資料變得越來越大，越來越多的應用程式開始轉向雲計算，資料庫技術出現了一種新的動向，大資料分析和雲應用的普及使得資料管理領域的啟蒙運動也在大力進軍加速。與MySQL時代相比，目前的形式——随着雲計算政策的首次出現——大量資料對象和分布式資料管理的出現——着實讓人感覺像是一條複興之旅。
雲計算今生(CE)
在我們當今的雲時代下，資料管理是一個資料庫資料存儲和堆疊的複雜網絡。随着MongoDB、HBase、Cassandra、CouchDB、DynamoDB等資料庫的普及，谷歌、Facebook、亞馬遜和其他公司已經将大量的NoSQL資料庫投入前線使用。這是一個巨大的挑戰，要把握每一個資料庫，并弄清楚為什麼使用它。為了了解潛層技術并獲得對使用哪個NoSQL資料庫的廣泛了解，CAP定理是一個很簡便的工具。
CAP定理圖
現代雲管理政策
在當今時代，資料管理需要被分解成許多不同的次元。在選擇新興閃耀的NoSQL資料庫之前，我們應該謹慎地考慮使用已經證明的SQL資料庫。在選擇具體技術之前，了解資料管理的短期和長期商業政策，權衡競争優先事項是至關重要的。
每當我想要評估一個資料管理政策時，我都會通過一份清單來幫助我做決定(如下)：
資料的安全性和合規性考慮是什麼
資料的短期和長期可擴充性是什麼
資料的類型和用途是什麼
模式更改的頻率是多少
資料檢索的延遲原因是什麼
資料的速率是多少
資料的多樣性是什麼
資料可用性的要求是什麼
資料存儲的搜尋需求是什麼
資料如何處理成資訊和見解
資料如何分析和報告
資料存儲在多使用者環境中嗎
資料管理的最佳成本是什麼
資料管理的層級是什麼
資料管理的生命周期要求是什麼(備份/恢複)
技術人員對于雲應用程式中使用了多個資料庫感到舒适。随着微服務和貨櫃化的使用，這一趨勢也在加速。此外，大多數雲應用程式商都意識到分離資料管理層的需求，這些層包括一個UI緩存層、CDN層、圖形分析層、業務層、業務分析層、安全層、報告層、物聯網裝置層等衆多層，每個層都可以有自己的資料管理政策——隻要資料被保護，通過等REST應用程式界面來進行通路。
把資料庫作為一項服務(DBaaS)
這是一個令人興奮的時代，一組成熟的DBaaS選項針對SQL和NoSQL資料庫應運而生。例如，亞馬遜極光提供MySQL和PostgreSQL資料庫，Instaclustr則提供Cassandra資料庫系統作為一項托管在AWS上的服務。
把分析作為一項服務(AaaS)
三大雲服務提供商都提供分析服務。雲分析平台采用的最大障礙是對資料安全的擔憂，AWS和Azure提供了一套穩健的資料分析服務，以減輕這種擔憂，Azure分析服務針對SQL，并提供強大的可視化Power BI工具。
圖資料庫使用
圖形資料庫變革使解決方案更快地從圖形比對查詢中受益，同時幫助加速基于網絡安全、推薦引擎、IT操作、網絡等方面的鄰接關系的搜尋。例如，在客戶的物聯網網絡安全産品中，我們使用Apache Spark和Cassandra DB作為分析層，基于MongoDB的網絡安全編制，但産生的資料由Neo4j圖資料庫中組織起來，以便進一步分析網絡安全的威脅。這是一個資料管理分級分離的絕好例子，在這種情況下，最佳資料庫被用于解決網絡安全産品裡非常複雜的問題。
物聯網資料庫
随着物聯網可行性應用程式的出現，從裝置層收集和處理的大量資料需要以一種專門的方式處理。我們已經成功地使用一個相對新興、令人振奮的InfluxDB開放源碼資料庫來有效處理時間序列資料。是以，适當的應用程式可以使用InfluxDB資料庫和相關聯TICK堆棧來進行資料管理：
TICK堆棧圖
原文釋出時間為：2017-10-16
本文作者：佚名
本文來自雲栖社群合作夥伴“51CTO”，了解相關資訊可以關注。