天天看點

雲資料庫産品及架構設計背後的考量

<b>摘要:</b>8月24日,阿裡雲資料庫技術峰會到來,本次技術峰會邀請到了阿裡集團和阿裡雲資料庫老司機們,為大家分享了一線資料庫實踐經驗和技術幹貨。在本次峰會上,阿裡雲資料庫進階産品專家蕭少聰(鐵庵)介紹了全體系阿裡雲資料庫産品并對于阿裡雲資料庫産品的實作架構進行了分享,幫助大家了解了阿裡雲全資料庫産品體系能解決哪些實用場景的問題,同時幫助大家了解其解決的原理。

<b>以下内容根據演講嘉賓現場視訊以及ppt整理而成。</b>

本次分享将主要介紹阿裡雲是如何設計雲資料庫産品的架構的,以及在雲資料庫産品的架構設計背後的故事。本次的分享将不會非常深入技術底層細節,而是希望通過分享使得大家了解在使用雲資料庫時應該如何去規劃,以及阿裡雲在設計雲資料庫産品的時候存在什麼樣的思考。

<b></b>

一、雲資料庫的市場背景

<b>多産品類型混合</b>

在市場上面,大家可以看到類型非常多樣的資料庫産品。如果大家今天還是在使用像sql server或者mysql這樣單獨的關系型資料庫,那麼可能業務所覆寫的場景還是比較有限的。而往往在一家中型或者比較大型的公司裡面,已經開始用到很多不同的資料庫産品了。

雲資料庫産品及架構設計背後的考量

<b>系統架構越發複雜</b>

如上圖所示,通常情況下,在業務剛開始的時候使用的是一個sql資料庫或者nosql資料庫,但是随着業務慢慢的發展就會用到key-value的緩存資料庫,再之後可能就會發展到資料倉庫,同時也可能發展到大資料的系統。

接下來為大家介紹一家公司從小型企業逐漸成長為大型企業的過程中的資料庫架構設計的發展步驟以及在運作過程中每個階段的資料庫演化情況。如下圖所示,在初始階段,整個資料庫架構的結構是比較簡單的,圖中僅有3台伺服器,這意味着公司在剛剛開始的時候可能隻有幾台資料庫伺服器,它們可能是sql的系統,也可能是nosql的系統。此時dba以及管理人員不需要去做過多的結構使用分析。然而,在進行管理的過程中,dba往往會身兼多職,在這個時候的dba可能在管理資料庫的同時也在做開發以及對于作業系統的運維工作。

雲資料庫産品及架構設計背後的考量

更進一步,當企業發展到初具規模的時候,資料庫往往就不能夠以單節點的方式去運作了,此時往往需要配合一些叢集以及一些其他的資料庫。例如在剛剛開始的時候,隻用到了單獨的sql資料庫以及nosql資料庫,但是在系統初具規模的時候,可能兩方面的資料庫都會用到,同時還可能會用到像key-value緩存資料庫等進行混合來實作整體的資料庫業務效果。在這個過程之中,dba扮演着非常神奇的角色,此時的dba不隻需要去做普通的sql系統管理,而且還需要管理nosql以及key-value資料庫,而且很多時候整體系統監控以及系統維護都需要由dba進行完整地支撐,此時的dba可以稱之為“神奇的dba”,因為他什麼都需要管。

雲資料庫産品及架構設計背後的考量

當業務進一步發展到下一個階段時又會是什麼情況呢?其實很多公司在剛剛起步時往往隻有一個項目,當公司的業務發展到一定規模的時候,項目也會逐漸地增加。是以,每一個項目都将會使用一整套資料庫結構,而在這個時候項目也會不斷地提升和增長,每個項目會使用單獨整體資料庫結構,這時候的資料庫管理者dba就不再是單個人了,往往會有2到3個dba,而且他們每個人應該都能夠獨當一面,并且應該具有完整的架構經驗。正是在這個時候才是對于企業的比較大的挑戰,大家都知道在技術人員的職業發展生涯當中,技術人員都是希望能夠承載更多的工作或者讓自己的職業生涯獲得更大的發展,是以在這個過程之中往往能夠形成企業與技術人員本身之間認知差異的博弈。很多時候如果企業發展的速度跟不上技術人員的技術成長速度,技術人員就很可能嘗試跳槽或者尋找其他的工作,當技術專家離開企業的時候,就會使得企業的進一步發展受到阻礙。

