如何分析云數(shù)據(jù)庫現(xiàn)狀與前沿技術(shù)

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)如何分析云數(shù)據(jù)庫現(xiàn)狀與前沿技術(shù)，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

「一切都會運行在云端」?，F(xiàn)在越來越多的業(yè)務(wù)從自己維護基礎(chǔ)設(shè)施轉(zhuǎn)移到公有(或者私有)云上， 帶來的好處也是無需贅述的，極大降低了 IaaS  層的運維成本，對于數(shù)據(jù)庫層面來說的，以往需要很強的 DBA 背景才能搞定彈性擴容高可用什么的高級動作，現(xiàn)在大多數(shù)云服務(wù)基本都或多或少提供了類似的服務(wù)。

今天的分享主要集中在云服務(wù)商的云數(shù)據(jù)庫方案背后的架構(gòu)，以及我最近觀察到的一些對于云數(shù)據(jù)庫有意義的工業(yè)界的相關(guān)技術(shù)的進展。

Amazon RDS

其實說到公有云上的云數(shù)據(jù)庫，應(yīng)該最早 Amazon 的 RDS，最早應(yīng)該是在 2009 年發(fā)布的，Amazon RDS  的架構(gòu)類似在底層的數(shù)據(jù)庫上構(gòu)建了一個中間層(從架構(gòu)上來看，阿里云 RDS，UCloud RDS 等其他云的 RDS  服務(wù)基本是大同小異，比拼的是功能多樣性和實現(xiàn)的細節(jié))，這個中間層負責(zé)路由客戶端的 SQL  請求發(fā)往實際的數(shù)據(jù)庫存儲節(jié)點，因為將業(yè)務(wù)端的請求通過中間層代理，所以可以對底層的數(shù)據(jù)庫實例進行很多運維工作，比如備份，遷移到磁盤更大或者 IO  更空閑的物理機等，這些工作因為隱藏在中間層后邊，業(yè)務(wù)層可以做到基本沒有感知，另外這個中間路由層基本只是簡單的轉(zhuǎn)發(fā)請求，所以底層可以連接各種類型的數(shù)據(jù)庫。

所以一般來說，RDS 基本都會支持 MySQL / SQLServer / MariaDB / PostgreSQL  等流行的數(shù)據(jù)庫，對兼容性基本沒有損失，而且在這個 Proxy  層設(shè)計良好的情況下，對性能的損失是比較小的，另外有一層中間層隔離底層的資源池，對于資源的利用和調(diào)度上可以做不少事情，比如簡單舉個例子，比如有一些不那么活躍的  RDS 實例可以調(diào)度在一起共用物理機，比如需要在線擴容只需要將副本建立在更大磁盤的機器上，在 Proxy 層將請求重新定向即可，比如定期的數(shù)據(jù)備份可以放到 S3  上，這些一切都對用戶可以做到透明。

但是這樣的架構(gòu)缺點也同樣明顯：本質(zhì)上還是一個單機主從的架構(gòu)，對于超過***配置物理機的容量，CPU 負載，IO  的場景就束手無策了，隨著很多業(yè)務(wù)的數(shù)據(jù)量并發(fā)量的增長，尤其是移動互聯(lián)網(wǎng)的發(fā)展，***的可擴展性成為了一個很重要需求。當(dāng)然對于絕大多數(shù)數(shù)據(jù)量要求沒那么大，單實例沒有高并發(fā)訪問的庫來說，RDS  仍然是很適合的。

Amazon DynamoDB

對于剛才提到的水平擴展問題，一些用戶實在痛的不行，甚至能接受放棄掉關(guān)系模型和  SQL，比如一些互聯(lián)網(wǎng)應(yīng)用業(yè)務(wù)模型比較簡單，但是并發(fā)量和數(shù)據(jù)量巨大，應(yīng)對這種情況，Amazon 開發(fā)了 DynamoDB，并于 2012 年初發(fā)布  DynamoDB 的云服務(wù)，其實 Dynamo 的論文早在 2007 年就在 SOSP 發(fā)表，這篇有歷史意義的論文直接引爆了 NoSQL  運動，讓大家覺得原來數(shù)據(jù)庫還能這么搞，關(guān)于 DynamoDB 的模型和一些技術(shù)細節(jié)，我在我另一篇文章《開源數(shù)據(jù)庫現(xiàn)狀》提過，這里就不贅述了。

