這篇文章主要介紹了云原生數(shù)據(jù)庫(kù)設(shè)計(jì)的方法是什么的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇云原生數(shù)據(jù)庫(kù)設(shè)計(jì)的方法是什么文章都會(huì)有所收獲，下面我們一起來看看吧。

成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站制作、成都做網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)嘉黎,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575

常見的分布式數(shù)據(jù)庫(kù)流派

分布式數(shù)據(jù)庫(kù)的發(fā)展歷程，我按照年代進(jìn)行了分類，到目前為止分成了四代。第一代是基于簡(jiǎn)單的分庫(kù)分表或者中間件來做 Data Sharding 和 水平擴(kuò)展。第二代系統(tǒng)是以 Cassandra、HBase 或者 MongoDB 為代表的 NOSQL 數(shù)據(jù)庫(kù)，一般多為互聯(lián)網(wǎng)公司在使用，擁有很好的水平擴(kuò)展能力。

第三代系統(tǒng)我個(gè)人認(rèn)為是以 Google Spanner 和 AWS Aurora 為代表的新一代云數(shù)據(jù)庫(kù)，他們的特點(diǎn)是融合了 SQL 和 NoSQL 的擴(kuò)展能力，對(duì)業(yè)務(wù)層暴露了 SQL 的接口，在使用上可以做到水平的擴(kuò)展。

第四代系統(tǒng)是以現(xiàn)在 TiDB 的設(shè)計(jì)為例，開始進(jìn)入到混合業(yè)務(wù)負(fù)載的時(shí)代，一套系統(tǒng)擁有既能做交易也能處理高并發(fā)事務(wù)的特性，同時(shí)又能結(jié)合一些數(shù)據(jù)倉(cāng)庫(kù)或者分析型數(shù)據(jù)庫(kù)的能力，所以叫 HTAP，就是融合型的數(shù)據(jù)庫(kù)產(chǎn)品。

未來是什么樣子，后面的分享我會(huì)介紹關(guān)于未來的一些展望。從整個(gè)時(shí)間線看，從 1970 年代發(fā)展到現(xiàn)在，database 也算是個(gè)古老的行業(yè)了，具體每個(gè)階段的發(fā)展情況，我就不過多展開。

數(shù)據(jù)庫(kù)中間件

對(duì)于數(shù)據(jù)庫(kù)中間件來說，第一代系統(tǒng)是中間件的系統(tǒng)，基本上整個(gè)主流模式有兩種，一種是在業(yè)務(wù)層做手動(dòng)的分庫(kù)分表，比如數(shù)據(jù)庫(kù)的使用者在業(yè)務(wù)層里告訴你；北京的數(shù)據(jù)放在一個(gè)數(shù)據(jù)庫(kù)里，而上海的數(shù)據(jù)放在另一個(gè)數(shù)據(jù)庫(kù)或者寫到不同的表上，這種就是業(yè)務(wù)層手動(dòng)的最簡(jiǎn)單的分庫(kù)分表，相信大家操作過數(shù)據(jù)庫(kù)的朋友都很熟悉。

第二種通過一個(gè)數(shù)據(jù)庫(kù)中間件指定 Sharding 的規(guī)則。比如像用戶的城市、用戶的 ID、時(shí)間來做為分片的規(guī)則，通過中間件來自動(dòng)的分配，就不用業(yè)務(wù)層去做。

這種方式的優(yōu)點(diǎn)就是簡(jiǎn)單。如果業(yè)務(wù)在特別簡(jiǎn)單的情況下，比如說寫入或者讀取基本能退化成在一個(gè)分片上完成，在應(yīng)用層做充分適配以后，延遲還是比較低的，而整體上，如果 workload 是隨機(jī)的，業(yè)務(wù)的 TPS 也能做到線性擴(kuò)展。

但是缺點(diǎn)也比較明顯。對(duì)于一些比較復(fù)雜的業(yè)務(wù)，特別是一些跨分片的操作，比如說查詢或者寫入要保持跨分片之間的數(shù)據(jù)強(qiáng)一致性的時(shí)候就比較麻煩。另外一個(gè)比較明顯的缺點(diǎn)是它對(duì)于大型集群的運(yùn)維是比較困難的，特別是去做一些類似的表結(jié)構(gòu)變更之類的操作。想象一下如果有一百個(gè)分片，要去加一列或者刪一列，相當(dāng)于要在一百臺(tái)機(jī)器上都執(zhí)行操作，其實(shí)很麻煩。