雲資料庫産品及架構設計背後的考量

<b>資料庫容災:兩地n中心</b>

在系統架構越發複雜的情況下,企業所遇到的不僅是人員的問題,在進行資料庫架構發展演變的過程當中,企業還會遇到另外的一個問題:在業務發展到一定階段之後,往往需要産生更多的資料架構的邏輯,包括在業務要求之下以及在監管部門的要求之下,可能需要實作像兩地三中心等等一系列複雜的架構,這也會使得業務的運作成本成倍地提高。因為在單獨的機房之下進行資料庫叢集的搭建會是比較友善的,而在實作像兩地三中心這樣的架構的時候,還需要去購買同城光纖以及異地光纖等等基礎設施,這部分大量的費用也往往使得很多的企業在這樣的位置上處于停步狀态。

雲資料庫産品及架構設計背後的考量

如果企業希望能夠進一步地突破發展瓶頸往往還需要使用更多的資料庫架構,例如需要使用到olap的資料庫倉庫以及大資料的海量分析等。在這樣的情況下,dba團隊以及整體系統的建構成本都将會更大地提升。

雲資料庫産品及架構設計背後的考量

<b>阿裡雲 雲資料庫:産品理念</b>

前面為大家介紹了一個企業從小型到中型或者說是到達爆發期以及更進一步的上升期的過程之中,對于資料庫可能會出現什麼樣的要求。接下來為大家分享在阿裡雲的雲資料庫中希望為大家提供什麼樣的産品理念。

雲資料庫産品及架構設計背後的考量

首先,大家可以看到在業務各個不同的發展過程當中需要使用到不同的資料庫、資料庫的組合以及不同的資料庫産品的層級,是以阿裡雲會設計自己的資料庫産品讓不同的層級都可以适用。

第二點,阿裡雲會盡可能地去幫助企業提高自身的發展效率,也就是讓企業非常友善地擴充自己的資源,讓這些資源為使用者直接提升生産效率。

第三點,阿裡雲會直接降低整個架構的建構門檻,在傳統企業架構之下,從單個機房變到多個機房或者從單個伺服器變為多個伺服器的時候,會存在很多技術以及生産成本的門檻限制,阿裡雲希望能夠通過雲資料庫整體的底層架構,包括飛天架構将這些門檻降到最低。

最後要提到的也是本次中最希望分享的一點就是:在雲資料庫之上,阿裡雲所希望達到的終極目标是解放dba。其實通常情況下在一家公司裡面,dba很多時候往往不會受到很大的重視,因為在企業中dba日常所做的工作往往是像部署、備份等等一系列運維工作,而這些工作将會占據dba 50%到60%的時間,而這些工作卻沒有辦法去為企業帶來直接的生産效率。而在雲資料庫上面,通過雲架構的自動化管理來完成所有的運維工作,dba可以将自己更多的時間投入到業務架構的優化之中。什麼是業務架構的優化呢?比如表結構設計的不合理需要進行優化,一些sql存在性能問題需要優化,以及某些設計在業務發展的過程中已經不合時宜需要優化,所有的這些優化都是dba應該去做的。而dba也是最容易發展成為企業核心架構師的一群人,他們的工作應該更多地為企業真正地産能以及技術能力的輸出發揮貢獻,而不是去過多地關注每一天的部署、備份這樣繁瑣的運維工作。