Dynamo 對外主打的特點是水平擴展能力和通過多副本實現(xiàn)(3副本)的高可用，另外在 API  的設(shè)計上可以支持最終一致性讀取和強一致性讀取，最終一致性讀取能提升讀的吞吐量。但是請注意，DynamoDB  雖然有強一致讀，但是這里的強一致性并不是傳統(tǒng)我們在數(shù)據(jù)庫里說的 ACID 的 C，而且由于沒有時序的概念(只有 vector  clock)，對于沖突的處理只能交給客戶端，Dynamo  并不支持事務(wù)。不過對于一些特定的業(yè)務(wù)場景來說，擴展能力和可用性是最重要的，不僅僅是容量，還有集群的吞吐。

阿里云 DRDS

但是那些 RDS 的用戶的數(shù)據(jù)量也是在持續(xù)增長的，對于云服務(wù)提供商來說不能眼睜睜的看著這些 RDS  用戶數(shù)據(jù)量一大就走掉或者自己維護數(shù)據(jù)庫集群，因為也不是誰都能徹底重構(gòu)代碼到 NoSQL  之上，并且分庫分表其實對于業(yè)務(wù)開發(fā)者來說是一個很痛苦的事情，在痛苦中往往是蘊含著商業(yè)機會的。

比如對于 RDS 的擴展方案，我介紹兩個比較典型的，***個是阿里云的 DRDS (不過現(xiàn)在好像從阿里云的產(chǎn)品列表里拿掉了?)，DRDS  其實思路很簡單，就是比 RDS 多一小步，在剛才提到的 RDS 的中間層中加入用戶配置的路由策略，比如用戶可以指定某個表的某些列作為 sharding key  根據(jù)一定規(guī)則路由到特定的實例，也可以垂直的配置分庫的策略。

其實 DRDS 的前身就是淘寶的 TDDL，只不過原來 TDDL 是做在 JDBC 層，現(xiàn)在將 TDDL 做進了 Proxy 層(有點像把 TDDL 塞到  Cobar 的感覺)，這樣的好處是，將應(yīng)用層分庫分表的工作封裝起來了，但是本質(zhì)上仍然是一個中間件的方案，盡管能對簡單的業(yè)務(wù)做到一定程度的 SQL 兼容。

對于一些復(fù)雜查詢，多維度查詢，跨 Shard 事務(wù)支持都是有限了，畢竟中間路由層對 SQL 的理解有限，至于更換 Sharding key  、DDL、備份也是很麻煩的事情，從 Youtube 開源的中間件 Vitess  的實現(xiàn)和復(fù)雜程度來看甚至并不比實現(xiàn)一個數(shù)據(jù)庫簡單，但是兼容性卻并沒有重新寫一個數(shù)據(jù)庫來得好。

Amazon Aurora

后來時間來到了 2015 年，Amazon 走了另外一條路，在 2015 年，Amazon Aurora 發(fā)布，Aurora  的資料在公網(wǎng)上并不多，Aurora 提供了 5x 于單機 MySQL 5.6 的讀吞吐能力，不過***也就擴展到 15  個副本，副本越多對寫吞吐影響越大，因為只有一個 Primary Instance 能提供寫入服務(wù)，單個副本***支持容量  64T，而且支持高可用以及彈性的擴展。

值得一提的是 Aurora  的兼容性，其實做數(shù)據(jù)庫的都知道，兼容性是一個很難解決的問題，可能實現(xiàn)上很小的差異就會讓用戶的遷移成本變得很大，這也是為什么中間件和分庫分表的方案如此反人類的原因，我們大多都在追求用戶平滑的遷移體驗。

