敢啃“硬骨頭”，開(kāi)源分布式數(shù)據(jù)庫(kù)TiDB如何煉成？

原創(chuàng)
作者：黃東旭 2018-09-29 09:47:41

運(yùn)維

數(shù)據(jù)庫(kù)運(yùn)維

分布式 如今硬件的性價(jià)比越來(lái)越高，網(wǎng)絡(luò)傳輸速度越來(lái)越快，數(shù)據(jù)庫(kù)分層的趨勢(shì)逐漸顯現(xiàn)，人們已經(jīng)不再?gòu)?qiáng)求用一個(gè)解決方案來(lái)解決所有的存儲(chǔ)問(wèn)題，而是通過(guò)分層，讓緩存與數(shù)據(jù)庫(kù)負(fù)責(zé)各自擅長(zhǎng)的業(yè)務(wù)場(chǎng)景。

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比赤城網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式赤城網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋赤城地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。

【51CTO.com原創(chuàng)稿件】如今硬件的性價(jià)比越來(lái)越高，網(wǎng)絡(luò)傳輸速度越來(lái)越快，數(shù)據(jù)庫(kù)分層的趨勢(shì)逐漸顯現(xiàn)，人們已經(jīng)不再?gòu)?qiáng)求用一個(gè)解決方案來(lái)解決所有的存儲(chǔ)問(wèn)題，而是通過(guò)分層，讓緩存與數(shù)據(jù)庫(kù)負(fù)責(zé)各自擅長(zhǎng)的業(yè)務(wù)場(chǎng)景。

TiDB 作為一款 HTAP 數(shù)據(jù)庫(kù)，在高性能的實(shí)現(xiàn) OLTP 特性基礎(chǔ)之上，也同時(shí)提供基于實(shí)時(shí)交易數(shù)據(jù)的實(shí)時(shí)業(yè)務(wù)分析需求。

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開(kāi)。

在“大數(shù)據(jù)處理技術(shù)”分會(huì)場(chǎng)，PingCAP CTO 黃東旭帶來(lái)了《How can HTAP help you：ATiDB Story》的主題演講。

他分享了 TiDB 的設(shè)計(jì)思路、現(xiàn)實(shí)應(yīng)用場(chǎng)景，以及 TiDB 集群在部署和運(yùn)營(yíng)方面的***實(shí)踐。

什么是 TiDB 數(shù)據(jù)庫(kù)?

TiDB 是一個(gè)數(shù)據(jù)庫(kù)。我們知道市面上有很多類似 MySQL、Oracle 的數(shù)據(jù)庫(kù)。為什么還需要一個(gè)新的數(shù)據(jù)庫(kù)?

相信大家 90% 都使用過(guò) MySQL。但是當(dāng) MySQL 的數(shù)據(jù)量比較大或者說(shuō)并發(fā)開(kāi)始撐不住的時(shí)候，能有什么選擇?

其實(shí)選擇沒(méi)多少。一個(gè)是完全不用 MySQL，而是用 NoSQL。比如說(shuō) HBase 或者 Cassandra 去做數(shù)據(jù)庫(kù)。

但是相應(yīng)的代價(jià)就是失去了 SQL 的復(fù)雜查詢的能力，還有整個(gè) MySQL 的 EcoSystem。

NoSQL 可以帶來(lái)橫向的水平拓展能力，但是會(huì)面臨整個(gè)業(yè)務(wù)代碼的重寫。這在很多場(chǎng)景下是不太現(xiàn)實(shí)的。

所以很多時(shí)候還是得用 MySQL，但是 MySQL 在數(shù)量方面有各種各樣的限制。所以過(guò)去我們能做的事情就是 Sharding，水平分區(qū)，分庫(kù)分表。

但是很多時(shí)候雖然你做了水平切分，分庫(kù)分表，但是 Scale 還是一個(gè)非常大的問(wèn)題。

另外一點(diǎn)比如說(shuō)你用了讀寫分離，或者你可能用了 Cassandra 這樣的最終一次性的系統(tǒng)，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)這個(gè)新支付單是比較大的。

如果你沒(méi)有一個(gè)強(qiáng)一致的、持久化的存儲(chǔ)系統(tǒng)，你的業(yè)務(wù)層的代碼是很難寫的，特別是對(duì)一些金融場(chǎng)景或者說(shuō)對(duì)一致性要求比較高的業(yè)務(wù)。

