阿里的nosql,阿里的價(jià)值觀

阿里巴巴算法工程師需要掌握什么技能

1、熟悉Java，有大訪問量系統(tǒng)開發(fā)經(jīng)驗(yàn)；

成都創(chuàng)新互聯(lián)公司網(wǎng)站設(shè)計(jì)，為客戶量身定制各類網(wǎng)站建設(shè)業(yè)務(wù)，包括企業(yè)型、電子商務(wù)型、響應(yīng)式網(wǎng)站、行業(yè)門戶型等各類網(wǎng)站，實(shí)戰(zhàn)經(jīng)驗(yàn)豐富，成功案例眾多。以客戶利益為出發(fā)點(diǎn)，成都創(chuàng)新互聯(lián)公司網(wǎng)站制作為客戶規(guī)劃、定制網(wǎng)站開發(fā)符合企業(yè)需求、帶有營(yíng)銷價(jià)值的網(wǎng)絡(luò)建站方案認(rèn)真對(duì)待每一個(gè)客戶，我們不用口頭的語(yǔ)言來吹擂我們的優(yōu)秀，數(shù)千家的成功案例見證著我們的成長(zhǎng)。

2、熟練使用Spring、Mybatis等開源框架，熱愛開源技術(shù)；

3、熟悉Linux，熟悉MySQL或其他數(shù)據(jù)庫(kù)并了解SQL優(yōu)化，對(duì)NoSQL、消息隊(duì)列等有深入的理解；

4、熟悉TCP/IP、HTTP等網(wǎng)絡(luò)協(xié)議；

5、對(duì)Elasticsearch、Drools、Dubbo、JVM、服務(wù)治理等技術(shù)

6、熟練mvc的設(shè)計(jì)和開發(fā)工作，熟悉2種以上的php開發(fā)框架，如zend，yii，laravel，熟悉laravel 優(yōu)先；

7、熟悉PHP+MySQL開發(fā)和維護(hù)，熟悉LAMP／LNMP環(huán)境下的開發(fā)工作

8、熟悉laravel框架，了解php composer優(yōu)先考慮；

9、熟悉前端開發(fā)技術(shù)，如html5、css3、javascript等；

10、熟悉rest 。

阿里IM技術(shù)分享(六)：閑魚億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化

本文由阿里閑魚技術(shù)團(tuán)隊(duì)逸昂分享，原題“消息鏈路優(yōu)化之弱感知鏈路優(yōu)化”，有修訂和改動(dòng)，感謝作者的分享。

閑魚的IM消息系統(tǒng)作為買家與賣家的溝通工具，增進(jìn)理解、促進(jìn)信任，對(duì)閑魚的商品成交有重要的價(jià)值，是提升用戶體驗(yàn)最關(guān)鍵的環(huán)節(jié)。

然而，隨著業(yè)務(wù)體量的快速增長(zhǎng)，當(dāng)前這套消息系統(tǒng)正面臨著諸多急待解決的問題。

以下幾個(gè)問題典型最為典型：

1） 在線消息的體驗(yàn)提升；

2） 離線推送的到達(dá)率；

3） 消息玩法與消息底層系統(tǒng)的耦合過強(qiáng)。

經(jīng)過評(píng)估，我們認(rèn)為現(xiàn)階段離線推送的到達(dá)率問題最為關(guān)鍵，對(duì)用戶體驗(yàn)影響較大。

本文將要分享的是閑魚IM消息在解決離線推送的到達(dá)率方面的技術(shù)實(shí)踐，內(nèi)容包括問題分析和技術(shù)優(yōu)化思路等 ，希望能帶給你啟發(fā)。

（本文已同步發(fā)布于： ?）

本文是系列文章的第6篇，總目錄如下：

《 阿里IM技術(shù)分享(一)：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過人之處 》

《 阿里IM技術(shù)分享(二)：閑魚IM基于Flutter的移動(dòng)端跨端改造實(shí)踐 》

《 阿里IM技術(shù)分享(三)：閑魚億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路 》

《 阿里IM技術(shù)分享(四)：閑魚億級(jí)IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐 》

《 阿里IM技術(shù)分享(五)：閑魚億級(jí)IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐 》

《 阿里IM技術(shù)分享(六)：閑魚億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化 》（* 本文）

從數(shù)據(jù)通信鏈接的技術(shù)角度，我們根據(jù)閑魚客戶端是否在線，將整體消息鏈路大致分為強(qiáng)感知鏈路和弱感知鏈路。

強(qiáng)感知鏈路由以下子系統(tǒng)或模塊：

1） 發(fā)送方客戶端；

2） idleapi-message（閑魚的消息網(wǎng)關(guān)）；

3） heracles（閑魚的消息底層服務(wù)）；

4） accs（阿里自研的長(zhǎng)連接通道）；

5） 接收方客戶端組成。

整條鏈路的核心指標(biāo)在于端到端延遲和消息到達(dá)率。

強(qiáng)感知鏈路中的雙方都是在線的，消息到達(dá)客戶端就可以保證接收方感知到。強(qiáng)感知鏈路的主要痛點(diǎn)在消息的端到端延遲。

弱感知鏈路與強(qiáng)感知鏈路的主要不同在于： 弱感知鏈路的接收方是離線的，需要依賴離線推送這樣的方式送達(dá)。

因此弱感知鏈路的用戶感知度不強(qiáng)，其核心指標(biāo)在于消息的到達(dá)率，而非延遲。

所以當(dāng)前階段，優(yōu)化弱感知鏈路的重點(diǎn)也就是提升離線消息的到達(dá)率。換句話說， 提升離線消息到達(dá)率問題，也就是優(yōu)化弱感知鏈路本身 。

下圖一張整個(gè)IM消息系統(tǒng)的架構(gòu)圖，感受下整體鏈路：

如上圖所示，各主要組件和子系統(tǒng)分工如下：

1） HSF是一個(gè)遠(yuǎn)程服務(wù)框架，是dubbo的內(nèi)部版本；

2） tair是阿里自研的分布式緩存框架，支持 memcached、Redis、LevelDB 等不同存儲(chǔ)引擎；

3） agoo是阿里的離線推送中臺(tái)，負(fù)責(zé)整合不同廠商的離線推送通道，向集團(tuán)用戶提供一個(gè)統(tǒng)一的離線推送服務(wù)；