以上就是在設計雲資料庫過程中,大家所看到的市場需求情況以及阿裡雲的雲資料庫産品設計理念。

<b>二、永恒不變的話題:需求</b>

其實前面所講的長篇故事都是需求,每一個需求都需要得到滿足。那麼面對這些需求,阿裡雲的雲資料庫是如何一步一步解決的呢?

<b>分層:擴充邊界覆寫不同層級的使用者</b>

第一步就是進行分層。之前使用過阿裡雲資料庫的朋友可能會有印象,阿裡雲最初推出的資料庫版本叫做高可用版本,這應該也是目前阿裡雲資料庫裡面使用量最多的版本。在這個版本裡面會有兩個資料庫伺服器,一主一備,他們提供了非常好的性能并且能夠快速地進行切換,然而在這樣的架構之下,成本實際上翻了一倍。很多的使用者,特别是入門級别的剛開始使用雲資料庫的使用者,往往不需要主備的資料庫系統,而是希望投入更低的成本,這個時候阿裡雲就推出了雲資料庫的基礎版。基礎版的架構隻有單個節點,基礎版的推出使得使用者的成本得以降低。同時需要注意的一點就是:在單節點或者說是基礎版之下,高可用到底是如何保障的。其實大家可以放心,在基礎版之下,阿裡雲同樣提供了高可用的保障,隻不過沒有兩個節點的保障而是将整個資料庫運作在飛天架構之上,如果資料庫出現問題或者資料庫所在的主機出現了問題,飛天系統會自動尋找新的主機、新的節點将整個系統運作起來,隻不過切換時間會稍微長一些,但是不會出現像系統長期斷開的情況。

雲資料庫産品及架構設計背後的考量

再進一步,很多進階使用者,特别是在金融界中的使用者所要求的資料穩定性以及對于資料故障時的rpo都會有更高的要求,這時候阿裡雲就提供了金融版資料庫。在兩節點的基礎之上可能會擴充到三節點甚至更多節點的叢集的應用。在做了這樣的工作之後,阿裡雲實際上是拓展了雲資料庫産品的邊界,從剛開始阿裡雲資料庫隻有高可用雙節點版本,擴充到單節點的基礎版以及多節點的金融版,使得不同需求的使用者可以擷取到他們所需要的各種不同規格的雲資料庫服務。

<b>效率:化繁為簡,釋放工作量</b>

在有了資料庫的運作環境之後,其實大家可以看到各個使用者往往都會有自己不同時段的類似于促銷、活動等的一些業務,在這些業務之中,使用者的查詢要求往往是非常高的,會出現非常高的查詢峰值,這時可以通過隻讀節點來進行解決。在阿裡雲中就直接提供了隻讀請求的執行個體,而不需要使用者自己再去搭建隻讀執行個體了。如果大家自己搭建過資料庫,就可能對于這個過程有所體會,當搭建一個隻讀執行個體時往往需要去建構或者配置3到4個配置檔案,而且各個主機之間,包括使用者權限以及密碼的同步等都需要進行規劃,這個過程對于初級的dba而言是比較困難和麻煩的事情,而且與此同時還需要保障整個系統在業務發展的過程中的穩定運作。

雲資料庫産品及架構設計背後的考量

在阿裡雲上面,實際上會将建構隻讀執行個體的過程更加簡化,因為阿裡雲資料庫本身的底層系統架構會自動化地進行所有的配置以及業務确認,使用者隻需要在界面上面點選按鈕并添加一個隻讀執行個體就能夠将隻讀執行個體建立完成,而且允許使用者建立5個甚至10個隻讀執行個體。在這個過程中,大家會發現雖然阿裡雲提供了直接添加隻讀執行個體的功能,而且完成了其中的同步,但是業務方也就是如上圖所示的雲伺服器ecs上面的應用還是需要通過把讀寫請求和隻讀請求進行業務分離,這對于資料庫的開發是存在入侵性的,也就是說原來開發的程式隻需要一個資料庫進行操作就可以了,而由于目前使用了隻讀執行個體,則需要将所有的隻讀查詢都單獨地拎出來讓其去通路其他節點,這一點對于程式的入侵性可能會是非常大的,這就可能會使得很多的開發者無法直接使用到阿裡雲的隻讀執行個體了,或者有很多的工作需要重新進行開發。

