建站
咨詢
售后
建站咨詢
新聞中心
作者：phoenixxliu，騰訊 TEG 后臺開發(fā)工程師
10年的西藏網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應快，48小時及時工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整西藏建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“西藏網(wǎng)站設(shè)計”,“西藏網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
目錄：
- 導語
- 一、背景
- 二、競品分析
- 三、需求和挑戰(zhàn)
- 四、架構(gòu)和方案
- 五、總結(jié)和展望
導語
小程序云開發(fā)(Tencent CloudBase)擁有易接入、高性能、高可用等特性，其中云數(shù)據(jù)庫作為核心組件之一，可以有效降低運維成本，幫助開發(fā)者實現(xiàn)業(yè)務(wù)快速上線與迭代。本文將簡要介紹如何通過 TEG 云架構(gòu)平臺部的高性能分布式 NoSQL 數(shù)據(jù)庫，為近百萬小程序云開發(fā)用戶提供完整的原生云端數(shù)據(jù)庫能力支持。
一、背景
要理解小程序云開發(fā)，不妨將之從字面上拆解為小程序和云開發(fā)兩個部分。本節(jié)部分我們也將嘗試從這兩個方面帶大家一起簡要梳理下相關(guān)的背景知識。
1.1 云開發(fā)
從軟件工程的角度來看，軟件開發(fā)經(jīng)歷了如下三個階段：傳統(tǒng)開發(fā)-->敏捷迭代-->serverless。傳統(tǒng)的開發(fā)模式和敏捷開發(fā)模式除了需要開發(fā)者編寫核心的業(yè)務(wù)邏輯外，都不可避免地需要對后端的基礎(chǔ)設(shè)施進行管控和優(yōu)化。比如，一個應用的邏輯可以很簡單，可一旦涉及到應用的發(fā)布部署，就需要開發(fā)者花費大量精力進行服務(wù)器、數(shù)據(jù)庫、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的申請和搭建，還要考慮這些后端基礎(chǔ)設(shè)施的穩(wěn)定性、可用性和監(jiān)控指標。這一切耗時耗力又與產(chǎn)品的核心功能無關(guān)，對于需要快速開發(fā)和試錯的產(chǎn)品，傳統(tǒng)的模式開發(fā)速度慢、部署和運維成本較高。
開發(fā)趨勢
隨著 serverless 概念的火熱，越來越多的開發(fā)開始轉(zhuǎn)向 serverless 架構(gòu)發(fā)展。“serverless”并不是指后端沒有服務(wù)器，而是將后端服務(wù)器及相關(guān)運維操作變得對上層應用開發(fā)者不可見和透明。用戶無需關(guān)心后端的基礎(chǔ)設(shè)施，直接通過云 API 一鍵接入云函數(shù)、云數(shù)據(jù)庫和云存儲來獲取算力、數(shù)據(jù)庫、存儲等基礎(chǔ)的后端能力。這種隨用隨取的開發(fā)模式，不但可以讓開發(fā)者能更專注于自身的業(yè)務(wù)邏輯，還具有低成本、開發(fā)速度快以及免運維等諸多優(yōu)勢。
1.2 小程序
小程序應該不用過多介紹，相信現(xiàn)在每一個使用智能手機的人都已經(jīng)在日常生活中或多或少地使用到了各種各樣的小程序：點餐、外賣、打車、購物等等。為了嚴謹起見，還是按張小龍朋友圈的介紹給出一個簡單的定義：小程序是一種不需要下載安裝即可使用的應用，它實現(xiàn)了應用“觸手可及”的夢想，用戶掃一掃或者搜一下即可打開應用。也體現(xiàn)了“用完即走”的理念，用戶不用關(guān)心是否安裝太多應用的問題。應用將無處不在，隨時可用，但又無需安裝卸載。
自 2017 年 1 月 9 日微信發(fā)布小程序以來(十年前正好是喬布斯發(fā)布首款 iphone，有媒體解讀，這是張小龍的致敬以及野心的表現(xiàn))，小程序在這幾年的發(fā)展中已經(jīng)形成了完整的生態(tài)系統(tǒng)，用戶數(shù)和小程序數(shù)量也有了非常顯著的進步和發(fā)展，其他主流互聯(lián)網(wǎng)企業(yè)也開始紛紛布局小程序平臺，如支付寶小程序、百度小程序、抖音小程序、今日頭條小程序等等。據(jù)微信提供的數(shù)據(jù)，在 2019 年微信小程序全球交易額達到了 8000 多億，同比增長 160%，日活躍用戶超過 3 億，截至目前，微信上線的小程序超過 100 萬個，擁有超過 150 萬開發(fā)者、8200 多個第三方平臺，小程序在電商，零售行業(yè)同比去年有爆發(fā)式增長。到 2020 年微信公開課 PRO(同樣是 1 月 9 日)，全網(wǎng)的小程序數(shù)量已經(jīng)超過 450 萬?？梢哉f，我們已經(jīng)進入了一個“全民小程序”的時代。
受到今年新冠疫情的影響，由于小程序開發(fā)相較于 app 開發(fā)更加輕量和低門檻，同時也能觸達到更多的人群，各種健康碼、申報、信息核實等大部分都采用小程序的形式上線。類似的，線下實體店客流受阻，越來越多的商家和店鋪將自己的銷售轉(zhuǎn)移到線上來保證疫情期間的現(xiàn)金流，小程序同樣也是這一場景的不二選擇。
附近的小程序
越來越多樣化和越來越火爆的小程序也就意味著會有越來越多的小程序開發(fā)者入場，如何服務(wù)好這些基于小程序生態(tài)的開發(fā)者們就成為了一件必須要解決的事情。于是小程序云開發(fā)問世，可以說小程序需求 + serverless 理念 = 小程序云開發(fā)。小程序云開發(fā)以微信作為小程序前端運行的依托，同時又通過接入云函數(shù)、云數(shù)據(jù)庫和云存儲等云服務(wù)，來達到對后端基礎(chǔ)設(shè)施的“開箱即用”。這些特性可以在很大程度上解放小程序開發(fā)者的生產(chǎn)力，大大降低開發(fā)的成本和難度。
二、競品分析
事實上，互聯(lián)網(wǎng)巨頭們很早就看上了這一塊市場。以 google 為例，自從 2014 年 10 月收購 filebase，google 將自身已有的云端服務(wù)與工具一并整合進 filebase，使之成為專門為 app 開發(fā)者提供一站式的BaaS(Backend as a service，后端即服務(wù))產(chǎn)品，涵蓋了開發(fā)、質(zhì)量、分析與發(fā)展著四個主要的模塊，提供了認證、數(shù)據(jù)庫、存儲、云函數(shù)、機器學習等服務(wù)以及一系列性能和數(shù)據(jù)分析工具。
filebase-cloud filestore
如果重點看它的數(shù)據(jù)庫產(chǎn)品的話，filebase 提供了兩個選項：Cloud Filestore和實時數(shù)據(jù)庫。雖然他們都是 NoSQL 數(shù)據(jù)庫,但官方更推薦使用前者，因為它可以提供高性能、良好的可擴展性以及其他更多的高級功能。參考官網(wǎng)的介紹，cloud filestore的主要功能如下：
- 靈活性——支持靈活的分層數(shù)據(jù)結(jié)構(gòu)，文檔型;
- 富有表現(xiàn)力的查詢——支持過濾/排序等功能，自動家索引，查詢性能與結(jié)果集的大小(而不是整個數(shù)據(jù)集的大小)成比例;
- 實時更新——支持實時數(shù)據(jù)同步;
- 離線支持——緩存離線狀態(tài)的寫入、讀取、查詢，待恢復在線時，同步本地更改;
- 可擴展涉及——基礎(chǔ)架構(gòu)支持自動多區(qū)域數(shù)據(jù)復制，強大一致性保證、原子批量操作以及事務(wù)支持;
另外，filestore是支持按量收費的，可支持按數(shù)據(jù)存儲量、流量以及文檔的讀(query)，寫(insert/update)，刪除(delete)操作次數(shù)來收費。并且對外提供了多個客戶端和開發(fā)語言版本的 sdk。
其他為人熟知的 BaaS 產(chǎn)品還有Parse，最早被 Facebook 收編，但沒多久就停止了運行。目前以開源產(chǎn)品的形態(tài)運行在 github 上，需要開發(fā)者自行下載源碼并部署和維護，已經(jīng)失去了 BaaS 的意義。
類似的，國內(nèi)也有不少提供一站式后端服務(wù)(BaaS)的產(chǎn)品，包括：LeanCloud，Bmob，willddog野狗云服務(wù)、知曉云等。騰訊云推出的小程序云開發(fā)(Tencent CloudBase，TCB)也是屬于同一賽道的產(chǎn)品，即采用 serverless 架構(gòu)的一體化后端云服務(wù)。
三、需求和挑戰(zhàn)
那么，小程序云開發(fā)對于數(shù)據(jù)庫提出了哪些基本需求?又有哪些挑戰(zhàn)呢?
我們認為應該主要有以下五個方面的需求：
- 安全性：對于數(shù)據(jù)庫而言，數(shù)據(jù)安全是第一位的;
- 易用性：與小程序的特征類似，“開箱即用，用完即走”，簡單上手，免運維;
- 低成本：按量收費，精細化成本控制;
- 高性能：Nosql，支持高并發(fā)讀寫;
- 靈活性：無固定的數(shù)據(jù)庫表模式(no-schema)，支持彈性伸縮;
顯而易見，最大的挑戰(zhàn)就是如何利用已有的技術(shù)來同時滿足這五個需求并且能在它們其中達成良好的 trade-off。畢竟大多數(shù)情況下我們并不是提出了一種新的架構(gòu)，而是在多種方案和組件之間進行取舍，正如分布式系統(tǒng)里大名鼎鼎的 CAP 理論，一致性/可用性/分區(qū)容忍性你只能選擇其中的兩個。
下面將首先介紹我們所使用的架構(gòu)，然后闡述在這樣的一個架構(gòu)下有什么挑戰(zhàn)以及我們所采取的相應對的方案。(并不一定是最優(yōu)解，讀者可以帶著自己的思考來看待，我們是如何做取舍的)
四、架構(gòu)和方案
圍繞前面提到的 5 個主要需求，我們從架構(gòu)設(shè)計等方面對云開發(fā)數(shù)據(jù)庫進行了相應的改造及優(yōu)化，其架構(gòu)圖如下：
云數(shù)據(jù)庫架構(gòu)v2
最上面是小程序的接入客戶端，中間部分是接入層，底層是數(shù)據(jù)庫的存儲層。當然，還有周邊的管控、告警、備份、元數(shù)據(jù)管理等模塊。
開發(fā)者通過云開發(fā)提供的 SDK，可以在微信小程序和 qq 小程序中一鍵獲取云數(shù)據(jù)庫的登錄態(tài)，然后將數(shù)據(jù)讀寫請求發(fā)送給接入層。接入層收到用戶的讀寫請求后，由 keeper 和 agent 這兩個無狀態(tài)的模塊對接入的讀寫請求進行相關(guān)處理。其中 keeper 主要負責請求的鑒權(quán)、認證緩存，以及讀寫請求數(shù)的統(tǒng)計，是云數(shù)據(jù)庫權(quán)限校驗，負載均衡和計費功能實現(xiàn)的核心模塊。agent 模塊主要有以下幾個功能：1)維護接入層到底層數(shù)據(jù)庫實例的連接池，通過復用已建立的連接來減少請求鑒權(quán)和連接創(chuàng)建的耗時;2)統(tǒng)計請求的并發(fā)數(shù)，對讀寫請求的 QPS 進行平滑處理，避免短時間的毛刺影響數(shù)據(jù)庫性能和可用性;3)在熱遷移切換數(shù)據(jù)庫實例時，將請求掛起，切換后再將請求恢復，來實現(xiàn)熱遷移過程對用戶的全程無感知。
最后，讀寫請求通過了接入層，再接下來會到達存儲層進行數(shù)據(jù)庫實例的讀寫。鑒于本文的關(guān)注點主要集中在數(shù)據(jù)庫層面，接下來將嘗試從四個方面對其進行描述。為了避免本文篇幅過長，部分內(nèi)容并不會給出細節(jié)實現(xiàn)，只是淺析，感興趣的讀者可以留言或者找我們討論。
4.1 訪問控制
權(quán)限控制
首先，用戶只能訪問自己的數(shù)據(jù)庫，無法訪問其他用戶的數(shù)據(jù)庫，不同用戶的數(shù)據(jù)庫之間是相互隔離的，所有連接也必須認證。默認情況下，用戶是擁有數(shù)據(jù)庫的讀寫權(quán)限的，也支持在數(shù)據(jù)庫上建立多個不同權(quán)限的賬戶(比如一個只讀的賬戶)。在小程序云開發(fā)的場景下，利用微信全鏈路免鑒權(quán)的特性，用戶完全不需要太關(guān)心認證相關(guān)的問題。
訪問控制
連接數(shù)控制
其次是連接數(shù)控制方面，我們會分兩層進行控制：1)在接入層進行客戶端連接控制，根據(jù)初始化時實例類型(免費/付費等)進行不同的初始化限制，如果超過限制則提示相應的用戶;2)接入層到存儲層也有相應的連接數(shù)控制，會池化到后端數(shù)據(jù)庫所有主從節(jié)點的鏈接，避免因過多鏈接而導致的數(shù)據(jù)庫性能問題。
流量&QPS 控制
最后是機器層面的出入流量控制以及資源使用限制，原理與連接數(shù)控制類似，用戶所有的請求都會經(jīng)過接入層，因此可以在接入層控制 QPS 進而實現(xiàn)后續(xù)的按量付費功能。QPS 超過閾值后可以提示用戶或者在接入層做排隊處理。
這里有人可能會質(zhì)疑了，云開發(fā)數(shù)據(jù)庫不是彈性伸縮的嘛?為何還有 qps 的限制呢?不應該是我 qps 越來越高，后端的數(shù)據(jù)庫資源也跟著不斷擴容嘛?答：是的，默認的配置下會有一定彈性擴展空間，但是會有一個限制。當然，這里限制具體多少跟產(chǎn)品策略有關(guān)。
4.2 數(shù)據(jù)安全
數(shù)據(jù)安全是數(shù)據(jù)庫最重要的特性之一，畢竟一個存在數(shù)據(jù)丟失風險的數(shù)據(jù)庫并不能夠在激烈的市場競爭中存活下來。那么云數(shù)據(jù)庫是如何保證數(shù)據(jù)安全的呢?
數(shù)據(jù)冗余
要解決數(shù)據(jù)不丟失的問題，首先就是要避免數(shù)據(jù)庫的單點問題，也就是要有數(shù)據(jù)冗余。一般而言，工業(yè)界認為比較安全的備份數(shù)為三份。因此，云數(shù)據(jù)庫默認是三副本分布式存儲，即一份數(shù)據(jù)會存儲三份放在不同的機器上，同時機器也要分布在不同的機房中。節(jié)點區(qū)分主從狀態(tài)，主節(jié)點可以接受讀寫請求，從節(jié)點只能接受讀請求。副本集內(nèi)的存儲節(jié)點之間采用 raft-like 的副本集協(xié)議來實現(xiàn)三副本數(shù)據(jù)的最終一致性。
高可用
當機器發(fā)生故障時副本集內(nèi)的數(shù)據(jù)節(jié)點會自動切換(FailOver)，從節(jié)點變?yōu)橹鞴?jié)點繼續(xù)提供服務(wù)，從而把對業(yè)務(wù)的影響降到最低。
數(shù)據(jù)安全
備份回檔
云數(shù)據(jù)庫的備份對用戶完全透明，后臺根據(jù)數(shù)據(jù)庫的狀態(tài)自動選擇性地進行全量以及增量備份。詳細來說就是用戶的寫入越快，后臺的備份頻率也會相應增高，這樣做的目的是為了減少回檔時需要回放的數(shù)據(jù)，提升回檔性能。
支持 7 天內(nèi)任意時間回檔，可以選擇只回檔單個表，進一步減少回檔所需的時間。
另外，如果節(jié)點故障需要新加一個節(jié)點到副本集中，可選擇從備份文件中進行恢復，從而減少對源集群的侵入性。
基于冷備恢復
多可用區(qū)容災
云數(shù)據(jù)庫默認跨三機房(AZ, Availability Zone)部署，也對用戶透明，任意一個機房掛掉也不會對服務(wù)產(chǎn)生任何影響;同時也可以支持跨多地域，兩地三中心等模式。比如北京、上海、深圳各有一個節(jié)點，業(yè)務(wù)采取就近接入的方式來降低業(yè)務(wù)訪問云數(shù)據(jù)庫的時延。
兩地三中心
另外，所有到數(shù)據(jù)庫的連接必須認證以及所有數(shù)據(jù)均加密壓縮存儲，這兩點保證了數(shù)據(jù)的鏈路安全以及存儲安全。
4.3 彈性伸縮
彈性伸縮
很多時候，業(yè)務(wù)的訪問模式會呈現(xiàn)很明顯的周期性或者不均勻的特征，比如外賣類業(yè)務(wù)的高峰期出現(xiàn)在用餐時段，其他時段訪問較少;游戲類業(yè)務(wù)的高峰期出現(xiàn)在晚上或周末，上班時間較少;還有一些電商類業(yè)務(wù)的高峰期出現(xiàn)在特殊時間點(雙十一，618 等)。
周期性規(guī)律
如果按照傳統(tǒng)的數(shù)據(jù)庫運維模式，需要提前預估量級，然后運維執(zhí)行擴容，等活動結(jié)束后再縮容回來(不然成本是個問題)。那么在小程序的場景，既然要做到用戶對后端服務(wù)無感知，那么資源的擴縮容也應當不被感受到。
基于這個出發(fā)點，我們實現(xiàn)了云數(shù)據(jù)庫的彈性伸縮。依賴管控系統(tǒng)的負載監(jiān)控模塊，我們可以根據(jù)數(shù)據(jù)庫的實時負載情況動態(tài)地調(diào)整數(shù)據(jù)庫的資源，并且自動調(diào)整敏感度，從而來有效地應對數(shù)據(jù)庫負載突增的情況，在負載低的時候也可以將資源釋放提供給其他更需要的實例。其次，為了避免單個大查詢引起的頻繁調(diào)整，我們設(shè)置了滑動窗口和“去毛刺”機制，保證了彈性伸縮盡可能平滑地進行。
數(shù)據(jù)庫熱遷移
當實例狀態(tài)發(fā)生變更(比如免費-->付費，冷-->熱)的時候，可能會需要進行數(shù)據(jù)遷移，比如從性能較差的機器遷移到性能較好的機器。有了接入層的配合，我們實現(xiàn)了用戶無感知的數(shù)據(jù)庫熱遷移，可以在不停服的情況下將用戶的數(shù)據(jù)從一個數(shù)據(jù)庫無損遷移到另一個數(shù)據(jù)庫。
熱遷移
整體來看，數(shù)據(jù)庫熱遷移主要分為三個部分：
- 數(shù)據(jù)同步(Data Sync)
- 割接(Cutover)
- 狀態(tài)變更(Status Change)
第一階段，高性能數(shù)據(jù)同步的能力完全由底層數(shù)據(jù)庫提供支持，需要先同步全量數(shù)據(jù)，再同步全量階段新產(chǎn)生的操作記錄(operation log)，然后不斷循環(huán)這個過程，直到源數(shù)據(jù)庫和目標數(shù)據(jù)庫的差距非常小，實現(xiàn)方式非常類似于一個副本集內(nèi)的主從同步。在這一階段中，源數(shù)據(jù)庫是可讀可寫的。第二階段，也就是當兩邊數(shù)據(jù)庫的差距非常小時、進行熱遷移的割接過程，將源數(shù)據(jù)庫變?yōu)椴豢勺x不可寫，接入層臨時 hold 住用戶的請求，并不返回錯誤;數(shù)據(jù)同步這邊，在目標數(shù)據(jù)庫補齊了所有的操作記錄并且校驗兩邊數(shù)據(jù)完全一致之后，進行割接，其中包括用戶的拷貝及一系列元數(shù)據(jù)變更。第三階段，割接完成后，將目標集群變?yōu)榭捎脿顟B(tài)，之前由接入層 block 住的請求可以釋放并繼續(xù)執(zhí)行。由于割接的過程非常迅速(秒級)，這些請求并不會返回類似超時之類的失敗。當然這里只考慮了最一般的情況，當某個環(huán)節(jié)出現(xiàn)異常時需要考慮到相應部分的回滾和應對邏輯，涉及狀態(tài)機的變化，這相對比較復雜，在此不多贅述。
我們認為數(shù)據(jù)熱遷移要做到用戶完全無感知，主要有以下幾個難點：
- 強一致性感知集群變更;
- 高性能割接;
- 割接狀態(tài)持久化以及超時控制;
- 對于用戶請求的臨時處理;
在我們的架構(gòu)中，底層數(shù)據(jù)庫提供了高性能數(shù)據(jù)同步的基本能力;由于有接入層 agent 的存在，可以很方便地實現(xiàn) agent 之間的強一致性感知以及對于用戶請求的臨時處理(比如 block 住);引入了分布式 KV 存儲系統(tǒng) etcd 來實現(xiàn)割接狀態(tài)的持久化和超時控制，如下圖所示：
熱遷移狀態(tài)轉(zhuǎn)移圖
經(jīng)過線上環(huán)境測試，當數(shù)據(jù)庫梳理維持在 3k 左右的 QPS(100% write)時，熱遷移成功，從前端看用戶請求在遷移過程中成功率一直維持 100%，也就是做到了熱遷移對用戶的完全透明。
微信讀書每日一答
我們不妨舉個例子來說明數(shù)據(jù)庫熱遷移的應用。微信讀書業(yè)務(wù)就使用了小程序云開發(fā)，微信讀書小程序中的“每日一答”模塊完全使用云數(shù)據(jù)庫作為底層支撐。“問答 PK”，“每日一答”以及不同類別的題目都分別存儲存在不同的表中，峰值(夜間 0 點左右)QPS 接近 10k，自業(yè)務(wù)上線以來一直平穩(wěn)運行。有一段時間我們發(fā)現(xiàn)共享資源池內(nèi)的一個用戶的訪問量有明顯增大的趨勢，彈性伸縮后仍不能完全滿足其需求，為避免其對微信讀書實例產(chǎn)生影響，決定將其整個數(shù)據(jù)庫實例通過熱遷移的方式移動到我們的熱資源池中。由于數(shù)據(jù)量并不大(10G)，在短短幾分鐘之內(nèi)就完成了數(shù)據(jù)的遷移和割接(秒級)工作，整個過程對用戶完全透明，當然也沒有對微信讀書實例產(chǎn)生任何影響。
4.4 智能 DBA
智能 DBA 是一個非常大的話題，涉及各個方面，分層級來看主要包含以下三層：應用層，處理層和采集層。采集層負責從多個數(shù)據(jù)源采集需要的數(shù)據(jù)和指標;處理層對采集到的數(shù)據(jù)進行預處理和分析并產(chǎn)生相應的決策和建議;應用層則會根據(jù)不同的應用場景進行不同的處理，比如自動化運維模塊需要進行異常處理，而巡檢模塊只需要進行巡檢和告警即可。
智能DBA
自動化運維
為了進一步減少后臺側(cè)的運維操作，我們實現(xiàn)了自動化運維平臺。通過對運行時的存儲節(jié)點狀態(tài)的監(jiān)控，對每個節(jié)點進行探活及故障判斷，然后在決策中心根據(jù)故障的統(tǒng)計結(jié)果進行相應的自動化運維操作(比如磁盤只讀了則強制切主)同時也會告警給運維人員，確保自動化運維結(jié)果正確。
自動化運維平臺
對于一部分自動化運維沒辦法覆蓋的問題，我們有各個層面和維度(機器、實例、節(jié)點等)全套的秒級監(jiān)控，各項指標共計69+項，后端可以實時感知到數(shù)據(jù)庫的狀態(tài);發(fā)現(xiàn)問題盡早處理。
索引優(yōu)化
索引是數(shù)據(jù)庫中非常重要的概念，用于加速數(shù)據(jù)庫的查找。在小程序的場景下，我們希望將用戶對于后端的數(shù)據(jù)庫的認知降低到越少越好。于是實現(xiàn)了一系列查詢優(yōu)化的功能，比如自動建索引。當我們的接入層和存儲層發(fā)現(xiàn)用戶有很多查詢到后端都是全表掃描時，就會根據(jù)用戶的 query 具體字段進行對應索引的添加工作。等到索引建立完成，用戶就可以直接享受優(yōu)化后的查詢結(jié)果。重要的是，這一過程用戶同樣也是無感知的。
我們認為自動建索引要做到用戶完全無感知需要考慮以下幾個主要問題：
- 同步 VS.異步?建索引過程應該是異步的，否則將會阻塞用戶的正常請求。
- 如何控制建索引的風險?主要分為兩個方向：1)首先需要控制自動建索引的頻率。建索引是 cpu 消耗型任務(wù)，如果數(shù)據(jù)庫一直處于建索引的過程中很明顯是不可接受的;2)其次需要控制自動建索引的數(shù)量，使之在一個相對合理的范圍。對于一般的表不會有問題，但是如果數(shù)據(jù)庫中的某個表包含多個字段，且用戶會根據(jù)這些字段進行不同的查詢，那么不加限制的索引會導致索引數(shù)量特別多，嚴重影響用戶的更新效率(因為更新時除了會更新數(shù)據(jù)外還會更新相應的索引)。
- 索引該如何實現(xiàn)動態(tài)更新?用戶的查詢并不是一成不變的，伴隨的業(yè)務(wù)的發(fā)展或者變換，對于同一個表的查詢很有可能也會發(fā)生變化。那么之前自動建立的索引也需要自動刪除，否則長期下去將成為數(shù)據(jù)庫的負擔和瓶頸。需要根據(jù)用戶查詢條件的變化來動態(tài)更新已有的索引。這里關(guān)于索引的最左匹配原則也值得考慮進來。
- 如何做到對用戶透明?不僅僅是建索引時不影響用戶的正常請求，而且需要讓用戶能直接感受到查詢走索引的速度。當表內(nèi)數(shù)據(jù)量比較大時，一次索引的變更操作(比如復合索引字段順序的變化)可能會導致用戶的同樣一條查詢存在顯著的耗時差距，除了向用戶解釋外，我們也可以考慮將索引的變更做得更平滑一些，并提供一系列的查詢優(yōu)化建議。這樣可以幫助用戶更好地使用數(shù)據(jù)庫。
自動建索引功能上線后，數(shù)據(jù)庫實例的請求平均耗時大幅下降，整個小程序云開發(fā)數(shù)據(jù)庫的大盤的平均耗時也減少了50%以上，如下圖所示。
自動加索引上線后的效果
誠然，自動建索引還有一定的局限性，比如使用不等于和正則匹配等復雜查詢方式時。此時就需要其他方式來處理，比如前臺提示用戶應該如何優(yōu)化查詢語句;或者根據(jù)云數(shù)據(jù)庫提供的慢日志分析工具來分析慢日志并針對性地給出解決方案。
五、總結(jié)和展望
小程序云開發(fā)可以大大解放小程序開發(fā)者的生產(chǎn)力，降低開發(fā)的成本和難度。其中，云數(shù)據(jù)庫扮演了舉足輕重的角色。針對小程序云開發(fā)對云數(shù)據(jù)庫提出的 5 大需求：安全性、易用性、低成本、高性能、靈活性，我們從數(shù)據(jù)庫架構(gòu)設(shè)計等方面做了諸多改造和優(yōu)化，使得云數(shù)據(jù)庫可以更加貼合小程序的使用場景。
面向未來，在云數(shù)據(jù)庫的管控層我們也將提供更加細粒度的監(jiān)控(當然，是給我們自己看的，用戶無需關(guān)注)，更智能的 DBA 和更高效的彈性伸縮能力(比如基于 k8s 的云數(shù)據(jù)庫);在云數(shù)據(jù)庫的內(nèi)核層，我們將封裝更多的底層存儲引擎能力暴露給 API 層，并深度結(jié)合小程序的使用場景來進行定制化開發(fā)(比如調(diào)研發(fā)現(xiàn)很多小程序是答題相關(guān)的，那么我們可以提供更優(yōu)的中文文本索引能力)，進一步提升事務(wù)的性能等。
我們有理由相信，云開發(fā)數(shù)據(jù)庫將在 serverless 理念的指導下不斷完善自己，和小程序一起發(fā)展得越來越好。
參考資料
- Filebase
- Filebase pricing
- Cloud Filestore
- Introducing Cloud Filestore
- rtdv-vs-filestore
- Parse
- LeanCloud
- Bmob
- 知曉云
- Tencent CloudBase
新聞標題：解密小程序云開發(fā)數(shù)據(jù)庫
本文鏈接：http://fisionsoft.com.cn/article/djedidd.html