4） accs是阿里自研的長(zhǎng)連接通道，為客戶端、服務(wù)端的實(shí)時(shí)雙向交互提供便利；

5） lindorm是阿里自研的NoSQL產(chǎn)品，與HBase有異曲同工之妙；

6） 域環(huán)是閑魚消息優(yōu)化性能的核心結(jié)構(gòu)，用來存儲(chǔ)用戶最新的若干條消息。

強(qiáng)感知鏈路和弱感知鏈路在通道選擇上是不同的：

1） 強(qiáng)感知鏈路使用accs這個(gè)在線通道；

2） 弱感知鏈路使用agoo這個(gè)離線通道。

通俗了說，弱感知鏈路指的就是離線消息推送系統(tǒng)。

相比較于在線消息和端內(nèi)推送（也就是上面說的強(qiáng)感知鏈路），離線推送難以確保被用戶感知到。

典型的情況包括：

1） 未發(fā)送到用戶設(shè)備：即推送未送達(dá)用戶設(shè)備，這種情況可以從通道的返回分析；

2） 發(fā)送到用戶設(shè)備但沒有展示到系統(tǒng)通知欄：閑魚曾遇到通道返回成功，但是用戶未看到推送的案例；

3） 展示到通知欄，并被系統(tǒng)折疊：不同安卓廠商對(duì)推送的折疊策略不同，被折疊后，需用戶主動(dòng)展開才能看到內(nèi)容，觸達(dá)效果明顯變差；

4） 展示到通知欄，并被用戶忽略：離線推送的點(diǎn)擊率相比于在線推送更低。

針對(duì)“1）未發(fā)送到用戶設(shè)備”，原因有：

1） 離線通道的token失效；

2） 參數(shù)錯(cuò)誤；

3） 用戶關(guān)閉應(yīng)用通知；

4） 用戶已卸載等。

針對(duì)“3）展示到通知欄，并被系統(tǒng)折疊”，原因有：

1） 通知的點(diǎn)擊率；

2） 應(yīng)用在廠商處的權(quán)重；

3） 推送的數(shù)量等。

針對(duì)“4）展示到通知欄，并被用戶忽略”，原因有：

1） 用戶不愿意查看推送；

2） 用戶看到了推送，但是對(duì)內(nèi)容不感興趣；

3） 用戶在忙別的事，無暇處理。

總之： 以上這些離線消息推送場(chǎng)景，對(duì)于用戶來說感知度不高，我們也便稱之為弱感知鏈路。

我們的弱感知鏈路分為3部分，即：

1） 系統(tǒng)；

2） 通道；

3） 用戶。

共包含了Hermes、agoo、廠商、設(shè)備、用戶、承接頁(yè)這幾個(gè)環(huán)節(jié)。具體如下圖所示。

從推送的產(chǎn)生到用戶最終進(jìn)入APP，共分為如下幾個(gè)步驟：

步驟1 ：Hermes是閑魚的用戶觸達(dá)系統(tǒng)，負(fù)責(zé)人群管理、內(nèi)容管理、時(shí)機(jī)把控，是整個(gè)弱感知鏈路的起點(diǎn)。；

步驟2 ：agoo是阿里內(nèi)部承接離線推送的中臺(tái)，是閑魚離線推送能力的基礎(chǔ)；

步驟3 ：agoo實(shí)現(xiàn)離線推送依靠的是廠商的推送通道（如：蘋果的 apns通道 、Google的fcm通道、及 國(guó)內(nèi)各廠商的自建通道 。；

步驟4 ：通過廠商的通道，推送最終出現(xiàn)在用戶的設(shè)備上，這是用戶能感知到推送的前提條件；

步驟5 ：如果用戶剛巧看到這條推送，推送的內(nèi)容也很有趣，在用戶的主動(dòng)點(diǎn)擊下會(huì)喚起APP，打開承接頁(yè)，進(jìn)而給用戶展示個(gè)性化的商品。

經(jīng)過以上5個(gè)步驟，至此弱感知鏈路就完成了使命。

弱感知鏈路的核心問題在于：

1） 推送的消息是否投遞給了用戶；

2） 已投遞到的消息用戶是否有感知。

這對(duì)應(yīng)推送的兩個(gè)階段：

1） 推送消息是否已到達(dá)設(shè)備；

2） 用戶是否查看推送并點(diǎn)擊。

其中： 到達(dá)設(shè)備這個(gè)階段是最基礎(chǔ)的，也是本次優(yōu)化的核心。

我們可以將每一步的消息處理量依次平鋪，展開為一張漏斗圖，從而直觀的查看鏈路的瓶頸。

漏斗圖斜率最大的地方是優(yōu)化的重點(diǎn)，差異小的地方不需要優(yōu)化：

通過分析以上漏斗圖，弱感知鏈路的優(yōu)化重點(diǎn)在三個(gè)方面：

1） agoo受理率：是指我們發(fā)送推送請(qǐng)到的數(shù)量到可以通過agoo（阿里承接離線推送的中臺(tái)）轉(zhuǎn)發(fā)到廠商通道的數(shù)量之間的漏斗；

2） 廠商受理率：是指agoo中臺(tái)受理的量到廠商返回成功的量之間的漏斗；

3） Push點(diǎn)擊率：也就通過以上通道最終已送到到用戶終端的消息，是否最終轉(zhuǎn)化為用戶的主動(dòng)“點(diǎn)擊”。

有了優(yōu)化方向，我們來看看優(yōu)化手段吧。

跟隨推送的視角，順著鏈路看一下我們是如何進(jìn)行優(yōu)化的。

用戶的推送，從 Hermes 站點(diǎn)搭乘“班車”，駛向下一站：? agoo 。

這是推送經(jīng)歷的第一站。到站一看，傻眼了，只有不到一半的推送到站下車了。這是咋回事嘞？

這就要先說說 agoo 了，調(diào)用 agoo 有兩種方式：

1） 指定設(shè)備和客戶端，agoo直接將推送投遞到相應(yīng)的設(shè)備；

2） 指定用戶和客戶端，agoo根據(jù)內(nèi)部的轉(zhuǎn)換表，找到用戶對(duì)應(yīng)的設(shè)備，再進(jìn)行投遞。

