在All in Cloud的雲計算時代,業務和應用正在不斷「雲化」,在此過程當中雲原生(Cloud Native)理念應運而生。做爲雲化改造的重要部分,雲數據庫因其天生的彈性擴展能力以及靈活、易用等特色,讓其在面對爆炸性增加的數據量和越發繁複的數據類型時表現的更加遊刃有餘。前端
面對業務及應用的「雲原生化」,數據庫技術究竟面臨了怎樣的挑戰及發展趨勢?爲此巨杉科技特別舉辦了「雲時代的數據庫架構設計與演進」深圳站活動,邀請多位數據庫領域專家帶來精彩紛呈的技術乾貨、分享實實在在的應用實踐經驗,讓現場數百位開發者收穫滿滿。數據庫
雲架構下分佈式數據庫設計實踐後端
做爲第一位分享嘉賓, 巨杉數據庫研發副總裁許建輝在主題爲「雲架構下分佈式數據庫設計實踐」的分享中表示,雲架構對數據庫的要求最早產生於應用程序的變革。「很早以前,過去的應用開發並無如此多的快速服務幫助,當時的數據開發模式如何?全部的企業應該都有平臺部,負責開發一套與全部數據庫打交道的中間件,負責與全部的數據庫讀取、存儲、前端應用等作業務方面的連接。咱們發現,在這種模式下數據庫是一個集中存儲的狀態,比較耦合。」安全
隨着互聯網業務的快速興起以及雲架構逐漸普及,進而產生了微服務應用體系。在微服務架構下,咱們看到了對數據庫訪問模式發生的變遷。據瞭解,目前業界有三種狀況,首先基於微服務並不須要作太多調整,採用集中數據庫存儲,這樣每一個微服務的數據接口訪問並不須要作不少變化,能夠達成快速適配。服務器
但相對之下也有不少不足,比方說數據集中存儲在後端數據庫中,數據的解耦合對每一個微服務都有影響,分別是數據讀取自己以及資源,畢竟數據訪問的模式有差異,需求不一樣。此外在集中存儲後,數據的彈性擴張出現問題。畢竟微服務的模式對數據擴張並不排斥,但存儲不行,不彈性沒商量;若是涉及到更換數據庫也必然會對全部微服務架構產生干擾。架構
「應對這種狀況,如今主流的玩法是每一個微服務都有一個獨立存儲,這樣開發起來比較簡單,但一樣會帶來幾方面的問題,例如每一個微服務都具有獨立數據庫存儲以後,每一個企業都會有成千上百的微服務,如何作到統一治理、統一的數據視圖很重要,固然管理成本是個須要前期考量的大問題,避免數據產生嚴重的碎片化很重要。」他總結道。併發
這種狀況須要什麼好辦法來解決?一般採用分佈式數據庫平臺。對於上層,對全部微服務體系能夠抽象出許多數據庫實例,主要用來作接口兼容與轉換。在分享中,許建輝提到,若是須要PostgreSQL,就能夠建立PostgreSQL數據庫實例,S3也是如此。對每一個實例來講,底層在一個分佈式數據庫上所承載的物理機數量,上層並不 「關心」;從數據彈性擴張上來講也徹底沒有限制。還有一點,在微服務的發展過程當中,在數據訪問方面,同一份數據的不一樣業務模型其訪問能力是有差別的。運維
目前巨杉數據庫主要面對三大業務場景,第一是聯機交易,替換傳統數據庫,例如MySQL、PostgreSQL、DB2等,能夠進行交易場景的處理,讓接口徹底兼容等;第二就是數據中臺,將每一部分業務分享出的數據進行統一管理,主要以大併發的讀寫爲主;此外局勢內容管理了,比方說數據分片能力、水平擴張以及彈性伸縮等分區操做。機器學習
談及MySQL接口的兼容,巨杉數據庫能夠百分百兼容MySQL數據庫和PostgreSQL數據庫。從兼容層面來說,首先涉及到語法的兼容,其中包括語法庫的兼容;其次是通信協議,不只能夠作到應用接口的兼容,還要保證體系工具方向,例如第三方MySQL有不少監控、管理和解析分析能力,必然要保證整個體系可使用;再次就是訪問計劃,要對訪問計劃進行兼容,其中包括統計信息的收集、訪問結構等。異步
分佈式數據庫智能運營平臺—TDSQL扁鵲的架構實現與實踐
會上,騰訊TDSQL智能運營平臺負責人趙東志也應邀來到現場,從雲數據庫以及分佈式數據庫更細化的運維場景出發並積極探索。在「分佈式數據庫智能運營平臺—TDSQL扁鵲的架構實現與實踐」中,咱們初步瞭解到,TDSQL是騰訊金融雲針對金融場景推出的高一致性分佈式數據庫,基於MySQL基礎上進行的二次開發;目前在騰訊內部涉及 到 90%的金融和交易,通常狀況下交易類型不容許丟數據,因此騰訊海量數據體制要求其具有足夠的擴展能力等。
「咱們針對數據庫雲化的痛點構建了扁鵲平臺,目的很明確,就是但願這個平臺在數據庫出現故障時能夠告訴咱們該怎麼解決;若是沒有出現故障,是否能夠經過一些有效的巡檢方式來評估 出如今數據庫中的潛在風險等。總之,有了這樣一個平臺可讓咱們將多年的運維經驗沉澱到體系中,必定程度上減緩重複勞動的消耗。」趙東志總結道。
現在數據庫確實面臨不少問題,能夠大體區分爲可用性問題、性能問題以及可靠性問題等。TDSQL做爲金融級數據庫,有高可用的配置,例如在每一個實例上都會模擬Agent,按期向DB實例中插入數據;此外切換自己對數據是無損的,但在金融場景中並不但願有過多的切換,主要是由於時間上的影響。更加常見的、用戶自身對數據庫的用法不太合理所致使的問題,一方面是InnoDB併發線程的問題,另一方面是Binlog的問題。
對此他認爲:「若是用戶有大量慢查詢,他們就會長期循環佔用工做線程,結果會致使阻塞到InnoDB。若是用戶有大量,例如併發執行100個會話,也會有問題出現;衆所周知,MySQL金融場景要求Binlog,數據寫入以前,Binlog作主備同步,至關於Binlog和InnoDB要一致,Binlog負責主備同步關係。我一直以爲任何一個數據庫沒法完美應用各類場景,都有最大的適用範圍。若是想更高效發揮數據庫的能力,就要遵照數據庫的規則。」
分佈式搜索和分析引擎—阿里雲Elasticsearch架構設計與演進
「談到Elasticsearch,你們會想到ELK,這是比較流行的組合。Elasticsearch是基於Lucene的開源分佈式搜索和分析引擎,能夠根據Logstash作數據過濾、修改和收集,其中Kibana主要用於數據展現和報表。此外作日誌分析的企業用Elasticsearch也比較多,還 有些客戶可能會去作指標數據的分析或者安全類應用的分析。」阿里巴巴搜索技術專家歐陽楚纔在「分佈式搜索和分析引擎—阿里雲Elasticsearch架構設計與演進」的主題中說。
據瞭解,Elasticsearch用Java語言開發,而使用Java語言都會遇到內存垃圾回收的問題。這樣就致使若是應用併發量特別高,每個請求都會佔用必定的內存,若是Java虛擬機處理不及時,頗有可能會致使JVM虛擬機的宕機。
2019年4月,Elasticsearch發佈7.0版本加併入了Top K排序,7.0版本後,Elasticsearch自己會監測實際請求的使用量並配置熔斷,例如查詢請求對JVM使用內存超過40%則直接中止請求等。常常在關係型數據庫中作查詢或比較耗時的請求,可能會把數據庫「拖慢」。若是能夠提早識別出這樣的請求,提早中斷,就能夠高效保證其餘請求正常運行。伴隨技術迭代與升級,在7.1版本里,Elasticsearch公司把商業版特性、安全特性開始免費,而這個特性特別有用,由於原來開源版本沒有帳號密碼和認證,這個版本後把帳號密碼安全認證功能無償使用起來。
歐陽楚才還補充道,Elasticsearch自己可從一個節點擴展到上百個節點,最開始開發自測階段能夠在本機搭建單節點集羣並完成數據的寫入和查詢,且推送到生產環境,一般會按角色拆分不一樣角色的節點,分別負責不一樣的功能模塊。更重要的是,Elasticsearch有Master節點,負責集羣元數據信息的管理、索引的分片管理;DataNode節點主要負責數據存儲和查詢;還有一個節點類型叫作客戶端節點或者協調服務器節點,負責接收用戶的查詢請求,把查詢和寫入請求分發給數據節點。
阿里雲從2017年開始與Elasticsearch合做,把Elasticsearch搬到阿里雲上提供託管式服務,針對寫入、查詢作了性能上的調優。現在,阿里雲Elasticsearch規模有超過3000個集羣,節點數超過1萬+,存儲數量超過5PB,其最重要的工做是保證數據安全。「對此咱們在外面加了一層X-pack安全認證,必須建立用戶名密碼,經過用戶名密碼實現訪問,另外還能夠配置IP段來訪問Elasticsearch服務,避免黑客攻擊。」
有時候,不少用戶本身搭建Elasticsearch時會遇到一些問題,尤爲是新手部署集羣時沒有專門配置專有主節點,致使集羣裏的節點通信出現問題等。他提出,在阿里雲上,通常推薦專門配置三個專有主節點來負責數據管理和分片管理。固然不排除有一些金融行業客戶對數據的安全要求特別高,要求多個機房上任意一個機房掉電或者光纖被挖斷的狀況下,服務均可以作到高可用。在易用性方面,阿里雲支持X-pack、監控告警、機器學習等功能。「管理Elasticsearch集羣實例比較方便,能夠自定義安裝自研或者開源的插件,也能夠用自研的分詞。阿里雲的安全團隊在Kibana上作了不少定製化開發,方便用戶使用。」
「在Elasticsearch內核方面咱們作了不少工做,支持分佈式存儲讀寫。在軟件層面,咱們團隊有工程師專門研究Elasticsearch索引分片機制,讓全部分片能夠彈性擴建或者縮容。基於Elasticsearch作的應用案例,衆安保險在今年四月份Elasticsearch發佈會上介紹過他們在阿里雲上使用Elasticsearch的經驗等。」
SequoiaDB分佈式集羣生態工具及容器化部署實戰
技術分享逐漸接近尾聲,巨杉技術社區杜蓉帶來「SequoiaDB分佈式集羣生態工具及容器化部署實戰」的演講。她提出,巨杉數據庫生態工具中,一種是管理工具,另外一種是數據備份、遷移、導入工具。支持MySQL Workbench,以及不少MySQL周邊的工具。像Workbench同樣,能夠查到它對應的表;能夠經過圖形化進行監控,也能夠經過工具對集羣的系統信息進行批量修改。
此外關於備份,分別涉及到數據庫集的備份、集羣級備份和文件系統級備份三種。所謂集羣級備份,設有集羣備份的指令,根據指令選擇全量備份仍是增量備份;此外集羣級備份的數據量比較大。複製方面,異步複製比較簡單,支持的實例比較多,能夠用MySQL、DB二、Informix、Oracle等,用自身導入處處工具;準同步複製,MySQL用本身的工具把日誌實施寫入管道中,經過ApacheStorm作標準化的修改,修改爲DML或者DDL命令。
另外,杜蓉還在現場爲開發者們列舉了三種安裝數據庫的方式:首先就是安裝包,直接安裝在機器上;其次就是經過VMWare導入虛擬機鏡像;另外就是Docker鏡像等。
一鍵直達:巨杉Tech | SequoiaDB Docker鏡像使用教程
儘管針對雲時代的數據庫架構設計與演進精彩技術分享已暫時告一段落,但關於面對業務及應用的「雲原生化」,數據庫技術究竟面臨了怎樣的挑戰及發展趨勢的系列問題探討依舊在火熱進行中,敬請繼續關注巨杉TechDay技術沙龍的後續活動。
PS:關注公衆號,發送「0721」,或按圖示操做,便可獲取PPT~