NoSQL - Not Only SQL

在 2010 年前后，好多互聯(lián)網(wǎng)公司都發(fā)現(xiàn)了這個(gè)大的痛點(diǎn)，仔細(xì)思考了業(yè)務(wù)后，他們發(fā)現(xiàn)業(yè)務(wù)很簡(jiǎn)單，也不需要 SQL 特別復(fù)雜的功能，于是就發(fā)展出了一個(gè)流派就是 NoSQL 數(shù)據(jù)庫(kù)。NoSQL 的特點(diǎn)就是放棄到了高級(jí)的 SQL 能力，但是有得必有失，或者說放棄掉了東西總能換來一些東西，NoSQL 換來的是一個(gè)對(duì)業(yè)務(wù)透明的、強(qiáng)的水平擴(kuò)展能力，但反過來就意味著你的業(yè)務(wù)原來是基于 SQL 去寫的話，可能會(huì)帶來比較大的改造成本，代表的系統(tǒng)有剛才我說到的 MongoDB、Cassandra、HBase 等。

最有名的系統(tǒng)就是 MongoDB，MongoDB 雖然也是分布式，但仍然還是像分庫(kù)分表的方案一樣，要選擇分片的 key，他的優(yōu)點(diǎn)大家都比較熟悉，就是沒有表結(jié)構(gòu)信息，想寫什么就寫什么，對(duì)于文檔型的數(shù)據(jù)比較友好，但缺點(diǎn)也比較明顯，既然選擇了 Sharding Key，可能是按照一個(gè)固定的規(guī)則在做分片，所以當(dāng)有一些跨分片的聚合需求的時(shí)候會(huì)比較麻煩，第二是在跨分片的 ACID 事務(wù)上沒有很好的支持。

HBase 是 Hadoop 生態(tài)下的比較有名的分布式 NoSQL 數(shù)據(jù)庫(kù)，它是構(gòu)建在 HDFS 之上的一個(gè) NoSQL 數(shù)據(jù)庫(kù)。Cassandra 是一個(gè)分布式的 KV 數(shù)據(jù)庫(kù)，其特點(diǎn)是在 KV 操作上提供多種一致性模型，缺點(diǎn)與很多 NoSQL 的問題一樣，包括運(yùn)維的復(fù)雜性， KV 的接口對(duì)于原有業(yè)務(wù)改造的要求等。

第三代分布式數(shù)據(jù)庫(kù) NewSQL

剛才說過 Sharding 或者分庫(kù)分表，NoSQL 也好，都面臨著一個(gè)業(yè)務(wù)的侵入性問題，如果你的業(yè)務(wù)是重度依賴 SQL，那么用這兩種方案都是很不舒適的。于是一些技術(shù)比較前沿的公司就在思考，能不能結(jié)合傳統(tǒng)數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)，比如 SQL 表達(dá)力，事務(wù)一致性等特性，但是又跟 NoSQL 時(shí)代好的特性，比如擴(kuò)展性能夠相結(jié)合發(fā)展出一種新的、可擴(kuò)展的，但是用起來又像單機(jī)數(shù)據(jù)庫(kù)一樣方便的系統(tǒng)。在這個(gè)思路下就誕生出了兩個(gè)流派，一個(gè)是 Spanner，一個(gè)是 Aurora，兩個(gè)都是頂級(jí)的互聯(lián)網(wǎng)公司在面臨到這種問題時(shí)做出的一個(gè)選擇。

Shared Nothing 流派

Shared Nothing 這個(gè)流派是以 Google Spanner 為代表，好處是在于可以做到幾乎無(wú)限的水平擴(kuò)展，整個(gè)系統(tǒng)沒有端點(diǎn)，不管是 1 個(gè) T、10 個(gè) T 或者 100 個(gè) T，業(yè)務(wù)層基本上不用擔(dān)心擴(kuò)展能力。第二個(gè)好處是他的設(shè)計(jì)目標(biāo)是提供強(qiáng) SQL 的支持，不需要指定分片規(guī)則、分片策略，系統(tǒng)會(huì)自動(dòng)的幫你做擴(kuò)展。第三是支持像單機(jī)數(shù)據(jù)庫(kù)一樣的強(qiáng)一致的事務(wù)，可以用來支持金融級(jí)別的業(yè)務(wù)。