我們的系統(tǒng)不保存用戶的設(shè)備信息。因此，是按照用戶來調(diào)用agoo的。

同時(shí)： 由于沒有用戶的設(shè)備信息，并不知道用戶是 iOS 客戶端還是 Android 客戶端。工程側(cè)不得不向 iOS 和 Android 都發(fā)送一遍推送。雖然保證了到達(dá)，但是，一半的調(diào)用都是無效的。

為了解這個(gè)問題： 我們使用了agoo的設(shè)備信息。將用戶轉(zhuǎn)換設(shè)備這一階段提前到了調(diào)用 agoo 之前，先明確用戶對(duì)應(yīng)的設(shè)備，再指定設(shè)備調(diào)用 agoo，從而避免無效調(diào)用。

agoo調(diào)用方式優(yōu)化后，立刻剔除了無效調(diào)用，agoo受理率有了明顯提升。

至此： 我們總算能對(duì) agoo 受理失敗的真正原因做一個(gè)高大上的分析了。

根據(jù)統(tǒng)計(jì)： 推送被 agoo 拒絕的主要原因是——用戶關(guān)閉了通知權(quán)限。同時(shí)，我們對(duì) agoo 調(diào)用數(shù)據(jù)的進(jìn)一步分析發(fā)現(xiàn)——有部分用戶找不到對(duì)應(yīng)的設(shè)備。 優(yōu)化到此，我們猛然發(fā)現(xiàn)多了兩個(gè)問題。

那就繼續(xù)優(yōu)化唄：

1） 通知體驗(yàn)優(yōu)化，引導(dǎo)打開通知權(quán)限；

2） 與agoo共建設(shè)備庫(kù)，解決設(shè)備轉(zhuǎn)換失敗的問題。

這兩個(gè)優(yōu)化方向又是一片新天地，我們擇日再聊。

推送到達(dá) agoo ，分機(jī)型搭乘廠商“專列”，駛向下一站：用戶設(shè)備。

這是推送經(jīng)歷的第二站。出站查票，發(fā)現(xiàn)竟然超員了。

于是乎： 我們每天有大量推送因?yàn)槌^廠商設(shè)定的限額被攔截。

為什么會(huì)這樣呢？

實(shí)際上： 提供推送通道的廠商（沒錯(cuò)， 各手機(jī)廠商的自家推送通道良莠不齊 ），為了保證用戶體驗(yàn)，會(huì)對(duì)每個(gè)應(yīng)用能夠推送的消息總量進(jìn)行限制。

對(duì)于廠商而言，這個(gè)限制會(huì)根據(jù)推送的類型和應(yīng)用的用戶規(guī)模設(shè)定——推送主要分為產(chǎn)品類的推送和營(yíng)銷類的推送。

廠商推送通道對(duì)于不同類型消息的限制是：

1） 對(duì)于產(chǎn)品類推送，廠商會(huì)保證到達(dá)；

2） 對(duì)于營(yíng)銷類推送，廠商會(huì)進(jìn)行額度限制；

3） 未標(biāo)記的推送，默認(rèn)作為營(yíng)銷類推送對(duì)待。

我們剛好沒有對(duì)推送進(jìn)行標(biāo)記，因此觸發(fā)了廠商的推送限制。

這對(duì)我們的用戶來說，會(huì)帶來困擾。閑魚的交易，很依賴買賣家之間的消息互動(dòng)。這部分消息是需要確保到達(dá)的。

同樣： 訂單類的消息、用戶的關(guān)注，也需要保證推送給用戶。

根據(jù)主流廠商的接口協(xié)議，我們將推送的消息分為以下幾類，并進(jìn)行相應(yīng)標(biāo)記：

1） 即時(shí)通訊消息；

2） 訂單狀態(tài)變化；

3） 用戶關(guān)注內(nèi)容；

4） 營(yíng)銷消息這幾類。

同時(shí)，在業(yè)務(wù)上，我們也進(jìn)行了推送的治理——將用戶關(guān)注度不高的消息，取消推送，避免打擾。

經(jīng)過這些優(yōu)化，因?yàn)槌^廠商限額而被攔截的推送實(shí)現(xiàn)了清零。

通過優(yōu)化agoo受理率、廠商受理率，我們解決了推送到達(dá)量的瓶頸。但即使消息被最終送達(dá)，用戶到底點(diǎn)擊了沒有？這才是消息推送的根本意義所在。

于是，在日常的開發(fā)測(cè)試過程中，我們發(fā)現(xiàn)了推送的兩個(gè)體驗(yàn)問題：

1） 用戶點(diǎn)擊Push有開屏廣告；

2） 營(yíng)銷Push也有權(quán)限校驗(yàn)，更換用戶登陸后無法點(diǎn)擊。

對(duì)于開屏廣告功能，我們?cè)黾恿薖ush點(diǎn)擊跳過廣告的能力。

針對(duì)Push的權(quán)限校驗(yàn)功能，閑魚根據(jù)場(chǎng)景做了細(xì)分：

1） 涉及個(gè)人隱私的推送，保持權(quán)限校驗(yàn)不變；

2） 營(yíng)銷類的推送，放開權(quán)限校驗(yàn)。

以上是點(diǎn)擊體驗(yàn)的優(yōu)化，我們還需要考慮用戶的點(diǎn)擊意愿。

用戶點(diǎn)擊量與推送的曝光量、推送素材的有趣程度相關(guān)。推送的曝光量又和推送的到達(dá)量、推送的到達(dá)時(shí)機(jī)有關(guān)。

具體的優(yōu)化手段是：

1） 在推送內(nèi)容上：我們需要優(yōu)化的是推送的時(shí)機(jī)和相應(yīng)的素材；

2） 在推送時(shí)機(jī)上：算法會(huì)根據(jù)用戶的偏好和個(gè)性化行為數(shù)據(jù)，計(jì)算每個(gè)用戶的個(gè)性化推送時(shí)間，在用戶空閑的時(shí)間推送（避免在不合適的時(shí)間打擾用戶，同時(shí)也能提升用戶看到推送的可能性）。