<b>效率: 化繁為簡,釋放工作量, 直接支援讀寫分離</b>

針對上述的問題,阿裡雲的資料庫在發展的過程中也會收到使用者的需求和報告,是以阿裡雲資料庫就進行了進一步的優化。在隻讀執行個體的運作條件之下,阿裡雲資料庫還進一步地提供了讀寫分離的ip通路,其主要會在proxy業務層底下實作所有sql的收集,并且對于所有的收集到的sql進行分類,如果發現sql操作既有讀操作也有寫操作的時候,也就是讀寫操作在同一個事務裡面的時候,會将這些操作自動地送出到主節點。而如果當發現事務中所有的操作都是讀操作的時候,proxy層就會将這些隻讀的查詢平均地配置設定到各個隻讀節點。這意味着應用程式不需要改變本身的代碼,阿裡雲就能夠自動地為使用者實作讀寫分離的工作,而業務方不需要去修改自己的業務代碼。通過這樣查詢的讀寫分離的功能,可以非常好地簡化本身開發以及維護的工作量。

雲資料庫産品及架構設計背後的考量

<b>效率:新一代關系型資料庫演進</b>

其實除了上面所說的這些,阿裡雲資料庫所做的工作還遠沒有結束。如果大家留意了阿裡雲最近的新聞或者最新的産品動向就會知道,在阿裡雲資料庫最新的版本中提供了關系型資料庫polardb的叢集,這款産品預計将在十月份推出,在這款産品上面不單單解決了讀寫分離的問題,也會使用到最新的硬體技術去達到比較好的讀寫資源比。在讀寫分離的業務之下,當主節點有資料寫入的時候,所有的資料需要同步到每一個隻讀節點,而在主節點和隻讀節點之間或許會存在網絡延遲,這些網絡延遲可能會導緻從主節點讀出的資料和從隻讀節點讀出的資料出現不一緻的情況,而這是需要業務方或者開發人員知曉并通過業務進行保障的。

雲資料庫産品及架構設計背後的考量

而在polardb中,阿裡雲嘗試使用了一種新型的架構,通過rdma網絡會将下層的各個存儲節點進行整合管理,通過分布式raft協定實作完整的底層叢集。這樣所能達到的效果就是當主節點進行資料寫入的過程中,底層的raft協定的資料叢集會把資料自動打散到三個或者以上的存儲節點上面,同時這些資料一旦寫入,在其他的隻讀節點上就可以讀到。是以可以看到在這樣的架構之下,減少了多節點之間的資料複制,網絡帶寬的消耗會更低,同時主節點和隻讀節點之間網絡資料延遲基本為零,也就是說隻要資料寫入了,隻讀節點就能夠讀取到,符合acid的完整原則。所有的資料在存放的時候都不會少于三節點,任何一個節點或者資料子產品出現故障的時候,都不會造成資料丢失。在這樣的架構之下,可以進一步使得資料庫的使用者擷取更高的成本效益。

<b>門檻: 綜合系統管理門檻高</b>

以上分享的是在資料庫關系的演進中阿裡雲提供的一些思考和産品,而下面會分享另外一個問題。如下圖所示,當一個業務發展到比較龐大的資料規模時,存下來的業務資料還需要進行産品的分析,比如當資料量已經存放到兩三年的時候,企業主肯定希望能夠通過這兩三年沉澱的資料來進行業務分析。這個時候,在傳統的架構之下,往往會向如圖中所看到的把資料通過etl,也就是資料導入到資料倉庫,并在資料倉庫之上再去做olap的業務分析。同時由于資料量越來越大,是以也需要通過分布式的資料庫中間件實作一個動作,也就是将整個的資料庫進行分庫分表式的管理。當然,這樣的功能在網際網路圈已經使用的非常多了,但是大家會發現下圖中存在四個藍色的管理标記,這是因為在每個層級當中都需要對于資料庫進行一些單獨的人為操作和人為幹預。