代表產(chǎn)品就是 Spanner 與 TiDB，這類系統(tǒng)也有一些缺點(diǎn)，從本質(zhì)上來說一個(gè)純分布式數(shù)據(jù)庫(kù)，很多行為沒有辦法跟單機(jī)行為一模一樣。舉個(gè)例子，比如說延遲，單機(jī)數(shù)據(jù)庫(kù)在做交易事務(wù)的時(shí)候，可能在單機(jī)上就完成了，但是在分布式數(shù)據(jù)庫(kù)上，如果要去實(shí)現(xiàn)同樣的一個(gè)語(yǔ)義，這個(gè)事務(wù)需要操作的行可能分布在不同的機(jī)器上，需要涉及到多次網(wǎng)絡(luò)的通信和交互，響應(yīng)速度和性能肯定不如在單機(jī)上一次操作完成，所以在一些兼容性和行為上與單機(jī)數(shù)據(jù)庫(kù)還是有一些區(qū)別的。即使是這樣，對(duì)于很多業(yè)務(wù)來說，與分庫(kù)分表相比，分布式數(shù)據(jù)庫(kù)還是具備很多優(yōu)勢(shì)，比如在易用性方面還是比分庫(kù)分表的侵入性小很多。

Shared Everything 流派

第二種流派就是 Shared Everything 流派，代表有 AWS Aurora、阿里云的 PolarDB，很多數(shù)據(jù)庫(kù)都定義自己是 Cloud-Native Database，但我覺得這里的 Cloud-Native 更多是在于通常這些方案都是由公有云服務(wù)商來提供的，至于本身的技術(shù)是不是云原生，并沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。從純技術(shù)的角度來去說一個(gè)核心的要點(diǎn)，這類系統(tǒng)的計(jì)算與存儲(chǔ)是徹底分離的，計(jì)算節(jié)點(diǎn)與存儲(chǔ)節(jié)點(diǎn)跑在不同機(jī)器上，存儲(chǔ)相當(dāng)于把一個(gè) MySQL 跑在云盤上的感覺，我個(gè)人認(rèn)為類似 Aurora 或者 PolarDB 的這種架構(gòu)并不是一個(gè)純粹的分布式架構(gòu)。

原來 MySQL 的主從復(fù)制都走 Binlog，Aurora 作為一種在云上 Share Everything Database 的代表，Aurora 的設(shè)計(jì)思路是把整個(gè) IO 的 flow 只通過 redo log 的形式來做復(fù)制，而不是通過整個(gè) IO 鏈路打到最后 Binlog，再發(fā)到另外一臺(tái)機(jī)器上，然后再 apply 這個(gè) Binlog，所以 Aurora 的 IO 鏈路減少很多，這是一個(gè)很大的創(chuàng)新。

日志復(fù)制的單位變小，意味著我發(fā)過去的只有 Physical log，不是 Binlog，也不是直接發(fā)語(yǔ)句過去，直接發(fā)物理的日志能代表著更小的 IO 的路徑以及更小的網(wǎng)絡(luò)包，所以整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的吞吐效率會(huì)比傳統(tǒng)的 MySQL 的部署方案好很多。

Aurora 的優(yōu)勢(shì)是 100% 兼容 MySQL，業(yè)務(wù)兼容性好，業(yè)務(wù)基本上不用改就可以用，而且對(duì)于一些互聯(lián)網(wǎng)的場(chǎng)景，對(duì)一致性要求不高的話，數(shù)據(jù)庫(kù)的讀也可以做到水平擴(kuò)展，不管是 Aurora 也好，PolarDB 也好，讀性能是有上限的。

Aurora 的短板大家也能看得出來，本質(zhì)上這還是一個(gè)單機(jī)數(shù)據(jù)庫(kù)，因?yàn)樗袛?shù)據(jù)量都是存儲(chǔ)在一起的，Aurora 的計(jì)算層其實(shí)就是一個(gè) MySQL 實(shí)例，不關(guān)心底下這些數(shù)據(jù)的分布，如果有大的寫入量或者有大的跨分片查詢的需求，如果要支持大數(shù)據(jù)量，還是需要分庫(kù)分表，所以 Aurora 是一款更好的云上單機(jī)數(shù)據(jù)庫(kù)。

第四代系統(tǒng)：分布式 HTAP 數(shù)據(jù)庫(kù)