Aurora 另辟蹊徑，由于公開的資料不多，我猜想 Aurora 在 MySQL 前端之下實現(xiàn)了一個基于 InnoDB  的分布式共享存儲層(https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/)，對于讀實例來說是很好水平擴展的，這樣就將  workload 均攤在前端的各個 MySQL 實例上，有點類似 Oracle RAC 那樣的 Share everything 的架構(gòu)。

這個架構(gòu)的好處相對中間件的方案很明顯，兼容性更強，因為還是復(fù)用了 MySQL 的 SQL 解析器，優(yōu)化器，業(yè)務(wù)層即使有復(fù)雜查詢也沒關(guān)系，因為連接的就是  MySQL。但是也正是由于這個原因，在節(jié)點更多，數(shù)據(jù)量更大的情況下，查詢并不能利用集群的計算能力(對于很多復(fù)雜查詢來說，瓶頸出現(xiàn)在 CPU 上)，而且  MySQL 的 SQL 優(yōu)化器能力一直是 MySQL 的弱項，而且對于大數(shù)據(jù)量的查詢的 SQL 引擎的設(shè)計是和單機有天壤之別的，一個簡單的例子，分布式  Query Engine 比如 SparkSQL / Presto / Impala 的設(shè)計肯定和單機的 SQL  優(yōu)化器完全不同，更像是一個分布式計算框架。

所以我認(rèn)為 Aurora  是一個在數(shù)據(jù)量不太大的情況下(有容量上限)，對簡單查詢的讀性能優(yōu)化的方案，另外兼容性比中間件的方案好得多。但是缺點是對于大數(shù)據(jù)量，復(fù)雜查詢的支持還是比較弱，另外對于寫入性能  Aurora 其實沒有做太多優(yōu)化(單點寫入)，如果寫入上出現(xiàn)瓶頸，仍然需要在業(yè)務(wù)層做水平或者豎直拆分。

Google Cloud BigTableGoogle

作為大數(shù)據(jù)的祖宗一樣的存在，對于云真是錯過了一波又一波，虛擬化錯過一波讓 VMWare 和  Docker 搶先了(Google 早在十年前就開始容器的方案，要知道容器賴以生存的 cgroups 的 patch 就是 Google  提交的)，云服務(wù)錯過一波讓 Amazon 搶先了(Google App Engine 真是可惜)，大數(shù)據(jù)存儲錯過一波讓開源的 Hadoop  拿下了事實標(biāo)準(zhǔn)，以至于我覺得 Google Cloud BigTable 服務(wù)中兼容 Hadoop HBase API 的決定，當(dāng)時實現(xiàn)這些 Hadoop  API for BigTable 的工程師心中應(yīng)該是滴血的 :)

不過在被 Amazon / Docker / Hadoop 刺激到以后，Google 終于意識到社區(qū)和云化的力量，開始對 Google Cloud 輸出  Google 內(nèi)部各種牛逼的基礎(chǔ)設(shè)施，2015 年終于在 Google Cloud Platform 上正式亮相，對于 BigTable  的架構(gòu)相信大多數(shù)分布式存儲系統(tǒng)工程師都比較了解，畢竟 BigTable 的論文也是和 Amazon Dynamo 一樣是必讀的經(jīng)典，我就不贅述了。

BigTable 云服務(wù)的 API 和 HBase 兼容，所以也是 {Key : 二維表格結(jié)構(gòu)}，由于在 Tablet Server  這個層次還是一個主從的結(jié)構(gòu)，對一個 Tablet 的讀寫默認(rèn)都只能通過 Tablet Master 進行，這樣使得 BigTable  是一個強一致的系統(tǒng)，這里的強一致指的是對于單 Key 的寫入，如果服務(wù)端返回成功，接下來發(fā)生的讀取，都能是***的值。

由于 BigTable 仍然不支持 ACID 事務(wù)，所以這里的強一致只是對于單 Key 的操作而言的。對于水平擴展能力來說， BigTable  其實并沒有什么限制，文檔里很囂張的號稱 Incredible scalability，但是 BigTable 并沒有提供跨數(shù)據(jù)中心(Zone)高可用和跨  Zone 訪問的能力，也就是說，一個 BigTable 集群只能部署在一個數(shù)據(jù)中心內(nèi)部，這其實看得出 BigTable 在 Google  內(nèi)部的定位，就是一個高性能低延遲的分布式存儲服務(wù)，如果需要做跨 Zone 高可用需要業(yè)務(wù)層自己做復(fù)制在兩個 Zone 之間同步，構(gòu)建一個鏡像的 BigTable  集群。