3） 在推送素材上：算法會(huì)根據(jù)素材的實(shí)時(shí)點(diǎn)擊反饋，對(duì)素材做實(shí)時(shí)賽馬。只發(fā)用戶感興趣的素材，提高用戶點(diǎn)擊意愿。

通過以上我們的分析和技術(shù)優(yōu)化手段，整體弱推送鏈路鏈路有了不錯(cuò)的提升，離線消息的到達(dá)率相對(duì)提升了兩位數(shù)。

本篇主要和大家聊的是只是IM消息系統(tǒng)鏈路中的一環(huán)——弱感知鏈路的優(yōu)化，落地到到具體的業(yè)務(wù)也就是離線消息送達(dá)率問題。

整體IM消息系統(tǒng)，還是一個(gè)比較復(fù)雜的領(lǐng)域。

我們?cè)谙⑾到y(tǒng)的發(fā)展過程中，面臨著如下問題：

1） 如何進(jìn)行消息的鏈路追蹤；

2） 如何保證IM消息的快速到達(dá)（見《 閑魚億級(jí)IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐 》)；

3） 如何將消息的玩法和底層能力分離；

4） 離線推送中如何通過用戶找到對(duì)應(yīng)的設(shè)備。

這些問題，我們?cè)谝郧暗奈恼轮杏兴窒?，以后也?huì)陸續(xù)分享更多，敬請(qǐng)期待。

[1]? Android P正式版即將到來：后臺(tái)應(yīng)用?；睢⑾⑼扑偷恼嬲瑝?mèng)

[2]? 一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐

[3]? 一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等

[4]? 一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等

[5]? 從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)

[6]? 企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等

[7]? 融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制

[8]? 移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？

[9]? 現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討

[10]? 新手入門一篇就夠：從零開發(fā)移動(dòng)端IM

[11]? 移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”

[12]? 移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)

[13]? IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞

[14]? IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞

[15]? 零基礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)？

[16]? 零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？

[17]? 零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？

[18]? 零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？

（本文已同步發(fā)布于： ?）

你覺得數(shù)據(jù)庫(kù)這個(gè)課怎么樣？

普通。就是學(xué)習(xí)數(shù)據(jù)庫(kù)的操作而已。讀取,編輯,刪除這三種操作邏輯。只要記憶力好,把那幾種命令語(yǔ)句背下來,基本的操作就沒問題。這對(duì)今后的其他課程尤其是編程是有幫助的,因?yàn)橛行┸浖?huì)設(shè)計(jì)到數(shù)據(jù)庫(kù)的讀寫操作。尤其是一些網(wǎng)站,肯定會(huì)連接數(shù)據(jù)庫(kù)。不會(huì)數(shù)據(jù)庫(kù)操作,就沒辦法制作動(dòng)態(tài)網(wǎng)站。

阿里云分布式數(shù)據(jù)庫(kù)服務(wù)DRDS？誰(shuí)使用過 簡(jiǎn)單講講！

淘寶開源的TDDL和cobar的結(jié)合，放到了阿里云上就是DRDS，是商品，服務(wù)，可以購(gòu)買使用的?？梢栽诎⒗镌乒倬W(wǎng)上注冊(cè)免費(fèi)試用。

=====================================================

隨著互聯(lián)網(wǎng)時(shí)代的到來，計(jì)算機(jī)要管理的數(shù)據(jù)量呈指數(shù)級(jí)別地飛速上漲，而我們卻完全無法對(duì)用戶數(shù)做出準(zhǔn)確預(yù)估。我們的系統(tǒng)所需要支持的用戶數(shù)，很可能在短短的一個(gè)月內(nèi)突然爆發(fā)式地增長(zhǎng)幾千倍，數(shù)據(jù)也很可能快速地從原來的幾百GB飛速上漲到了幾百個(gè)TB。如果在這爆發(fā)的關(guān)鍵時(shí)刻，系統(tǒng)不穩(wěn)定或無法訪問，那么對(duì)于業(yè)務(wù)將會(huì)是毀滅性的打擊。

伴隨著這種對(duì)于系統(tǒng)性能、成本以及擴(kuò)展性的新需要，以HBase、MongoDB為代表的NoSQL數(shù)據(jù)庫(kù)和以阿里DRDS、VoltDB、ScaleBase為代表的分布式NewSQL數(shù)據(jù)庫(kù)如雨后春筍般不斷涌現(xiàn)出來。

本文將會(huì)介紹阿里DRDS的技術(shù)理念、發(fā)展歷程、技術(shù)特性等內(nèi)容。

DRDS設(shè)計(jì)理念

從20世紀(jì)70年代關(guān)系數(shù)據(jù)庫(kù)創(chuàng)立開始，其實(shí)大家在數(shù)據(jù)庫(kù)上的追求就從未發(fā)生過變化：更快的存取數(shù)據(jù)，可以按需擴(kuò)縮以承載更大的訪問量和更大的數(shù)據(jù)量，開發(fā)容易，硬件成本低，我們可以把這叫做數(shù)據(jù)庫(kù)領(lǐng)域的圣杯。

為了支撐更大的訪問量和數(shù)據(jù)量，我們必然需要分布式數(shù)據(jù)庫(kù)系統(tǒng)，然而分布式系統(tǒng)又必然會(huì)面對(duì)強(qiáng)一致性所帶來的延遲提高的問題，因?yàn)榫W(wǎng)絡(luò)通信本身比單機(jī)內(nèi)通信代價(jià)高很多，這種通信的代價(jià)就會(huì)直接增加系統(tǒng)單次提交的延遲。延遲提高會(huì)導(dǎo)致數(shù)據(jù)庫(kù)鎖持有時(shí)間變長(zhǎng)，使得高沖突條件下分布式事務(wù)的性能不升反降（這個(gè)具體可以了解一下Amdahl定律），甚至性能距離單機(jī)數(shù)據(jù)庫(kù)都還有明顯的差距。

從上面的說明，我們可以發(fā)現(xiàn)，問題的關(guān)鍵并不是分布式事務(wù)做不出來，而是做出來了卻因?yàn)樾阅芴疃鴽]有什么卵用。數(shù)據(jù)庫(kù)領(lǐng)域的高手們努力了40年，但至今仍然沒有人能夠很好地解決這個(gè)問題，Google Spanner的開發(fā)負(fù)責(zé)人就經(jīng)常在他的Blog上談?wù)撗舆t的問題，相信也是飽受這個(gè)問題的困擾。