第四代系統(tǒng)就是新形態(tài)的 HTAP 數(shù)據(jù)庫(kù)，英文名稱是 Hybrid Transactional and Analytical Processing，通過名字也很好理解，既可以做事務(wù)，又可以在同一套系統(tǒng)里面做實(shí)時(shí)分析。HTAP 數(shù)據(jù)庫(kù)的優(yōu)勢(shì)是可以像 NoSQL 一樣具備無(wú)限水平擴(kuò)展能力，像 NewSQL 一樣能夠去做 SQL 的查詢與事務(wù)的支持，更重要的是在混合業(yè)務(wù)等復(fù)雜的場(chǎng)景下，OLAP 不會(huì)影響到 OLTP 業(yè)務(wù)，同時(shí)省去了在同一個(gè)系統(tǒng)里面把數(shù)據(jù)搬來搬去的煩惱。目前，我看到在工業(yè)界基本只有 TiDB 4.0 加上 TiFlash 這個(gè)架構(gòu)能夠符合上述要求。

分布式 HTAP 數(shù)據(jù)庫(kù)：TiDB (with TiFlash)

為什么 TiDB 能夠?qū)崿F(xiàn) OLAP 和 OLTP 的徹底隔離，互不影響？因?yàn)?TiDB 是計(jì)算和存儲(chǔ)分離的架構(gòu)，底層的存儲(chǔ)是多副本機(jī)制，可以把其中一些副本轉(zhuǎn)換成列式存儲(chǔ)的副本。OLAP 的請(qǐng)求可以直接打到列式的副本上，也就是 TiFlash 的副本來提供高性能列式的分析服務(wù)，做到了同一份數(shù)據(jù)既可以做實(shí)時(shí)的交易又做實(shí)時(shí)的分析，這是 TiDB 在架構(gòu)層面的巨大創(chuàng)新和突破。

下圖是 TiDB 的測(cè)試結(jié)果，與 MemSQL 進(jìn)行了對(duì)比，根據(jù)用戶場(chǎng)景構(gòu)造了一種 workload，橫軸是并發(fā)數(shù)，縱軸是 OLTP 的性能，藍(lán)色、黃色、綠色這些是 OLAP 的并發(fā)數(shù)。這個(gè)實(shí)驗(yàn)的目的就是在一套系統(tǒng)上既跑 OLTP 又跑 OLAP，同時(shí)不斷提升 OLTP 和 OLAP 的并發(fā)壓力，從而查看這兩種 workload 是否會(huì)互相影響?？梢钥吹皆?TiDB 這邊，同時(shí)加大 OLTP 和 OLAP 的并發(fā)壓力，這兩種 workload 的性能表現(xiàn)沒有什么明顯變化，幾乎是差不多的。但是，同樣的實(shí)驗(yàn)發(fā)生在 MemSQL 上，大家可以看到 MemSQL 的性能大幅衰減，隨著 OLAP 的并發(fā)數(shù)變大，OLTP 的性能下降比較明顯。

接下來是 TiDB 在一個(gè)用戶實(shí)際業(yè)務(wù)場(chǎng)景的例子，在進(jìn)行 OLAP 業(yè)務(wù)的查詢的時(shí)候，OLTP 業(yè)務(wù)仍然可以實(shí)現(xiàn)平滑的寫入操作，延遲一直維持在較低的水平。

未來在哪里

Snowflake

Snowflake 是一個(gè) 100% 構(gòu)建在云上的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，底層的存儲(chǔ)依賴 S3，基本上每個(gè)公有云都會(huì)提供類似 S3 這樣的對(duì)象存儲(chǔ)服務(wù)，Snowflake 也是一個(gè)純粹的計(jì)算與存儲(chǔ)分離的架構(gòu)，在系統(tǒng)里面定義的計(jì)算節(jié)點(diǎn)叫 Virtual Warehouse，可以認(rèn)為就是一個(gè)個(gè) EC2 單元，本地的緩存有日志盤，Snowflake 的主要數(shù)據(jù)存在 S3 上，本地的計(jì)算節(jié)點(diǎn)是在公有云的虛機(jī)上。

這是 Snowflake 在 S3 里面存儲(chǔ)的數(shù)據(jù)格式的特點(diǎn)，每一個(gè) S3 的對(duì)象是 10 兆一個(gè)文件，只追加，每一個(gè)文件里面包含源信息，通過列式的存儲(chǔ)落到磁盤上。