雲資料庫産品及架構設計背後的考量

<b>簡化分庫分表管理,一份資料實作oltp+olap=htap</b>

可以看到在上圖的整個運作流程中,每一個節點上面都需要進行配置和規劃,而這些所有的配置和規劃都需要消耗時間。還有一點就是業務系統是oltp的系統,所有的線上的業務都在上圖中左側的oltp系統裡面,當需要進行分析的時候并不能直接在業務系統進行分析,因為這會影響業務系統本身的性能,是以需要再進行一次資料的抽取,将資料抽取到olap的資料倉庫中,然後再去做查詢。這樣動作使得資料多了備援,而且所有的資料無法實作所謂的“t+0”的實時分析,在這種情況下,所有的操作以及運維管理會消耗更多的使用資源。是以,在阿裡雲中也提供了hybriddb for mysql的架構。通過hybriddb for mysql架構的資料庫,可以實作将上圖中所看到的整個資料鍊路,包括分布式資料庫中間件以及資料倉庫都整合到一個資料庫中,這個資料庫可以直接實作oltp的事務操作,同時也接受olap的資料分析處理,而且整個系統也是分布式系統。

雲資料庫産品及架構設計背後的考量

在這個系統之上最大的好處就是使用者不再需要去分别地管理兩個業務系統:oltp系統和olap系統。與此同時還可以實作計算和存儲的分離操作,如果計算資源不足還可以單獨地增加計算資源使得查詢速度更快。而且整個系統将會直接相容mysql的生态,是以使用者不需要過多地修改自己資料庫查詢的業務邏輯,可以直接使用mysql的用戶端以及各種工具來連接配接到資料庫上面去進行操作。是以,在hybriddb for mysql資料庫中實作了一種新的形态叫做htap,實際上就是在同一個資料庫裡面不僅可以進行oltp操作,還可以進行olap操作,而且其空間可以擴充到超過pb的級别。

<b>釋放:安心原于透明,主動的提醒</b>

阿裡雲的資料庫産品除了提供了以上的功能以外,為了使得dba更加省心和安心,絕對離不開的就是對于各種資源的監控以及對于引擎的監控。在這裡不做過多的解析,因為在産品上大家可以看到,阿裡雲已經把自己原來在天貓、淘寶等的各方面的經驗進行了整體的輸出,會提供非常深度的包括tps、qps以及緩存命中率等等一系列的監控,而且可以産生直接的圖表。在報警方面,可以通過雲監控設定所需要的報警,當水位超過了一定的範圍之後可以直接發送短信、郵件甚至通過電話的告警來提醒dba進行擴容或者及時地發現問題。更進一步,阿裡雲還将會提供雲dba的協助工具,甚至還會為使用者提供index推薦以及像告警錯誤業務分析等服務。

雲資料庫産品及架構設計背後的考量

<b>釋放使用者成本:中小企業也可以獲得高端服務</b>

在企業發展的過程中,随着業務不斷地發展,需要更好地保障業務的連續穩定性。對于很多企業而言,資料庫中心裡面往往隻有一個idc的機房,然而如果這個idc機房出現斷電或者故障的時候,就沒有辦法進行更進一步的業務操作。阿裡雲在資料庫體系之下已經完成如下圖所示的整體架構。當大家看到阿裡雲資料庫産品購買頁的時候會發現阿裡雲不僅提供了單中心的雙節點模型,還在很多地域中提供了多可用區的模型。多可用區模型就是把主節點和備用節點放在一個城市的兩個不同的可用區上,也就是說使用者的執行個體隻購買了一個,但是在部署的時候卻部署在了一個城市的兩個中心,一旦主中心出現整體故障的時候,使用者的業務依然可以通過切換到備用中心繼續提供服務。大家可以想象,如果沒有雲架構的支撐,依靠自己搭建多可用區模型的時候,可能會需要非常高的業務成本,這是因為同城之間光纖搭建的費用是非常昂貴的。