面對(duì)這個(gè)難題，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)選擇了放棄分布式的方案，因?yàn)樵?0世紀(jì)70~80年代，我們的數(shù)據(jù)庫(kù)主要被用來處理企業(yè)內(nèi)的各類數(shù)據(jù)，面對(duì)的用戶不過幾千人，而數(shù)據(jù)量最多也就是TB級(jí)別。用單臺(tái)機(jī)器來處理事務(wù)，用個(gè)磁盤陣列處理一下磁盤容量不夠的問題，基本上就能解決一切問題了。

然而，信息化和互聯(lián)網(wǎng)的浪潮改變了這一切，我們突然發(fā)現(xiàn)，我們服務(wù)的對(duì)象發(fā)生了根本性變化，從原來的幾千人，變成了現(xiàn)在的幾億人，數(shù)據(jù)量也從TB級(jí)別到了PB級(jí)別甚至更多。存在單點(diǎn)的單機(jī)系統(tǒng)無論如何努力，都會(huì)面對(duì)系統(tǒng)處理能力的天花板。原來的這條路，看起來是走不下去了，我們必須想辦法換一條路來走。

可是，分布式數(shù)據(jù)庫(kù)所面對(duì)的強(qiáng)一致性難題卻像一座高山，人們努力了無數(shù)個(gè)日日夜夜，但能翻越這座山的日子看來仍然遙遙無期。

于是，有一群人認(rèn)為，強(qiáng)一致性這件事看來不怎么靠譜，那徹底繞開這個(gè)問題是不是個(gè)更好的選擇？他們發(fā)現(xiàn)確實(shí)有那么一些場(chǎng)景是不需要強(qiáng)一致事務(wù)的，甚至連SQL都可以不要，最典型的就是日志流水的記錄與分析這類場(chǎng)景。而去掉了事務(wù)和SQL，接口簡(jiǎn)單了，性能就更容易得到提升，擴(kuò)展性也更容易實(shí)現(xiàn)，這就是NoSQL系統(tǒng)的起源。

雖然NoSQL解決了性能和擴(kuò)展性問題，但這種繞開問題的方法給用戶帶來了很多困擾，系統(tǒng)的開發(fā)成本也大大提升。這時(shí)候就有另外一群人，他們覺得用戶需要SQL，覺得用戶也需要事務(wù)，問題的關(guān)鍵在于我們要努力地往圣杯的方向不斷前進(jìn)。在保持系統(tǒng)的擴(kuò)展性和性能的前提下，付出盡可能小的代價(jià)來滿足業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的需要。這就是NewSQL這個(gè)理念的由來。

DRDS也是一個(gè)NewSQL的系統(tǒng)，它與ScaleBase、VoltDB等系統(tǒng)類似，都希望能夠找到一條既能保持系統(tǒng)的高擴(kuò)展性和高性能，又能盡可能保持傳統(tǒng)數(shù)據(jù)庫(kù)的ACID事務(wù)和SQL特性的分布式數(shù)據(jù)庫(kù)系統(tǒng)。

DRDS發(fā)展歷程

在一開始，TDDL的主要功能就是做數(shù)據(jù)庫(kù)切分，一個(gè)或一組SQL請(qǐng)求提交到TDDL，TDDL進(jìn)行規(guī)則運(yùn)算后得知SQL應(yīng)該被分發(fā)到哪個(gè)機(jī)器，直接將SQL轉(zhuǎn)發(fā)到對(duì)應(yīng)機(jī)器即可（如圖1）。

圖1 TDDL數(shù)據(jù)庫(kù)切分

開始的時(shí)候，這種簡(jiǎn)單的路由策略能夠滿足用戶的需要，我們開始的那些應(yīng)用，就是通過這樣非常簡(jiǎn)單的方式完成了他所有的應(yīng)用請(qǐng)求。我們也認(rèn)為，這種方案簡(jiǎn)單可靠，已經(jīng)足夠好用了。

然而，當(dāng)我們服務(wù)的應(yīng)用從十幾個(gè)增長(zhǎng)到幾百個(gè)的時(shí)候，大量的中小應(yīng)用加入，大家紛紛表示，原來的方案限制太大，很多應(yīng)用其實(shí)只是希望做個(gè)讀寫分離，希望能有更好的SQL兼容性。

于是，我們做了第一次重大升級(jí)，在這次升級(jí)里，我們提出了一個(gè)重要的概念就是三層架構(gòu)，Matrix對(duì)應(yīng)數(shù)據(jù)庫(kù)切分場(chǎng)景，對(duì)SQL有一定限制，Group對(duì)應(yīng)讀寫分離和高可用場(chǎng)景，對(duì)SQL幾乎沒有限制。如圖2所示。

圖2 數(shù)據(jù)庫(kù)升級(jí)為三層架構(gòu)

這種做法立刻得到了大家的認(rèn)可，TDDL所提供的讀寫分離、分庫(kù)分表等核心功能，也成為了阿里集團(tuán)內(nèi)數(shù)據(jù)庫(kù)領(lǐng)域的標(biāo)配組件，在阿里的幾乎所有應(yīng)用上都有應(yīng)用。最為難得的是，這些功能從上線后，到現(xiàn)在已經(jīng)經(jīng)歷了多年雙11的嚴(yán)酷考驗(yàn)，從未出現(xiàn)過嚴(yán)重故障（p0、p1級(jí)別故障屬于嚴(yán)重故障）。數(shù)據(jù)庫(kù)體系作為整個(gè)應(yīng)用系統(tǒng)的重中之重，能做到這件事，真是非常不容易。

隨著核心功能的穩(wěn)定，自2010年開始，我們集中全部精力開始關(guān)注TDDL后端運(yùn)維系統(tǒng)的完善與改進(jìn)性工作。在DBA團(tuán)隊(duì)的給力配合下，圍繞著TDDL，我們成功做到了在線數(shù)據(jù)動(dòng)態(tài)擴(kuò)縮、異步索引等關(guān)鍵特征，同時(shí)也比較成功地構(gòu)建了一整套分布式數(shù)據(jù)庫(kù)服務(wù)管控體系，用戶基本上可以完全自助地完成整套數(shù)據(jù)庫(kù)環(huán)境的搭建與初始化工作。