另外，我們的數(shù)據(jù)倉(cāng)庫(kù)、大數(shù)據(jù)分析的解決方案和數(shù)據(jù)庫(kù)的解決方案中間基本是徹底割裂的。

這兩年大家常用的 RabbitMQ 或者 Kafka 這樣的管道系統(tǒng)，就是嘗試在數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)之間構(gòu)建一個(gè)橋梁。有沒(méi)有辦法能夠把實(shí)時(shí)的 OLAP 直接就在數(shù)據(jù)庫(kù)層面做?

或者說(shuō)現(xiàn)在你用了 MySQL 的 Sharding，要去做一個(gè)簡(jiǎn)單的跨業(yè)務(wù)的 join 的分析，都得把這個(gè)數(shù)據(jù)通過(guò) ETL 導(dǎo)到 Hadoop 或者 data warehouse 里面再去做分析。

維護(hù) ETL 的過(guò)程是一個(gè)比較麻煩的事情。另外一個(gè)問(wèn)題是數(shù)據(jù)分析師可能不是一個(gè)工程師或者說(shuō)一個(gè)技術(shù)很強(qiáng)的人，所以在技術(shù)選型上會(huì)有各種限制。

能不能就直接在數(shù)據(jù)庫(kù)上去做一些 in-place 的查詢呢，這是一個(gè)問(wèn)題。另外一個(gè)就是大的趨勢(shì)，大家都在思考數(shù)據(jù)庫(kù)這樣的業(yè)務(wù)怎么去跟現(xiàn)有云架構(gòu)去整合。

舉例來(lái)說(shuō)你不可能直接把一個(gè) MySQL 實(shí)例放到一個(gè) Container 里面，因?yàn)槿绻?Container 掛了，數(shù)據(jù)就沒(méi)了。

怎么去面向一個(gè)云環(huán)境或者一個(gè)可以彈性伸縮的容器環(huán)境，設(shè)計(jì)一個(gè)可以彈性伸縮的數(shù)據(jù)庫(kù)，這其實(shí)是個(gè)很大的問(wèn)題。

還有一個(gè)特別大的痛點(diǎn)，就是在做高可用的時(shí)候人是會(huì)出錯(cuò)的。我們現(xiàn)在做數(shù)據(jù)庫(kù)碰到這些問(wèn)題的原因是什么呢?

我個(gè)人認(rèn)為關(guān)系型數(shù)據(jù)庫(kù)像 MySQL，Oracle 這些本身不是面向分布式去做設(shè)計(jì)的。

另外，即使你勉強(qiáng)做這個(gè)分庫(kù)分表等操作，本質(zhì)上來(lái)說(shuō)你只是把 MySQL 再?gòu)?fù)制了一遍，并不是針對(duì)它是一個(gè)分布式系統(tǒng)來(lái)做存儲(chǔ)和計(jì)算的優(yōu)化。

這就是問(wèn)題，而這也是為什么我們會(huì)覺(jué)得我在做一些跨業(yè)務(wù)的查詢或者說(shuō)一些跨物理的這個(gè)機(jī)器的查詢和寫入會(huì)比較麻煩的原因。

但是終于這個(gè)情況在發(fā)生變化， 因?yàn)樵?2000 年以后，分布式系統(tǒng)理論開(kāi)始變?yōu)橹髁鳌?/p>

這有一個(gè)歷史發(fā)展的背景，就是過(guò)去硬件價(jià)格昂貴，而且網(wǎng)絡(luò)環(huán)境不好。所以盡可能把計(jì)算給放在本地去做。

因?yàn)?SSD 的出現(xiàn)，現(xiàn)在磁盤 IO 基本上問(wèn)題已經(jīng)不大了，而 Intel 很快會(huì)發(fā)布持久化內(nèi)存。像這種技術(shù)基本上解決了數(shù)據(jù)庫(kù) IO 層上的問(wèn)題。

現(xiàn)在在 Google 內(nèi)部，同一個(gè)數(shù)據(jù)中心內(nèi)讀取遠(yuǎn)程磁盤，跟讀取本地磁盤的吞吐和延遲基本是可以做到一致的。

在這種情況下你可以認(rèn)為整個(gè)數(shù)據(jù)中心就是一臺(tái)計(jì)算機(jī)，你重新去設(shè)計(jì)數(shù)據(jù)庫(kù)的時(shí)候，它本質(zhì)上就是一個(gè)分布式系統(tǒng)。

第三點(diǎn)就是大家的思維在發(fā)生改變，大家不再幻想有一個(gè)***的解決方案去解決掉所有存儲(chǔ)上的問(wèn)題。