雲資料庫産品及架構設計背後的考量

除此之外,阿裡雲還會為企業提供跨資料中心的通路。很多使用者可能會說現在自己的企業還不大,還不需要到這樣的業務保護,但是在這裡想告訴大家的是這樣的觀點往往是不正确的。如上圖所示,目前在同城雙中心災備裡面不需要增加使用者的成本,那麼就完全可以在企業發展之初就使用這樣的架構,因為在企業發展的過程中,任何一個技術上的故障或者服務的當機往往會造成後續更大的損失。是以如果能夠提前在不增加過多成本的情況下實作企業同城容災以及跨地域業務,往往能夠對于企業業務的發展提供更大的幫助。在阿裡雲上,其實基于阿裡雲本身的技術架構就可以為使用者更好地釋放這部分成本,而使用者不需要自己搭建光纖就可以複用所有現有的網絡,這使得企業在初始階段就可以像大企業一樣使用到所有的資料庫的高端服務。

大家可以看到,在阿裡雲資料庫業務中比較注重的就是如下圖所示的五點:如何幫助使用者節省成本,如何使資料庫的性能達到更高,如何維護業務的連續性,以及業務擴充能力和資料容災等。而這一切的能力都是通過雲托管平台進行規劃和賦能的。

雲資料庫産品及架構設計背後的考量

<b>三、生态的力量</b>

在以上的内容中為大家分享了雲資料庫上的産品驅動、阿裡雲資料庫提供了什麼樣的保護以及阿裡雲資料庫是如何承載使用者需求的。接下來為大家分享資料庫生态的力量。

<b>阿裡雲mysql生态體系</b>

當阿裡雲最初去規劃資料庫産品的時候,首先做的産品就是mysql,因為在當時mysql也是使用最為廣泛的資料庫,特别是在網際網路業界。但是在不斷的發展過程中也發現不斷有更多的網際網路業務以及企業客戶會進入到阿裡雲體系上來,是以阿裡雲需要有更多的資料庫類型來對這些使用者進行支撐。很多的使用者不僅僅需要使用sql的資料庫,還會需要做緩存并且需要進行資料分析。在下圖中,大家可以看到阿裡雲逐漸地增加更多的引擎,按照db-engines的統計,目前阿裡雲資料庫已經能夠覆寫70%的資料庫産品,這也是由市場所決定的。而這些産品中的部分産品已經開始走上了阿裡雲自研的道路,像之前提到的hybriddb for mysql以及polarbd等。當然,除了自研産品之外,阿裡雲也會兼顧到市場上面其他使用者的需求,也會提供像sql server、hbase、mongodb以及redis等一系列的資料庫産品,這就是阿裡雲目前的資料庫産品整體大生态。

雲資料庫産品及架構設計背後的考量