大概是2012年，我們?cè)诎⒗镌茍F(tuán)隊(duì)的支持下，開始嘗試將TDDL這套體系輸出到阿里云上，也有了個(gè)新的名字：阿里分布式數(shù)據(jù)庫(kù)服務(wù)（DRDS），希望能夠用我們的技術(shù)服務(wù)好更多的人。

不過當(dāng)我們滿懷自信地把自己的軟件拿到云上的時(shí)候，卻發(fā)現(xiàn)我們的軟件距離用戶的要求差距很大。在內(nèi)部因?yàn)橛蠨BA的同學(xué)們幫助進(jìn)行SQL review，所以SQL的復(fù)雜度都是可控的。然而到了云上，看了各種渠道提過來的兼容性需求，我們經(jīng)常是不自覺地發(fā)出這樣的感嘆：“啊？原來這種語(yǔ)法MySQL也是可以支持的？”

于是，我們又進(jìn)行了架構(gòu)升級(jí)，這次是以兼容性為核心目標(biāo)的系統(tǒng)升級(jí)工作，希望能夠在分布式場(chǎng)景下支持各類復(fù)雜的SQL，同時(shí)也將阿里這么多年來在分布式事務(wù)上的積累都帶到了DRDS里面。

這次架構(gòu)升級(jí)，我們的投入史無前例，用了三年多才將整個(gè)系統(tǒng)落地完成。我們先在內(nèi)部以我們自己的業(yè)務(wù)作為首批用戶上線，經(jīng)過了內(nèi)部幾百個(gè)應(yīng)用的嚴(yán)酷考驗(yàn)以后，我們才敢拿到云上，給到我們的最終用戶使用。

目前，我們正在將TDDL中更多的積累輸出到云上，同時(shí)也努力優(yōu)化我們的用戶界面。PS：其實(shí)用戶界面優(yōu)化對(duì)我們這種專注于高性能后端技術(shù)的團(tuán)隊(duì)來說，才是最大的技術(shù)挑戰(zhàn)，連我也去學(xué)了AngularJS，參與了用戶UI編。

DRDS主要功能介紹

發(fā)展歷史看完了，下面就由我來介紹一下目前我們已經(jīng)輸出到云上的主要功能。

【分布式SQL執(zhí)行引擎】

分布式SQL引擎主要的目的，就是實(shí)現(xiàn)與單機(jī)數(shù)據(jù)庫(kù)SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容，包括各類join和各類復(fù)雜函數(shù)等。他主要包含SQL解析、優(yōu)化、執(zhí)行和合并四個(gè)流程，如圖3中綠色部分。

圖3 SQL引擎實(shí)現(xiàn)的主要流程

雖然SQL是兼容的，但是分布式SQL執(zhí)行算法與單機(jī)SQL的執(zhí)行算法卻完全不同，原因也很簡(jiǎn)單，網(wǎng)絡(luò)通信的延遲比單機(jī)內(nèi)通信的延遲大得多。舉個(gè)例子說明一下，我們有份文件要從一張紙A上謄寫到另外一張紙B上，單機(jī)系統(tǒng)就好比兩張紙都在同一個(gè)辦公室里，而分布式數(shù)據(jù)庫(kù)則就像是一張紙?jiān)诒本粡埣堅(jiān)诤贾荨?/p>

自然地，如果兩張紙?jiān)谕粋€(gè)辦公室，因?yàn)閭鬏斁嚯x近，逐行謄寫的效率是可以接受的。而如果距離是北京到杭州，用逐行謄寫的方式，就立刻顯得代價(jià)太高了，我們總不能看一行，就打個(gè)“飛的”去杭州寫下來吧。在這種情況下，還是把紙A上的信息拍個(gè)照片，【一整批的】帶到杭州去處理，明顯更簡(jiǎn)單一些。這就是分布式數(shù)據(jù)庫(kù)特別強(qiáng)調(diào)吞吐調(diào)優(yōu)的原因，只要是涉及到跨機(jī)的所有查詢，都必須盡可能的積攢一批后一起發(fā)送，以減少系統(tǒng)延遲提高帶來的不良影響。

【按需數(shù)據(jù)庫(kù)集群平滑擴(kuò)縮】

DRDS允許應(yīng)用按需將新的單機(jī)存儲(chǔ)加入或移出集群，DRDS則能夠保證應(yīng)用在遷移流程中實(shí)現(xiàn)不停機(jī)擴(kuò)容縮容。

圖4 DRDS按需進(jìn)行平滑擴(kuò)縮

在內(nèi)部的數(shù)據(jù)庫(kù)使用實(shí)踐中，這個(gè)功能的一個(gè)最重要應(yīng)用場(chǎng)景就是雙11了。在雙11之前，我們會(huì)將大批的機(jī)器加入到我們的數(shù)據(jù)庫(kù)集群中，抗過了雙11，這批機(jī)器就會(huì)下線。

當(dāng)DRDS來到云上，我們發(fā)現(xiàn)雙11其實(shí)不僅僅只影響阿里內(nèi)部的系統(tǒng)。在下游的各類電商輔助性系統(tǒng)其實(shí)也面對(duì)巨大壓力。在雙11前5天，網(wǎng)聚寶的熊總就找到我說，擔(dān)心撐不過雙11的流量，怕系統(tǒng)掛。于是我們就給他介紹了這個(gè)自動(dòng)擴(kuò)容的功能怎么用，他買了一個(gè)月的數(shù)據(jù)庫(kù)，掛接在DRDS上。數(shù)據(jù)庫(kù)能力立刻翻倍，輕松抗過了雙11，也算是我印象比較深刻的一個(gè)案例了。

因?yàn)槲覀兺耆珶o法預(yù)測(cè)在什么時(shí)間點(diǎn)系統(tǒng)會(huì)有爆發(fā)性的增長(zhǎng)，而如果在這時(shí)候系統(tǒng)因?yàn)榧夹g(shù)原因不能使用，就會(huì)給整個(gè)業(yè)務(wù)帶來毀滅性的影響，風(fēng)口一旦錯(cuò)過，就追悔莫及了。我想這就是云計(jì)算特別強(qiáng)調(diào)可擴(kuò)展能力的原因吧。