易維護(hù)

TiDB 這個(gè)項(xiàng)目是在三年前開(kāi)始的。項(xiàng)目就是上面介紹的背景，我過(guò)去在豌豆莢一直維護(hù) MySQL 集群。

后來(lái)因?yàn)殛P(guān)系型數(shù)據(jù)庫(kù)不易維護(hù)，經(jīng)常想能不能有一個(gè)數(shù)據(jù)庫(kù)可以結(jié)合 MySQL 和 NoSQL 的優(yōu)點(diǎn)。

所以這就是最開(kāi)始的初心，我們要去做一個(gè)功能完備的 SQL，***去兼容現(xiàn)有的，至少是這些常用的復(fù)雜查詢、子查詢業(yè)務(wù)。

然后同時(shí)要以一個(gè) MySQL 的協(xié)議和用法去面向客戶，或者用戶。這一點(diǎn)很重要，它可以極大地降低用戶去試你產(chǎn)品的成本。

事務(wù)

第二點(diǎn)就是事務(wù)，事務(wù)是絕對(duì)不能少的。我覺(jué)得過(guò)去這十年 NoSQL 的社區(qū)有一個(gè)特別大的問(wèn)題就是追求可擴(kuò)展性，但是放棄了強(qiáng)一致事務(wù)的支持，這是不對(duì)的。

過(guò)去不實(shí)現(xiàn)這個(gè)功能的理由是這個(gè)功能會(huì)導(dǎo)致系統(tǒng)延遲，性能下降。但是我覺(jué)得以犧牲數(shù)據(jù)準(zhǔn)確性為代價(jià)去實(shí)現(xiàn)這個(gè)功能是不現(xiàn)實(shí)的。

這就相當(dāng)于本來(lái)這個(gè)事情應(yīng)該數(shù)據(jù)庫(kù)來(lái)做，這些 NoSQL 系統(tǒng)卻強(qiáng)行把這個(gè)事情交給業(yè)務(wù)層做。這會(huì)給寫業(yè)務(wù)帶來(lái)一個(gè)極大的問(wèn)題。

另外一個(gè)就是擴(kuò)展的易用性，就是能不能做到我這里用了一個(gè)詞叫做 push-button scaling。

我簡(jiǎn)單地扔一臺(tái)機(jī)器進(jìn)去，不做任何的 resharding，不做任何的修改配置，這個(gè)系統(tǒng)自己就擴(kuò)大了，自己去做 rebalancing，這跟傳統(tǒng)的 Sharding 方案有本質(zhì)的區(qū)別。

高可用

然后 HA 是什么?HA 就是高可用，這個(gè)問(wèn)題是傳統(tǒng)方案很難解決的。就是一切都是需要人工去做這個(gè)數(shù)據(jù)校驗(yàn)和流量的切換。

沒(méi)有辦法能做到真正的 HA，這個(gè)數(shù)據(jù)庫(kù)能不能自動(dòng)地自己去運(yùn)維、自己去修復(fù)自己，自己去保證這個(gè)系統(tǒng)的可用性。

在這塊我們也做了一些工作，就是我們?cè)诘紫碌恼麄€(gè)數(shù)據(jù)模型完全放棄掉了主從的模型，完全基于 Raft 跟 Paxos 這樣的一種分布式選舉算法來(lái)做。

這個(gè)還比較重要，因?yàn)槿绻粋€(gè)系統(tǒng)你不能保證它的可用性，談再多的性能都是沒(méi)有意義的，特別是對(duì)于 OLTP 系統(tǒng)來(lái)說(shuō)。

我的這個(gè)系統(tǒng)能不能既在上面去支持 ACID 事務(wù)，同時(shí)又可以利用 Spark 或者 Hadoop 去用整個(gè)機(jī)群的計(jì)算資源和能力，再去做一些復(fù)雜的 SQL 查詢的時(shí)候能加速。這個(gè)其實(shí)是可以做到的。

開(kāi)源

***一點(diǎn)就是一定是***開(kāi)源，通用的技術(shù)軟件不開(kāi)源是絕對(duì)沒(méi)有未來(lái)的。

因?yàn)楝F(xiàn)在時(shí)代已經(jīng)變了，過(guò)去那種閉門造車，然后招一大堆銷售，挨家敲門說(shuō)你要不要試一下的搞法是不對(duì)的，特別是平臺(tái)性質(zhì)的軟件。