其實 Google 很多業(yè)務(wù)在 MegaStore 和 Spanner 出來之前，就是這么搞的，對于 BigTable  來說如果需要搞跨數(shù)據(jù)中心高可用，強一致，還要保證低延遲那是不太可能的，也不符合 BigTable 的定位。另外值得吐槽的是 BigTable 團隊發(fā)過一個  Blog  (https://cloudplatform.googleblog.com/2015/05/introducing-Google-Cloud-Bigtable.html)

里面把 HBase 的延遲黑得夠嗆，一個 .99 的響應(yīng)延遲 6 ms, HBase 280ms.  其實看平均響應(yīng)延遲的差距不會那么大....BigTable 由于是 C++ 寫的，優(yōu)勢就是延遲是相當(dāng)平穩(wěn)的。但是據(jù)我所知 HBase 社區(qū)也在做很多工作將 GC  帶來的影響降到最小，比如 off-heap 等優(yōu)化做完以后，HBase 的延遲表現(xiàn)會好一些。

Google Cloud Datastore

在 2011 年，Google 發(fā)表了 Megastore 的論文，***次描述了一個支持跨數(shù)據(jù)中心高可用 +  可以水平擴展 + 支持 ACID 事務(wù)語義的分布式存儲系統(tǒng)， Google Megastore 構(gòu)建在 BigTable 之上，不同數(shù)據(jù)中心之間通過 Paxos  同步，數(shù)據(jù)按照 Entity Group 來進行分片，Entity Group 本身跨數(shù)據(jù)中心使用 Paxos 復(fù)制，跨 Entity Group 的 ACID  事務(wù)需要走兩階段的提交，實現(xiàn)了 Timestamp-based 的 MVCC。

不過也正是因為 Timstamp 的分配需要走一遍 Paxos，另外不同 Entity Groups 之間的 2PC  通信需要通過一個隊列來進行異步的通信，所以實際的 Megastore 的 2PC 的延遲是比較大的，論文也提到大多數(shù)的寫請求的平均響應(yīng)延遲是 100~400ms  左右，據(jù) Google 內(nèi)部的朋友提到過，Megastore 用起來是挺慢的，秒級別的延遲也是常有的事情...

作為應(yīng)該是 Google 內(nèi)部***個支持 ACID 事務(wù)和 SQL 的分布式數(shù)據(jù)庫，還是有大量的應(yīng)用跑在 Megastore 上，主要是用 SQL  和事務(wù)寫程序確實能輕松得多。為什么說那么多 Megastore 的事情呢?因為 Google Cloud Datastore 的后端就是  Megastore…

其實 Cloud Datastore 在 2011 年就已經(jīng)在 Google App Engine 中上線，也就是當(dāng)年的 Data Engine 的  High Replication Datastore，現(xiàn)在改了個名字叫 Cloud Datastore，當(dāng)時不知道背后原來就是大名鼎鼎的 Megastore  實在是失敬。雖然功能看上去很牛，又是支持高可用，又支持 ACID，還支持 SQL(只不過是 Google 精簡版的 GQL)但是從 Megastore  的原理上來看延遲是非常大的，另外 Cloud Datastore 提供的接口是一套類似的 ORM 的 SDK，對業(yè)務(wù)仍然是有一定的侵入性。

Google Spanner雖然 Megastore 慢，但是架不住好用，在 Spanner 論文中提到，2012 年大概已經(jīng)有 300+ 的業(yè)務(wù)跑在  Megastore 上，在越來越多的業(yè)務(wù)在 BigTable 上造 ACID Transaction 實現(xiàn)的輪子后，Google 實在受不了了，開始造一個大輪子  Spanner，項目的野心巨大，和 Megastore 一樣，ACID 事務(wù) + 水平擴展 + SQL 支持，但是和 Megastore  不一樣的是，Spanner 沒有選擇在 BigTable 之上構(gòu)建事務(wù)層，而是直接在 Google 的第二代分布式文件系統(tǒng) Colossus 之上開始構(gòu)建  Paxos-replicated tablet。

另外不像 Megastore 實現(xiàn)事務(wù)那樣通過各個協(xié)調(diào)者通過 Paxos 來決定事務(wù)的 timestamp，而是引入了硬件，也就是 GPS  時鐘和原子鐘組成的 TrueTime API 來實現(xiàn)事務(wù)，這樣一來，不同數(shù)據(jù)中心發(fā)起的事務(wù)就不需要跨數(shù)據(jù)中心協(xié)調(diào)時間戳，而是直接通過本地數(shù)據(jù)中心的  TrueTime API 來分配，這樣延遲就降低了很多。

Spanner 近乎***的一個分布式存儲，在 Google 內(nèi)部也是的 BigTable 的互補，想做跨數(shù)據(jù)中心高可用和強一致和事務(wù)的話，用  Spanner，代價是可能犧牲一點延遲，但是并沒有Megastore 犧牲那么多;想高性能(低延遲)的話，用 BigTable。

Google Spanner

目前沒有在 Google Cloud Platform 中提供服務(wù)，但是看趨勢簡直是一定的事情，至少作為 Cloud  Datastore 的下一代是一定的。另外一方面來看 Google 仍然沒有辦法將 Spanner 開源，原因和 BigTable 一樣，底層依賴了  Colossus 和一堆 Google 內(nèi)部的組件，另外比 BigTable 更困難的是，TrueTime 是一套硬件...

所以在 12 年底發(fā)布 Spanner 的論文后，社區(qū)也有開源的實現(xiàn)，比如目前比較成熟的 TiDB 和  CockroachDB，一會提到社區(qū)的云數(shù)據(jù)庫實現(xiàn)的時候會介紹。Spanner 的接口比 BigTable 稍微豐富一些，支持了它稱之為  Semi-relational 的表結(jié)構(gòu)，可以像關(guān)系型數(shù)據(jù)庫那樣進行 DDL，雖然仍然要指定每行的 primary key，但是比簡單的 kv  還是好太多。

Google F1

在 Spanner 項目開始的同時，Google 啟動了另外一個和 Spanner 配套使用的分布式 SQL 引擎的項目  F1，底層有那么一個強一致高性能的 Spanner，那么就可以在上層嘗試將 OLTP 和部分的 OLAP 打通，F(xiàn)1  其實論文題目說是一個數(shù)據(jù)庫，但是它并不存儲數(shù)據(jù)，數(shù)據(jù)都在 Spanner 上，它只是一個分布式查詢引擎，底層依賴 Spanner 提供的事務(wù)接口，將用戶的  SQL 請求翻譯成分布式執(zhí)行計劃。

Google F1提供了一種可能性，這是在其他的數(shù)據(jù)庫中一直沒有實現(xiàn)過的，OLTP 與 OLAP 融合的可能性，因為 Google F1 設(shè)計目標(biāo)是給  Google 的廣告系統(tǒng)使用，廣告投放系統(tǒng)這類系統(tǒng)一是對于一致性要求很高，壓力也很大，是典型的 OLTP  場景;第二是可能會有很多復(fù)雜的廣告投放效果評估的查詢，而且這類的查詢越是實時越好，這又有點實時 OLAP 的意思。

傳統(tǒng)的做法是 OLTP  的數(shù)據(jù)庫將數(shù)據(jù)每隔一段時間同步一份到數(shù)據(jù)倉庫中，在數(shù)據(jù)倉庫中離線的進行計算，稍微好點的使用一些流式計算框架進行實時計算，***種使用數(shù)據(jù)倉庫的方案，實時性是比較差的，倒騰數(shù)據(jù)是很麻煩的事情;至于使用流式計算框架的方案，一是靈活性不好，很多查詢邏輯需要提前寫好，沒法做很多  Ad-hoc 的事情，另外因為兩邊是異構(gòu)的存儲，導(dǎo)致 ETL 也是很麻煩的工作。

F1 其實依靠 Spanner 的 ACID 事務(wù)和 MVCC 的特性實現(xiàn)了 100% 的 OLTP，并且自身作為一個分布式 SQL  引擎，可以利用集群的計算資源實現(xiàn)分布式的 OLAP 查詢。這帶來的好處就是并不需要額外在設(shè)置一個數(shù)據(jù)倉庫進行數(shù)據(jù)分析，而是直接在同一個數(shù)據(jù)庫里實時分析，另外由于  Spanner 的 MVCC 和多副本帶來的 Lock-free snapshot read 的特性，這類 OLAP 查詢并不會影響正常 OLTP  的操作。

對于 OLTP 來說，瓶頸經(jīng)常出現(xiàn)在 IO 上，對于 OLAP 來說，瓶頸反而經(jīng)常出現(xiàn)在 CPU  也就是計算上，其實看上去是能融合起來，提升整個集群的資源利用率，這也是我看好 Google F1 + Spanner  這個組合的原因，未來的數(shù)據(jù)庫可能會融合數(shù)據(jù)倉庫，提供更完整且更實時的體驗。

(其實這個下面的 GFS 不太準(zhǔn)確，現(xiàn)在應(yīng)該是 Colossus)

Open source cloud-native database

2016 年在硅谷突然有個新詞火了起來 GIFEE，Google  Infrastructure For Everyone Else，大家意識到好像隨著新一代的開源基礎(chǔ)軟件的繁榮發(fā)展，原來在 Google  內(nèi)部的基礎(chǔ)設(shè)施已經(jīng)有很多高質(zhì)量的開源實現(xiàn)，比如容器方面有 Docker，調(diào)度器方面 Google 主動開源的 Borg 的第二代 Kubernetes，傳統(tǒng)的  BigTable 和 GFS 社區(qū)還有雖然屎但是還是能湊合用的 Hadoop，而且很多大廠覺得 Hadoop 屎的都基本自己都造了類似的輪子... 更別說最近  Google 開源上癮，Kubernetes 就不提了，從大熱的 Tensorflow 到相對冷門但是我個人認(rèn)為意義重大的 Apache Beam(Google  Cloud Dataflow 的基礎(chǔ))，基本能獨立開源的都在積極的擁抱社區(qū)。

這就造成了社區(qū)與 Google 內(nèi)部差距正在縮小，但是目前來說, 其他都好說, 只是 Spanner 和 F1 并不是那么容易造的，就算拋開  TrueTime 的硬件不提，實現(xiàn)一個穩(wěn)定的 Multi-Paxos 都不是容易的事情，另外分布式 SQL  優(yōu)化器這種事情也是有很高技術(shù)門檻的，另外就算造出來了，測試的復(fù)雜度也一點不比實現(xiàn)的復(fù)雜度低(可以參考 PingCAP 的分布式測試哲學(xué)的幾篇分享)。

目前從全球范圍內(nèi)來看，我認(rèn)為開源世界只有兩個團隊：一個 PingCAP 的 TiDB，一個 CockroachLabs 的 CockroachDB  是有足夠的技術(shù)能力和視野能將 Spanner 的開源實現(xiàn)造出來的，目前 TiDB 已經(jīng) RC1 并有不少使用者在生產(chǎn)環(huán)境使用，比 CockroachDB  的成熟度稍好，架構(gòu)上更接近正統(tǒng)的 F1 above Spanner 的架構(gòu)，CockroachDB 的成熟度稍微落后一些，并且協(xié)議選擇  PostgreSQL，TiDB 選擇的是 MySQL 的協(xié)議兼容。

而且從 TiDB 的子項目 TiKV 中，我們看到了新一代分布式 KV 的雛形，RocksDB + Multi-Raft  不依賴第三方分布式文件系統(tǒng)(DFS)提供水平擴展能力，正在成為新一代分布式 KV  存儲標(biāo)準(zhǔn)架構(gòu)。另外也很欣喜的看到竟然是由一個國內(nèi)團隊發(fā)起并維護的這樣級別的開源項目，即使放到硅谷也是***的設(shè)計和實現(xiàn)，從 Github  的活躍度和使用的工具及運營社區(qū)的流程上來看，很難看出是一個國內(nèi)團隊。

Kubernetes + Operator

剛才提到了一個詞 Cloud-Native,  其實這個詞還沒有準(zhǔn)確的定義，不過我的理解是應(yīng)用開發(fā)者和物理設(shè)施隔離，也就是業(yè)務(wù)層不需要再去關(guān)心存儲的容量性能等等一切都可以透明水平擴展，集群高度自動化乃至支持自我修復(fù)。對于一個大規(guī)模的分布式存儲系統(tǒng)來說人工是很難介入其中的，比如一個上千個節(jié)點的分布式系統(tǒng)，幾乎每天都可能有各種各樣的節(jié)點故障，瞬時網(wǎng)絡(luò)抖動甚至整個數(shù)據(jù)中心直接掛掉，人工去做數(shù)據(jù)遷移，數(shù)據(jù)恢復(fù)幾乎是不可能的事情。

很多人非?？春?Docker，認(rèn)為它改變了運維和軟件部署方式，但是我認(rèn)為更有意義的是 Kubernetes，調(diào)度器才是 Cloud-native  架構(gòu)的核心，容器只是一個載體而已并不重要，Kubernetes 相當(dāng)于是一個分布式的操作系統(tǒng)，物理層是整個數(shù)據(jù)中心，也就是 DCOS，這也是我們在  Kubernetes 上下重注的原因，我認(rèn)為大規(guī)模分布式數(shù)據(jù)庫未來不可能脫離 DCOS。

不過 Kubernetes  上對于有狀態(tài)的服務(wù)編排是一件比較頭疼的事情。而一般的分布式系統(tǒng)的特點，他不僅每個節(jié)點都有存儲的數(shù)據(jù)，而且他還要根據(jù)用戶需要做擴容，縮容，當(dāng)程序更新時要可以做到不停服務(wù)的滾動升級，當(dāng)遇到數(shù)據(jù)負載不均衡情況下系統(tǒng)要做  Rebalance，同時為了保證高可用性，每個節(jié)點的數(shù)據(jù)會有多個副本，當(dāng)單個節(jié)點遇到故障，還需要自動恢復(fù)總的副本數(shù)。而這些對于 Kubernetes  上的編排一個分布式系統(tǒng)來說都是非常有挑戰(zhàn)的。

Kubernetes 在 1.3 版本推出了 Petset ，現(xiàn)在已經(jīng)改名叫 StatefulSet， 核心思想是給 Pod 賦予身份，并且建立和維護  Pod 和 存儲之間的聯(lián)系。當(dāng) Pod 可能被調(diào)度的時候，對應(yīng)的 Persistent Volume 能夠跟隨他綁定。但是它并沒有完全解決我們的問題，PS  仍然需要依賴于 Persistent Volume，目前 Kubernetes 的 Persistent Volume 只提供了基于共享存儲，分布式文件系統(tǒng)或者  NFS 的實現(xiàn)，還沒有提供 Local Storage 的支持，而且 Petset 本身還處于 Alpha 版本階段，我們還在觀望。

不過除了 Kubernetes 官方社區(qū)還是有其他人在嘗試，我們欣喜的看到，就在不久之前，CoreOS 提出了一個新的擴展 Kubernetes  的新方法和思路。CoreOS 為 Kubernetes 增加了一個新成員，叫作 Operator。Operator 其實是一種對 Controller  的擴展，具體的實現(xiàn)由于篇幅的原因我就不羅嗦了，簡單來說是一個讓 Kubernetes 調(diào)度帶狀態(tài)的存儲服務(wù)的方案，CoreOS 官方給出了一個  Etcd-cluster 的備份和滾動升級的 operator 實現(xiàn)。

上述就是小編為大家分享的如何分析云數(shù)據(jù)庫現(xiàn)狀與前沿技術(shù)了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。