當然我們也可以看到另外一個生态模型,舉個例子就是目前很多的使用者都在使用mysql的資料庫,在mysql資料庫之下,阿裡雲會提供多種不同的資料庫形态和模式,讓使用者可以完全沉浸在mysql整體生态鍊路之中。如下圖左側所示,rds for mysql提供了基礎版、高可用版以及金融版,使得使用者可以快速地進行業務的使用,進一步在未來阿裡雲資料庫将會釋出的polardb也會率先地支援mysql的引擎,讓具有幾十tb資料或者上百tb資料的并且想要使用更加穩定的資料庫系統的大型客戶能夠非常好地解決遇到的問題。同時,很多人會認為mysql上面并不适合去做olap業務分析工作,但是如果所有的開發人員都是熟悉mysql的并且不希望跳出mysql的架構而且希望去基于mysql實作業務分析操作,這樣通過hybriddb for mysql就能夠繼續去承載這樣的業務,而且在這個系統上面還可以同時整合oltp和olap。是以,在資料庫産品的規劃過程之中,阿裡雲會充分地考慮使用者本身的感情因素,當使用者特别傾向于某一資料庫的時候,阿裡雲就會針對于這個資料庫做出一系列的産品,使得使用者可以通過統一的技術去完成所有的技術工作,而沒必要将所有的工作分散到不同的資料庫并使用不同的sql模型進行重新開發。

雲資料庫産品及架構設計背後的考量

<b>阿裡雲postgresql生态系統</b>

除了mysql生态之外,近年postgresql生态系統也是非常火熱的,阿裡雲資料庫團隊在postgresql生态上也沿用了和mysql生态中相同的思路。阿裡雲不隻是為使用者提供一個單獨的rds for postgresql的系統,因為postgresql和oracle比較相似,是以還會針對基于postgresql的增強版本——rds for pps來協助oracle使用者來進行資料遷移。同時阿裡雲也會推出針對于資料倉庫的hybriddb for postgresql來實作資料分析。而且所有的這些體系都可以通過外部表的形式去操作oss,甚至在oss上面放一份資料,各個不同的oltp、olap資料庫産品都可以對于oss上的資料進行讀寫操作和分析應用來實作整體生态鍊的運作過程。

雲資料庫産品及架構設計背後的考量

<b>四、sql+nosql+big data一站式解決資料打通</b>

除了上述提到的阿裡雲為拆分的mysql和postgresql生态鍊打造的獨特的方案之外,阿裡雲資料庫還會與阿裡雲的各種資料鍊路的軟體進行整合規劃。在下面這張圖中,大家可以看到,通過阿裡雲的dts以及cdp這樣資料工具,可以将前端的key-value的緩存層、oltp、nosql、分析以及big data進行整體資料的打通。雲上的資料可以通過比較友善的方式加上業務架構的模型開發就可以實作對于所有資料在各個資料産品之間的無縫打通,并實作了整體的資料交換。交換完資料之後就可以讓各個資料系統更大地發揮自己的業務價值。

雲資料庫産品及架構設計背後的考量

如今,資料庫其實已經是達到了百花齊放的狀态,目前有非常多的引擎以及不同的業務規劃。而阿裡雲的雲資料庫依舊秉持着這樣的幾點産品理念:阿裡雲會為使用者提供不同層級的資料庫産品,讓使用者可以實作不同的需求,不同的使用者可以購買到不同價格、可靠性以及性能的資料庫産品。阿裡雲希望通過雲平台的打通實作使用者資料庫建構的最快速的發展效率,而不希望因為架構的改變或者演變,而去等待幾周甚至一個月的規劃,而希望通過點幾下按鈕就能夠得到新的資料庫或者搭建出新的叢集,并與原有的叢集進行無縫連接配接。同時,在成本上面,因為得到了雲基礎架構的保證,使用者沒有必要自己去再搭建昂貴的光纖或者機櫃等硬體裝置,而可以直接去生産執行個體。使用者所購買的雲資料庫其實代表了很多東西,包括軟體、機器、機架以及網絡等,而這一系列的東西阿裡雲已經搭建好了,使用者可以根據自己的需求直接去購買一個月、兩個月或者一年的使用量級,而沒有必要去一次性地進行成本的支付。最後,阿裡雲希望通過自動化的部署、管理和監控,釋放dba的工作量,讓dba免于去被部署、管理等運維工作所纏繞,讓他們把更多的時間和經曆去投入到為企業進行業務優化,用技術為企業創造更多的核心生産力上面去。