而且開(kāi)源會(huì)更加有利于去做軟件推廣，你的用戶越多，用戶給你的反饋就越多。

這會(huì)比自己在內(nèi)部去做軟件速度快得多。這也是為什么這個(gè)項(xiàng)目才開(kāi)始三年，我們的客戶就超過(guò)了 2000 多家。

TiDB 數(shù)據(jù)庫(kù)的四大“殺手锏”

現(xiàn)在我來(lái)總結(jié)一下 TiDB 數(shù)據(jù)庫(kù)有哪些應(yīng)用場(chǎng)景可以在你自己的業(yè)務(wù)里面去使用。

用例 1：MySQL 分片與合并

***種場(chǎng)景就是 MySQL，比如已有的業(yè)務(wù)使用了 MySQL Sharding，沒(méi)問(wèn)題?，F(xiàn)在 TiDB 因?yàn)樵跇I(yè)務(wù)層實(shí)時(shí)兼容 MySQL 的這個(gè)訪問(wèn)協(xié)議。

而且我們做了一個(gè)工具 Syncer，它能夠把 TiDB 作為一個(gè) MySQL Master 的 Slave，在業(yè)務(wù)層前端可以是一個(gè)主庫(kù) MySQL，而作為從庫(kù)的 TiDB 可以看做一個(gè)大的 MySQL。

過(guò)去我們有一個(gè)說(shuō)法叫一主多從， 但現(xiàn)在有了 TiDB 以后，可以反過(guò)來(lái)說(shuō)多主一從。

你可以把這多個(gè) MySQL 組的不同的表、不同的業(yè)務(wù)、不同的庫(kù)，實(shí)時(shí)的 Binlog 的數(shù)據(jù)全都同步、匯總到一個(gè)大的分布式的 MySQL 上。

這個(gè)分布式 MySQL 就是 TiDB。在這個(gè) MySQL 之上，你可以去用一些比較復(fù)雜的 Query，比如 join，groupby 全都可以。所以這個(gè)是一種用戶場(chǎng)景。

Syncer 是什么?我剛才簡(jiǎn)單提了下，Syncer 是可以把自己偽裝成一個(gè) MySQL 的 Slave 去做數(shù)據(jù)的同步的工具。

它本質(zhì)上是一個(gè) Binlog Listener，會(huì)去監(jiān)聽(tīng) MySQL 的 Binlog，然后把它變成數(shù)據(jù)庫(kù)的語(yǔ)句。

用例 2：直接替換 MySQL

另外一個(gè)應(yīng)用場(chǎng)景就非常簡(jiǎn)單粗暴，最簡(jiǎn)單的情況是業(yè)務(wù)在快速地增長(zhǎng)，但是原來(lái)業(yè)務(wù)就是 MySQL 寫的，也沒(méi)考慮什么分庫(kù)分表，架構(gòu)這樣的事情。

摩拜早期的時(shí)候就用 MySQL。后來(lái)發(fā)現(xiàn)業(yè)務(wù)開(kāi)始快速增長(zhǎng)，公司在 30 人團(tuán)隊(duì)規(guī)模的時(shí)候開(kāi)始使用 TiDB。

然后一年之內(nèi)整個(gè)公司人數(shù)增長(zhǎng)到 800 人，數(shù)據(jù)從很小的數(shù)據(jù)集到后來(lái)在 TiDB 上有幾十 T 的數(shù)據(jù)，不需要再去做分庫(kù)分表。

所以在業(yè)務(wù)快速增長(zhǎng)的場(chǎng)景下 TiDB 是個(gè)很好的選擇，然后對(duì)于 OLTP 的業(yè)務(wù)來(lái)說(shuō)，TiDB 也是一個(gè)很好的選擇。

對(duì)吞吐來(lái)說(shuō)，TiDB 基本上可以做到線型擴(kuò)張，機(jī)器越多，性能越好。而對(duì)于延遲來(lái)說(shuō)，TiDB 也有非常出色的表現(xiàn)。

用例 3：數(shù)據(jù)倉(cāng)庫(kù)

還有一類使用場(chǎng)景是直接把 TiDB 作為數(shù)據(jù)倉(cāng)庫(kù)用。 TiDB 在 OLAP 的性能測(cè)評(píng)方面表現(xiàn)非常出眾。

如果有一些特別復(fù)雜的 SQL，TiDB 的 SQL 層還是搞不定，我這邊也做了一個(gè)開(kāi)源的項(xiàng)目，叫 TiSpark 。