Snowflake 這個(gè)系統(tǒng)最重要的一個(gè)閃光點(diǎn)就是對(duì)于同一份數(shù)據(jù)可以分配不同的計(jì)算資源進(jìn)行計(jì)算，比如某個(gè) query 可能只需要兩臺(tái)機(jī)器，另外一個(gè) query 需要更多的計(jì)算資源，但是沒關(guān)系，實(shí)際上這些數(shù)據(jù)都在 S3 上面，簡(jiǎn)單來說兩臺(tái)機(jī)器可以掛載同一塊磁盤分別去處理不同的工作負(fù)載，這就是一個(gè)計(jì)算與存儲(chǔ)解耦的重要例子。

Google BigQuery

第二個(gè)系統(tǒng)是 BigQuery，BigQuery 是 Google Cloud 上提供的大數(shù)據(jù)分析服務(wù)，架構(gòu)設(shè)計(jì)上跟 Snowflake 有點(diǎn)類似。BigQuery 的數(shù)據(jù)存儲(chǔ)在谷歌內(nèi)部的分布式文件系統(tǒng) Colossus 上面，Jupiter 是內(nèi)部的一個(gè)高性能網(wǎng)絡(luò)，上面這個(gè)是谷歌的計(jì)算節(jié)點(diǎn)。

BigQuery 的處理性能比較出色，每秒在數(shù)據(jù)中心內(nèi)的一個(gè)雙向的帶寬可以達(dá)到 1 PB，如果使用 2000 個(gè)專屬的計(jì)算節(jié)點(diǎn)單元，大概一個(gè)月的費(fèi)用是四萬(wàn)美金。BigQuery 是一個(gè)按需付費(fèi)的模式，一個(gè) query 可能就用兩個(gè) slot，就收取這兩個(gè) slot 的費(fèi)用，BigQuery 的存儲(chǔ)成本相對(duì)較低，1 TB 的存儲(chǔ)大概 20 美金一個(gè)月。

RockSet

第三個(gè)系統(tǒng)是 RockSet，大家知道 RocksDB 是一個(gè)比較有名的單機(jī) KV 數(shù)據(jù)庫(kù)，其存儲(chǔ)引擎的數(shù)據(jù)結(jié)構(gòu)叫 LSM-Tree，LSM-Tree 的核心思想進(jìn)行分層設(shè)計(jì)，更冷的數(shù)據(jù)會(huì)在越下層。RockSet 把后面的層放在了 S3 的存儲(chǔ)上面，上面的層其實(shí)是用 local disk 或者本地的內(nèi)存來做引擎，天然是一個(gè)分層的結(jié)構(gòu)，你的應(yīng)用感知不到下面是一個(gè)云盤還是本地磁盤，通過很好的本地緩存讓你感知不到下面云存儲(chǔ)的存在。

所以剛才看了這三個(gè)系統(tǒng)，我覺得有幾個(gè)特點(diǎn)，一個(gè)是首先都是天然分布式的，第二個(gè)是構(gòu)建在云的標(biāo)準(zhǔn)服務(wù)上面的，尤其是 S3 和 EBS，第三是 pay as you go，在架構(gòu)里面充分利用了云的彈性能力。我覺得這三點(diǎn)最重要的一點(diǎn)是存儲(chǔ)，存儲(chǔ)系統(tǒng)決定了云上數(shù)據(jù)庫(kù)的設(shè)計(jì)方向。

為什么 S3 是關(guān)鍵？

在存儲(chǔ)里邊我覺得更關(guān)鍵的可能是 S3。EBS 其實(shí)我們也有研究過，TiDB 第一階段其實(shí)已經(jīng)正在跟 EBS 塊存儲(chǔ)做融合，但從更長(zhǎng)遠(yuǎn)的角度來看，我覺得更有意思的方向是在 S3 這邊。

首先第一點(diǎn) S3 非常劃算，價(jià)格遠(yuǎn)低于 EBS，第二 S3 提供了 9 個(gè) 9 很高的可靠性，第三是具備線性擴(kuò)展的吞吐能力，第四是天然跨云，每一個(gè)云上都有 S3 API 的對(duì)象存儲(chǔ)服務(wù)。但是 S3 的問題就是隨機(jī)寫入的延遲非常高，但是吞吐性能不錯(cuò)，所以我們要去利用這個(gè)吞吐性能不錯(cuò)的這個(gè)特點(diǎn)，規(guī)避延遲高的風(fēng)險(xiǎn)。這是 S3 benchmark 的一個(gè)測(cè)試，可以看到隨著機(jī)型的提升，吞吐能力也是持續(xù)的提升。

如何解決 Latency 的問題？