【小表廣播】

小表廣播也是我們?cè)诜植际綌?shù)據(jù)庫(kù)領(lǐng)域內(nèi)最常用的工具之一，他的核心目的其實(shí)都是一個(gè)——盡可能讓查詢只發(fā)生在單機(jī)。

讓我們用一個(gè)例子來說明，小表廣播的一般使用場(chǎng)景。

圖5 小表廣播場(chǎng)景

圖5中，如果我想知道買家id等于0的用戶在商城里面買了哪些商品，我們一般會(huì)先將這兩個(gè)表join起來，然后再用where平臺(tái)名=”商城” and buyerID = 0找到符合要求的數(shù)據(jù)。然而這種join的方式，會(huì)導(dǎo)致大量的針對(duì)左表的網(wǎng)絡(luò)I/O。如果要取出的數(shù)據(jù)量比較大，系統(tǒng)延遲會(huì)明顯上升。

這時(shí)候，為了提升性能，我們就必須要減少跨機(jī)join的網(wǎng)絡(luò)代價(jià)。我們比較推薦應(yīng)用做如下處理，將左表復(fù)制到右表的每一個(gè)庫(kù)上。這樣，join操作就由分布式j(luò)oin一下變回到本地join，系統(tǒng)的性能就有很大的提升了，如圖6所示。

圖6

【分布式事務(wù)套件】

在阿里巴巴的業(yè)務(wù)體系中存在非常多需要事務(wù)類的場(chǎng)景，下單減庫(kù)存，賬務(wù)，都是事務(wù)場(chǎng)景最集中的部分。

而我們處理事務(wù)的方法卻和傳統(tǒng)應(yīng)用處理事務(wù)的方案不大一樣，我們非常強(qiáng)調(diào)事務(wù)的最終一致性和異步化。利用這種方式，能夠極大地降低分布式系統(tǒng)中鎖持有的時(shí)間，從而極大地提升系統(tǒng)性能。

圖7 DRDS分布式事務(wù)解決套件

這種處理機(jī)制，是我們分布式事務(wù)能夠以極低成本大量運(yùn)行的最核心法門。在DRDS平臺(tái)內(nèi)，我們將這些方案產(chǎn)品化，為了DRDS的分布式事務(wù)解決套件。

利用他們，能夠讓你以比較低的成本，實(shí)現(xiàn)低延遲，高吞吐的分布式事務(wù)場(chǎng)景。

DRDS的未來

阿里分布式數(shù)據(jù)庫(kù)服務(wù)DRDS上線至今，大家對(duì)這款產(chǎn)品的熱情超出了我們的預(yù)期，短短半年內(nèi)已經(jīng)有幾千個(gè)申請(qǐng)。

盡管還在公測(cè)期，但是大家就已經(jīng)把關(guān)系到身家性命的寶貴在線數(shù)據(jù)業(yè)務(wù)放到了DRDS上，我能夠感受到這份沉甸甸的信賴，也不想辜負(fù)這份信賴。

經(jīng)過阿里內(nèi)部幾千個(gè)應(yīng)用的不斷歷練，DRDS已經(jīng)積累出一套強(qiáng)大的分布式SQL執(zhí)行引擎和和一整套分布式事務(wù)套件。

我也相信，這些積累能夠讓用戶在基本保持單機(jī)數(shù)據(jù)庫(kù)的使用習(xí)慣的前提下，享受到分布式數(shù)據(jù)庫(kù)高性能可擴(kuò)展的好處。

在平時(shí)的DRDS支持過程中，我面對(duì)最多的問題就是，DRDS能不能夠在不改變?nèi)魏卧袠I(yè)務(wù)邏輯和代碼的前提下，實(shí)現(xiàn)可自由伸縮和擴(kuò)展呢？十分可惜的是，關(guān)系數(shù)據(jù)庫(kù)發(fā)展至今，還沒有找到既能保留傳統(tǒng)數(shù)據(jù)庫(kù)一切特性，又能實(shí)現(xiàn)高性能可擴(kuò)展數(shù)據(jù)庫(kù)的方法。

然而，雖不能至，吾心向往之！我們會(huì)以“可擴(kuò)展，高性能”為產(chǎn)品核心，堅(jiān)定地走在追尋圣杯的路上，并堅(jiān)信最終我們一定能夠找尋到它神圣的所在。

作者簡(jiǎn)介：王晶昱，花名沈詢，阿里巴巴資深技術(shù)專家。目前主要負(fù)責(zé)阿里的分布式數(shù)據(jù)庫(kù)DRDS（TDDL）和阿里的分布式消息服務(wù)ONS（RocketMQ/Notify）兩個(gè)系統(tǒng)。

為什么只有阿里云和AWS擁有自研云數(shù)據(jù)庫(kù)的能力？

很多國(guó)產(chǎn)數(shù)據(jù)庫(kù)乘風(fēng)破浪

我們正處在一個(gè)數(shù)據(jù)庫(kù)技術(shù)大爆炸的時(shí)代。

這幾年，NoSQL數(shù)據(jù)庫(kù)、NewSQL數(shù)據(jù)庫(kù)、時(shí)序數(shù)據(jù)庫(kù)、圖數(shù)據(jù)庫(kù)、分布式數(shù)據(jù)庫(kù)、超融合數(shù)據(jù)庫(kù)等專業(yè)數(shù)據(jù)庫(kù)技術(shù)發(fā)展勢(shì)頭很猛，國(guó)產(chǎn)數(shù)據(jù)庫(kù)的表現(xiàn)也相當(dāng)亮眼。

過去十年，是互聯(lián)網(wǎng)發(fā)展的黃金十年。與此對(duì)應(yīng)的是業(yè)務(wù)系統(tǒng)訪問并發(fā)呈指數(shù)級(jí)上升，海量數(shù)據(jù)計(jì)算和分析需求越來越普遍，傳統(tǒng)單機(jī)系統(tǒng)在業(yè)務(wù)支撐、成本、開放性等方面均面臨巨大挑戰(zhàn)，數(shù)據(jù)庫(kù)垂直擴(kuò)展模式難以維護(hù)等困境。