它其實(shí)是一個(gè) Spark 的插件，能夠讓用戶直接用 Spark SQL 來(lái)實(shí)時(shí)地在 TiKV 上做大數(shù)據(jù)分析。

第三個(gè)應(yīng)用場(chǎng)景，TiDB 本身是一個(gè)存儲(chǔ)跟計(jì)算分開(kāi)的一個(gè)項(xiàng)目。它底下 Key-Value 的那一層也可以單獨(dú)拿出來(lái)用，你可以把它當(dāng)作一個(gè) Hbase 的替代品， 同時(shí)支持跨行的事務(wù)。

TiDB 的項(xiàng)目其實(shí)是受到了 Google Spanner 這個(gè)系統(tǒng)的啟發(fā)，是通過(guò) NoSQL 這一層支持 transaction 的。

TiKV 提供了兩層 API，一層是支持跨行事物 transaction 的 API。第二層 API 叫弱 API，主要用來(lái)做單行的事務(wù)，不提供跨行事務(wù)的 ACID 的支持，但是換取的是整個(gè)性能和延遲的進(jìn)一步提升。

所以如果有需要，事務(wù)可以用 transaction 的 API，如果需要性能，但是沒(méi)有強(qiáng)一致事務(wù)的跨行事務(wù)的需求，就用弱 API。弱 API 跟 Hbase 的一致性級(jí)別是一樣的。

用例 4：作為其他系統(tǒng)的基石

基于通用的 KV 層，我們是可以做到很多我們想做的事情。TiDB 并不只是一個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)項(xiàng)目，它應(yīng)該是其他的分布式系統(tǒng)的 building block，可以作為其他系統(tǒng)構(gòu)建的基石。

TiDB 本身對(duì)外提供的是 MySQL 的接口，但是社區(qū)里面的小伙伴直接去給 TiKV 層去封裝一個(gè) Redis 的協(xié)議層。

然后能讓用戶直接用 Redis 的協(xié)議去做 TiKV。這樣就變成了可持久化的 Scalable 的 Redis。

然后另外一個(gè) Case，是在今日頭條用的，就是對(duì)外提供一個(gè) S3，你想造自己的 S3 沒(méi)有問(wèn)題。

但是造 S3 最難的部分是在源信息管理這塊，并不是它的 data nodes，所以如果你已經(jīng)有了一個(gè)支持跨事務(wù)的一個(gè)源信息存儲(chǔ)系統(tǒng)，你可以做到自己去建造 S3。

我知道已經(jīng)有一些社區(qū)的同學(xué)構(gòu)建一整套新的分布式存儲(chǔ)的服務(wù)，現(xiàn)在 API 還沒(méi)有開(kāi)源，但我覺(jué)得不久的未來(lái)會(huì)開(kāi)源。

如何從 MySQL 遷移到 TiDB?

既然 TiDB 這么好，那現(xiàn)在怎么把 MySQL 遷移到 TiDB 上呢?因?yàn)?TiDB 其實(shí)是基于 MySQL 生態(tài)的，當(dāng)然可以用 MySQLDump。

我們自己做了一個(gè)數(shù)據(jù)的導(dǎo)入導(dǎo)出工具叫 Lightning。為什么要做這個(gè)呢?

比如說(shuō)過(guò)去我們?nèi)绻苯邮怯?MySQL 的協(xié)議，用 MyDumper、Myloader，就是簡(jiǎn)單粗暴的導(dǎo)出導(dǎo)入。

那 TiDB 想要做什么事情呢?因?yàn)榇蠹抑?MyDumper Dump 出來(lái)的就是 MySQL 一條條的語(yǔ)句。

然后在 TiDB 這邊要從 SQL，到它的 parser 到執(zhí)行計(jì)劃、指導(dǎo)事務(wù)、到 KV，***才寫到單機(jī)的 RocksDB 上面。

這個(gè)過(guò)程一遍遍重復(fù)執(zhí)行是一個(gè)很慢的過(guò)程，如下圖：

我們就想，有沒(méi)有辦法能夠直接繞過(guò)中間所有的東西，直接利用 MyDumper Dump 出來(lái)的這個(gè) SQL 語(yǔ)句直接生成底下的 RocksDB 的數(shù)據(jù)的格式呢?當(dāng)然可以。

所以這就是 Lightning 在做的事情。你可以認(rèn)為這是一個(gè)升級(jí)版的 MySQLDumper，直接 Dump 出 SQL 語(yǔ)句。