如果要解決 S3 的 Latency 問題，這里提供一些思路，比如像 RockSet 那樣用 SSD 或者本地磁盤來做 cache，或者通過 kinesis 寫入日志，來降低整個(gè)寫入的延遲。還有數(shù)據(jù)的復(fù)制或者你要去做一些并發(fā)處理等，其實(shí)可以去做 Zero-copy data cloning，也是降低延遲的一些方式。

上述例子有一些共同點(diǎn)都是數(shù)據(jù)倉(cāng)庫(kù)，不知道大家有沒有發(fā)現(xiàn)，為什么都是數(shù)據(jù)倉(cāng)庫(kù)？數(shù)據(jù)倉(cāng)庫(kù)對(duì)于吞吐的要求其實(shí)是更高的，對(duì)于延遲并不是那么在意，一個(gè) query 可能跑五秒出結(jié)果就行了，不用要求五毫秒之內(nèi)給出結(jié)果，特別是對(duì)于一些 Point Lookup 這種場(chǎng)景來說，Shared Nothing 的 database 可能只需要從客戶端的一次 rpc，但是對(duì)于計(jì)算與存儲(chǔ)分離的架構(gòu)，中間無(wú)論如何要走兩次網(wǎng)絡(luò)，這是一個(gè)核心的問題。

你可能會(huì)說沒有關(guān)系，反正計(jì)算和存儲(chǔ)已經(jīng)分離了，大力出奇跡，可以加計(jì)算節(jié)點(diǎn)。但是我覺得新思路沒必要這么極端，Aurora 是一個(gè)計(jì)算存儲(chǔ)分離架構(gòu)，但它是一個(gè)單機(jī)數(shù)據(jù)庫(kù)，Spanner 是一個(gè)純分布式的數(shù)據(jù)庫(kù)，純 Shared Nothing 的架構(gòu)并沒有利用到云基礎(chǔ)設(shè)施提供的一些優(yōu)勢(shì)。

比如說未來我們的數(shù)據(jù)庫(kù)可以做這樣的設(shè)計(jì)，在計(jì)算層其實(shí)帶著一點(diǎn)點(diǎn)狀態(tài)，因?yàn)槊颗_(tái) EC2 都會(huì)帶一個(gè)本地磁盤，現(xiàn)在主流的 EC2 都是 SSD，比較熱的數(shù)據(jù)可以在這一層做 Shared Nothing，在這一層去做高可用，在這一層去做隨機(jī)的讀取與寫入。熱數(shù)據(jù)一旦 cache miss，才會(huì)落到 S3 上面，可以在 S3 只做后面幾層的數(shù)據(jù)存儲(chǔ)，這種做法可能會(huì)帶來問題，一旦穿透了本地 cache，Latency 會(huì)有一些抖動(dòng)。

這種架構(gòu)設(shè)計(jì)的好處：首先，擁有對(duì)實(shí)時(shí)業(yè)務(wù)的數(shù)據(jù)計(jì)算親和力，在 local disk 上會(huì)有很多數(shù)據(jù)，在這點(diǎn)上很多傳統(tǒng)數(shù)據(jù)庫(kù)的一些性能優(yōu)化技巧可以用起來；第二，數(shù)據(jù)遷移其實(shí)會(huì)變得很簡(jiǎn)單，實(shí)際上底下的存儲(chǔ)是共享的，都在 S3 上面，比如說 A 機(jī)器到 B 機(jī)器的數(shù)據(jù)遷移其實(shí)不用真的做遷移，只要在 B 機(jī)器上讀取數(shù)據(jù)就行了。

這個(gè)架構(gòu)的缺點(diǎn)是：第一，緩存穿透了以后，Latency 會(huì)變高；第二，計(jì)算節(jié)點(diǎn)現(xiàn)在有了狀態(tài)，如果計(jì)算節(jié)點(diǎn)掛掉了以后，F(xiàn)ailover 要去處理日志回放的問題，這可能會(huì)增加一點(diǎn)實(shí)現(xiàn)的復(fù)雜度。

關(guān)于“云原生數(shù)據(jù)庫(kù)設(shè)計(jì)的方法是什么”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“云原生數(shù)據(jù)庫(kù)設(shè)計(jì)的方法是什么”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享文章：云原生數(shù)據(jù)庫(kù)設(shè)計(jì)的方法是什么
本文URL：http://jinyejixie.com/article14/pgihge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營(yíng)銷、網(wǎng)站維護(hù)、營(yíng)銷型網(wǎng)站建設(shè)、關(guān)鍵詞優(yōu)化、網(wǎng)站改版、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)