深度稿 | UCloud數據庫產品演進之路
日前,“UCloud用戶開放日”***期活動順利舉行。UCloud關系型存儲研發部經理羅成對系統梳理了UCloud數據庫產品UDB的發展歷程,并闡述了貫穿其中的產品設計理念,包括產品族介紹、架構設計、未來規劃以及典型用戶案例。
UDB產品的前世今生
UDB是UCloud于2013年1月正式推出的第三款產品,***先支持的是應用最廣泛的MySQL數據庫。經過五年的發展,UDB產品線越來越豐富,目前已廣泛支持業內主流數據庫,如MySQL、MongoDB、PostgreSQL以及SQL Server,產品特性包括主從架構、高可用、數據庫專區、跨區高可用、讀寫分離、彈性擴展、備份與恢復、監控與告警等。
UDB產品非常適用于“三高”場景 —— 高性能、高可用、高并發,滿足多行業的業務需求,包括游戲、電子商務、企業服務、O2O、在線教育等。和UDB一同成長起來的客戶在上云之初就將UDB作為***。2014年,《刀塔傳奇》在AppStore排行榜連續幾個月***冠軍,部署使用UDB后,高峰時期同時在線支持超過4000個實例,還不包括從庫,整體發展非常迅速,UDB良好地支持了業務的發展。
UDB產品設計理念
UDB發展至今,貫穿其中的產品設計理念歸結起來有兩點:
◆ 用戶需求驅動
UDB整體發展都緊跟用戶的需求,不斷進行產品更新、迭代;
◆ 產品自然進化
云數據庫從字面上看是“云+數據庫”,部署在云平臺上,也會跟隨著云平臺的發展而不斷成長。
一個好的互聯網產品的定義是:通過可行的技術創造以及可持續發展的產品能力,滿足用戶需求。
UCloud一直都秉持著的信念是“用戶需求就是我們的下一個產品”,這里的需求有兩個層面:
◆ 功能性需求
對于數據庫產品來說,它核心要解決的功能性需求是數據存儲、數據訪問安全。我們的理解是,數據放在這里,它怎么去落地、訪問、讀寫、保證數據安全可靠,這是基本的功能性需求。
◆ 附加性需求
附加性需求包括穩定、容災、容量、性能、性價比、可運維等。
云數據庫產品,首先要滿足用戶的功能性需求,再一步步滿足用戶的附加性需求,這是UDB的產品設計理念。
UDB的產品演進之路
云數據庫UDB發展了好幾年,需求層次從簡單到復雜,整個產品的演進也從簡單到復雜,其背后的驅動力可從內外兩個方面來看:
◆ 外驅動力
外驅動力,是說用戶接入使用數據庫后,用戶本身的成長促使UDB產品不斷進化,以滿足其新需求。比如,前面提到的《刀塔傳奇》,使用UDB后體量迎來爆發性增長,達到一定程度之后,需求層次也發生了變化,已經不再局限于一些功能性需求,后面對一些附加性需求就越來越多了。
◆ 內驅動力
內驅動力,也就是說基礎設施在變化,給UDB提供基礎設施的是UCloud云平臺,基礎設施越來越便宜,云平臺的能力是不斷進步的。另外一方面,性能更強勁、更具性價比的計算/存儲硬件不斷面世,也促使UDB汲取硬件價值,轉移到產品上。
這些內外驅動力共同推動云數據庫的快速發展,縱觀整個UDB發展史,可以說經歷了三重境界:
云數據庫1.0可以簡單理解為“云+數據庫”,在云上部署了一個數據庫。云有按需計價、快速交付、彈性擴容、高速網絡、多可用區、虛擬化等一系列特點,而數據庫本身解決了數據的結構化存儲、標準化訪問、數據安全性等問題。可以說,云跟數據庫結合起來已能很好的滿足用戶功能性需求與部分附加性需求。
關于未來數據庫的發展,云數據庫已不再是簡單的“云+數據庫”,而是“云×數據庫”,功能更像是矩陣式進化。現在業界比較關注的AWS Aurora DB就非常典型,它是RDS發展到一定階段之后,克服了許多挑戰,不斷自我迭代,進化出的新一代產品,更好地覆蓋了用戶更高級的需求。目前來講,個人認為Aurora DB很好地代表了數據庫2.0的階段。
UDB用戶案例解析
之前說到,UDB非常適用于“三高”場景,下面結合真實案例為大家解析UDB是如何應用于這些業務場景的:
應用場景之業務持續可用
應用場景之高性能
應用場景之彈性擴容
應用場景之高性價比
◆ 應用場景之業務持續可用
我們做過一個調研:如果客戶開始使用的是單點數據庫,一旦宕機,現場更換硬件短則需要幾分鐘,長則需要幾個小時,而且這種因宕機導致業務不可用的情況,后果是非常嚴重的。
UDB則通過一個簡單、實用、可靠的基礎架構解決了上述問題,它包括一個代理節點、主數據庫、備數據庫。
這種架構的優點在于:
1) 足夠簡單,因為它的組件比較少。架構設計上,UDB一直奉行“簡單即可靠”。
2) 節點可以分布在不同的可用區,可以滿足跨可用區的容災需求。
通過主備模式,任意一個組件都有主備、熱備,因此可以做到兩層容災:DB容災和Proxy容災。下圖介紹了DB數據容災,DB容災原先VIP代理的是一個主庫,進行容災時則代理備庫,非常簡單。
另外一個是Proxy容災,進行VIP跨可用區漂移,在VPC2.0的網絡架構下,可以直接從可用區1漂到可用區2。
以金融和保險行業為例,金融行業因安保限制,需要“兩地三中心”架構。UCloud的兩地三中心解決方案首先在北京機房建一個主庫,使用跨可用區的高可用產品,同時在上海有個備庫,中間通過UDPN網絡專線打通,結合UDTS數據傳輸產品,可進行可靠的、持續的數據傳輸,這樣就能做到“兩地三中心”需求。
互聯網用戶也有“兩地三中心”的需求,將網絡UDPN打通之后,從庫能跟主庫自然進行同步。只要把主從關系建立好,網絡打通,自然就能在這3個可用區進行地域級容災能力。MongoDB的兩地容災方案更為簡單。
◆ 應用場景之高性能
使用數據庫最容易出現的瓶頸就是I/O。普通DB面對I/O密集型的應用非常被動,集中表現為DB反應慢,緊接著的并發癥是網絡延遲增高、慢查詢增多、連接數增多,雪崩效應很容易把DB打垮。
UCloud提供了一個解決方案——高性能SSD機型,底層采用PCI-e和NVMe SSD,其I/O能力吞吐量非常大。如果它對于性能要求更高,則推薦使用獨享實例,這樣可以使用整臺整機,不會跟別人產生I/O的競爭;如果要求再高,那推薦分布式數據庫UDDB,不僅容量可以擴展,性能也可以彈性擴展。典型客戶包括互聯網、游戲、電商、社交這些對于I/O要求特別高的用戶。統計數據顯示,高性能SSD UDB已經是不少用戶重要業務的***。
在單節點性能無法滿足業務需求的情況下,UCloud提供讀寫分離解決方案,完全可以做到性能成倍擴展。顧名思義,讀寫分離就是“讀”和“寫”分開,“寫”可以放在一個節點上,“讀”可以放在其他從庫上,基礎架構圖如下:
UCloud有一位做在線K歌APP的用戶從自建數據庫遷移到UCloud云平臺上,當時用戶的數據庫因業務增長迅速,遇到了性能瓶頸,使用了這套讀寫分離方案之后,其性能成倍擴展,用戶使用“1主帶5從”的架構,吞吐量可增長到6倍,不僅吞吐量上去,連接數也可以上去。因此,通過讀寫分離,業務將不再受單點連接數限制,也不再受單點容量的限制,可以平行擴展數據庫吞吐能力,連接數上去,并發能力就越來越強了。
◆ 應用場景之彈性擴容
互聯網應用有“起量很小,爆發很快”的特點。這些應用對云平臺的彈性擴容能力要求很高:首先,底層基礎架構必須具備彈性擴展能力,從應用層來講,后端無狀態的服務非常好做彈性擴展,但DB是有狀態的;其次,是存在熱點應用,也就是說整個DB都是為了這個應用在服務,就容易把整個DB拖垮。
隨著業務的不斷發展,某應用平臺后端的單點數據庫起初承受巨大的壓力。在UDB上,數據庫架構一步步從MongoDB Primary單點,到高可用副本集,再到分片集群演進,抗住了業務增長的壓力。數據量與分片個數成線性比例增加。
舉個例子,某家排行榜Top 10的社交應用APP,其業務可能達到一年30億條數據量的增長,這還是比較保守的估計。該APP希望能有一款彈性擴容,業務兼容性好且性價比優的解決方案。當時,該應用已經每天有***的數據量,查詢已經走了索引,簡單的SQL優化對其來講并不能提升太多。
UCloud推薦的解決方案是UDDB。
這個方案有幾個優勢,非常滿足這款社交應用APP的需求:
彈性擴容:應對數據增長只需添加UDB節點,將新產生的數據寫入新的節點;
靜默擴容:擴容操作100%不影響業務;
按需付費:業務上線前期,僅需購買1個節點,存儲未來3個月數據,如果業務快速增長,再添加節點,避免前期投入過大;
業務高度兼容: 客戶業務程序僅改動2條SQL。
◆ 應用場景之高性價比
有些客戶業務涉及到海量數據存儲,比如物聯網場景,部分智能終端一天的數據采集量就有幾億規模。數據采集上來需要存儲并保留較長時間(比如3個月)。在面對這種高并發、數據持續寫入的情況時,UDDB方案也能很好的滿足客戶需求。
針對類似場景,如果采用物理機自建,隱性投入很大,UCloud推薦高壓縮UDB+數據庫專區解決方案,能很好地降低數據庫成本。由于數據庫專區具有獨享性,這樣可以把整臺機器的利用率提升,專區的整機具有更大存儲空間,另外可以按時間滾動重用。同時進行DB壓縮之后,即使是普通數據盤也能滿足客戶需求,因為物聯網應用大量冷數據。***達到的效果是整個數據庫的規模壓縮比在3.2倍左右,數據量由原先150TB減少到目前52TB,總體成本節約26%。
UDB的未來展望
從UDB產品負責人的角度,對UDB未來的期待是——消除用戶對數據庫獲得和使用的門檻。現在,獲得門檻已經消除,用戶可以方便地在線購買云數據庫。
隨著UDB產品逐漸成熟和完善,用戶只需做一些編排工作,后端應用就可以直接用起來,而不必關注太多后端技術細節。但這還不夠,在云數據庫獲得門檻已基本解決的形勢下,降低使用門檻還要做很多努力。因此,今后要實現更多產品功能與特性來支持用戶業務,將用戶完全從數據庫“解放”出來。