然后我們?cè)?TiDB Lightning 這個(gè)項(xiàng)目?jī)?nèi)部直接去做了這個(gè) Record to KV，就是直接生成底層的 key-value pairs。然后同時(shí)在內(nèi)部去做數(shù)據(jù)分片，提前分好。

第三個(gè)就是直接去繞過(guò)中間所有的這些 SQL，直接去生成 RocksDB 的 SSD 文件，相當(dāng)于存儲(chǔ)的格式文件發(fā)送給不同的機(jī)器。然后這個(gè)機(jī)器直接去把文件 Load 到數(shù)據(jù)庫(kù)里面就完成了，中間其實(shí)是很快的。

部署 TiDB，我們選的技術(shù)方案是 Ansible，所有的部署都是可以一鍵完成。然后包括性能調(diào)優(yōu)什么的完全是開(kāi)源的。

我們目前正在把 TiDB 這個(gè)項(xiàng)目捐給 CNCF 基金會(huì)，正在跟 Kubernetes 進(jìn)行整合，現(xiàn)在正在測(cè)試階段，未來(lái)肯定也會(huì)開(kāi)源。

當(dāng)然，如果你說(shuō)想在本地自己去玩一玩，但是 TiDB 這么多組件，我能不能用一條命令就能在本地搭建一個(gè)完整的 TiDB Cluster 去做測(cè)試呢?當(dāng)然可以。

我們這邊是有 Docker Compose，是兩條路徑，一條是 git clone，然后第二條是啟動(dòng)。

它會(huì)啟動(dòng)包括 Dashboard，數(shù)據(jù)的遷移、可視化，TiDB MySQL 的 Service endpoint、TiSpark 全都會(huì)在你的 Docker Container 去創(chuàng)建。

另外這還不夠，我們把一些核心算法通過(guò)數(shù)學(xué)的方式去形式化地證明它是正確的。

這個(gè) TLA+ 的源碼文件開(kāi)源了，大家如果想在自己的分布式系統(tǒng)里面去用 TLA+ 做數(shù)學(xué)上的證明，你可以去參考我們寫的文檔。所以我覺(jué)得測(cè)試反而是這個(gè)公司最重要的一塊資產(chǎn)。

總結(jié)

***，有幾個(gè)大的問(wèn)題也是這段時(shí)間我思考得比較多的，比如說(shuō)你整個(gè)集群云化了以后，在數(shù)據(jù)庫(kù)的層面上 Multi—tenancy 該怎么做?就是如何能去做到更有效的資源隔離和復(fù)用?

現(xiàn)在并沒(méi)有太好的解決方案，因?yàn)檎麄€(gè) IO 的隔離還是比較大的問(wèn)題。

第二個(gè)就是自治，這個(gè)數(shù)據(jù)庫(kù)能不能擁有智能，就是我再不需要人工去做運(yùn)維。

這個(gè)數(shù)據(jù)庫(kù)能夠自己部署，自己維護(hù)，自己更新。然后數(shù)據(jù)出現(xiàn)問(wèn)題，自己修復(fù);性能出現(xiàn)問(wèn)題，自己調(diào)優(yōu)。

我們也在嘗試去把一些我們運(yùn)營(yíng)時(shí)的 Metric 往 Tensorflow 里面去導(dǎo)，自動(dòng)地去做調(diào)優(yōu)。這個(gè)工作正在做，然后應(yīng)該 CMU 是一些比較有意思的工作。

還有就是軟硬件的結(jié)合，就是說(shuō)怎么去利用這些新時(shí)代的硬件來(lái)提升你的整個(gè)數(shù)據(jù)庫(kù)的穩(wěn)定性能。

黃東旭，PingCAP 的聯(lián)合創(chuàng)始人兼***技術(shù)官。他是分布式系統(tǒng)和數(shù)據(jù)庫(kù)開(kāi)發(fā)方面的專家。他在分布式存儲(chǔ)方面擁有豐富的經(jīng)驗(yàn)和獨(dú)特的見(jiàn)解。他是 Codis(一種常用的分布式 Redis 緩存解決方案)和 TiDB(一種分布式關(guān)系型數(shù)據(jù)庫(kù))的聯(lián)合創(chuàng)始人。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

網(wǎng)頁(yè)題目：敢啃“硬骨頭”，開(kāi)源分布式數(shù)據(jù)庫(kù)TiDB如何煉成？
本文網(wǎng)址：http://www.dlmjj.cn/article/dhegjcp.html