眼看著數(shù)據(jù)庫(kù)性能瓶頸快要扼住發(fā)展的喉嚨，擺在這些長(zhǎng)久依賴Oracle、IBM等傳統(tǒng)數(shù)據(jù)庫(kù)的巨頭們面前的，只有兩條路：要么開啟無限加量的PLUS模式，即更換更多更強(qiáng)的服務(wù)器、硬盤、內(nèi)存、CPU等，要么自研能滿足業(yè)務(wù)發(fā)展需求的數(shù)據(jù)庫(kù)。

開拓者們的眼光一開始就聚焦在更長(zhǎng)遠(yuǎn)的未來，他們發(fā)現(xiàn)即便是系統(tǒng)變成真正的“傻大粗”，也只是解了燃眉之急，不能從源頭解決問題。

再看一眼像Oracle、IBM等傳統(tǒng)數(shù)據(jù)庫(kù)高昂的拓容價(jià)格，像阿里這樣的富一代也吃不消哇！

那么，自研數(shù)據(jù)庫(kù)，走起！

2010年后，云計(jì)算和開源社區(qū)興起，國(guó)產(chǎn)數(shù)據(jù)庫(kù)開始了彎道超車。

2019年被認(rèn)為是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的元年。

這一年，眾多國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品闖入了我們的視線，熱度不斷攀升；這一年，OceanBase登頂TPCC，并于一年后再次刷新自己的記錄。

從刀耕火種到摘下Oracle在數(shù)據(jù)庫(kù)領(lǐng)域的皇冠，國(guó)產(chǎn)數(shù)據(jù)庫(kù)經(jīng)歷的是一段不被理解和不被看好的歲月。

在國(guó)外數(shù)據(jù)庫(kù)先驅(qū)長(zhǎng)期占據(jù)市場(chǎng)優(yōu)勢(shì)的情況下，國(guó)產(chǎn)數(shù)據(jù)庫(kù)要想殺出重圍，一是要付出多倍努力，二是要拿出更強(qiáng)的產(chǎn)品才能在客戶面前更有底氣。

當(dāng)然，國(guó)產(chǎn)數(shù)據(jù)庫(kù)發(fā)展至今，已然是百花齊放。未來，國(guó)產(chǎn)數(shù)據(jù)庫(kù)的發(fā)展趨勢(shì)相對(duì)也比較明顯，即往云原生和分布式發(fā)展。

金融級(jí)分布式數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生

數(shù)字時(shí)代，數(shù)據(jù)成為各家必爭(zhēng)之地。

在金融應(yīng)用場(chǎng)景下，國(guó)內(nèi)數(shù)據(jù)庫(kù)市場(chǎng)于近幾年開始發(fā)生變化。

隨著應(yīng)用層和業(yè)務(wù)層的壓力加大，金融機(jī)構(gòu)對(duì)分布式技術(shù)架構(gòu)轉(zhuǎn)型的需求應(yīng)運(yùn)而生。

作為軟件系統(tǒng)的三大底層技術(shù)（操作系統(tǒng)、中間件、數(shù)據(jù)庫(kù)）之一，數(shù)據(jù)庫(kù)成為系統(tǒng)往分布式架構(gòu)轉(zhuǎn)型的樞紐。

不過，在早年國(guó)外傳統(tǒng)數(shù)據(jù)庫(kù)廠商盤根錯(cuò)節(jié)的“蠶食”下，這個(gè)核心變得又硬又難啃！

面對(duì)如今市場(chǎng)的需求變化，傳統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)呈現(xiàn)出一個(gè)通?。河直恐赜仲F。

再是，隨著諸如2013年“棱鏡門”事件的爆發(fā)，各界越來越重視數(shù)據(jù)安全和技術(shù)自主可控。

此外，金融機(jī)構(gòu)對(duì)快速、靈活、可伸縮性、創(chuàng)新、敏捷等開發(fā)能力需求大大提升，出于對(duì)長(zhǎng)期IT建設(shè)的成本考慮，自主可控更是成為他們出于自身長(zhǎng)遠(yuǎn)發(fā)展考量的剛需。

數(shù)字化時(shí)代，金融機(jī)構(gòu)的整體架構(gòu)正處于往分布式、云原生、微服務(wù)等方向發(fā)展的關(guān)鍵時(shí)刻，數(shù)據(jù)庫(kù)的選型便顯得至關(guān)重要。

根據(jù)中國(guó)人民銀行發(fā)布的《金融 科技 （FinTech）發(fā)展規(guī)劃（2019-2021年）》，我國(guó)將有計(jì)劃、分步驟地穩(wěn)妥推動(dòng)分布式數(shù)據(jù)庫(kù)產(chǎn)品先行先試，形成可借鑒、能推廣的典型案例和解決方案，為分布式數(shù)據(jù)庫(kù)在金融領(lǐng)域的全面應(yīng)用探明路徑，確保分布式數(shù)據(jù)庫(kù)在金融領(lǐng)域穩(wěn)妥應(yīng)用。

目前已有不少業(yè)界實(shí)踐證明了分布式數(shù)據(jù)庫(kù)應(yīng)用于金融場(chǎng)景的可靠性。同時(shí)，金融級(jí)分布式數(shù)據(jù)庫(kù)云化已經(jīng)在路上。

通過阿里來看大型應(yīng)用數(shù)據(jù)庫(kù)是選擇Oracle MySQL 還是 NoSQL

肯定是Oracle，因?yàn)閺暮?jiǎn)單查詢性能角度來比較：Oracle MySQL NoSQL，NoSQL 產(chǎn)品不支持 Join，MySQL 的查詢優(yōu)化器由于所基于的統(tǒng)計(jì)信息相對(duì)少很多，當(dāng)Query 復(fù)雜度很高的時(shí)候容易出現(xiàn)執(zhí)行計(jì)劃不是最優(yōu)選擇的問題，而 Oracle 由于大量的統(tǒng)計(jì)信息支持，使得其查詢優(yōu)化器更為智能，對(duì)復(fù)雜查詢有更優(yōu)的表現(xiàn)。

當(dāng)前標(biāo)題：阿里的nosql,阿里的價(jià)值觀
地址分享：http://m.jiaotiyi.com/article/phsece.html