7月28日，以“科技，洞見未來”為主題的 QingCloud Insight 2016大會(huì)將在北京召開，連接云計(jì)算產(chǎn)業(yè)鏈上下游，展示 IT 領(lǐng)域最新研發(fā)成果。作為 NewSQL 技術(shù)的代表，PingCAP 聯(lián)合創(chuàng)始人&CEO 劉奇將在本次大會(huì)上講述開源數(shù)據(jù)庫 TiDB 的設(shè)計(jì)與研發(fā)技術(shù)細(xì)節(jié)。在云和大數(shù)據(jù)時(shí)代，數(shù)據(jù)庫領(lǐng)域發(fā)生了什么？新應(yīng)用需要什么樣的數(shù)據(jù)庫？開發(fā)者需要哪些新技術(shù)？劉奇日前接受 CSDN 記者的專訪，從 TiDB 的研發(fā)開始，就傳統(tǒng)數(shù)據(jù)庫面臨的挑戰(zhàn)，新型數(shù)據(jù)庫的特性，開源模式的優(yōu)勢，TiDB 的研發(fā)進(jìn)展，以及數(shù)據(jù)庫與云計(jì)算資源更好配合的方式等問題進(jìn)行深入解析。
　　
　　PingCAP聯(lián)合創(chuàng)始人兼CEO劉奇
　　劉奇，PingCAP 聯(lián)合創(chuàng)始人兼 CEO，先后創(chuàng)建了 TiDB、Codis 等知名開源項(xiàng)目。曾任豌豆莢、京東資深系統(tǒng)架構(gòu)師。同時(shí)也是知名的 Go 語言專家和 Redis 專家?，F(xiàn)從事開源的分布式 NewSQL 數(shù)據(jù)庫 TiDB（受 Google F1 啟發(fā)）的開發(fā)。擅長高并發(fā)、大規(guī)模、分布式數(shù)據(jù)庫系統(tǒng)架構(gòu)設(shè)計(jì)。
　　數(shù)據(jù)庫領(lǐng)域的變化
　　CSDN：首先談?wù)勀?QingCloud Insight 2016 上的分享話題。
　　劉奇：我會(huì)講怎么去構(gòu)建一個(gè)分布式數(shù)據(jù)庫，主要是介紹我們是怎么實(shí)現(xiàn) TiDB 的。經(jīng)過大約一年半的研發(fā)，TiDB 現(xiàn)在已經(jīng)發(fā)布了 Beta 1版本，進(jìn)入一個(gè)快速迭代的周期，預(yù)期在三個(gè)月內(nèi)能迭代到一個(gè) GA 的版本。作為一個(gè)數(shù)據(jù)庫產(chǎn)品，我們對 TiDB 進(jìn)行嚴(yán)格的測試，以保證數(shù)據(jù)不會(huì)出問題。
　　CSDN：哪些人應(yīng)該了解這個(gè)內(nèi)容？
　　劉奇：DBA、系統(tǒng)架構(gòu)師、CTO 甚至 CIO，因?yàn)樗麄冃枰私釪atabase 對于企業(yè)真正的價(jià)值。不同數(shù)據(jù)的重要性是不一樣的，核心價(jià)值的數(shù)據(jù)永遠(yuǎn)不能丟失。比如說銀行，最核心的可能就是賬號(hào)、存款這些金融相關(guān)的這些數(shù)據(jù)，其次就是和業(yè)務(wù)相關(guān)的，再次就是一些日志。
　　CSDN：金融等行業(yè)核心有傳統(tǒng)關(guān)系型數(shù)據(jù)庫，也在針對不同數(shù)據(jù)嘗試 NoSQL，為什么還需要 TiDB 這樣的 NewSQL 技術(shù)？
　　劉奇：銀行其實(shí)也面臨互聯(lián)網(wǎng)轉(zhuǎn)型的壓力，傳統(tǒng)數(shù)據(jù)庫經(jīng)過這么多年，已經(jīng)不能適應(yīng)現(xiàn)在轉(zhuǎn)型期用戶數(shù)據(jù)增長的速度，也不能很好地支持跨數(shù)據(jù)中心多活——熱備都是比較過時(shí)的技術(shù)。當(dāng)然銀行在很大程度上還要考慮風(fēng)險(xiǎn)，即使有一個(gè)新的數(shù)據(jù)庫，他們也很難在短時(shí)間內(nèi)將其部署到最核心的業(yè)務(wù)，但是可以先從外圍開始測試，體驗(yàn)分布式帶來的好處，支持業(yè)務(wù)快速地往前發(fā)展。
　　CSDN：不僅 TiDB，很多分布式的數(shù)據(jù)庫都采用開源的模式，為什么這個(gè)領(lǐng)域這么喜歡開源？
　　劉奇：首先，數(shù)據(jù)庫可以分為 OLAP 和 OLTP 兩大類，OLAP 對于數(shù)據(jù)的安全性重視程度沒有 OLTP 那么高，丟失幾條數(shù)據(jù)對于用戶行為分析而言關(guān)系不大。目前開源領(lǐng)域以 OLAP 居多，因?yàn)閷?shí)現(xiàn)難度和風(fēng)險(xiǎn)更小，但是真正往 OLTP 上走是非常困難的。實(shí)際上，在 Google Spanner 論文出來之前，就沒有真正的大規(guī)模 OLTP 分布式數(shù)據(jù)庫，OLAP 的系統(tǒng)可以輕松擴(kuò)展到兩百臺(tái)機(jī)器，但 OLTP 數(shù)據(jù)庫能上到兩百臺(tái)機(jī)器是非常罕見的，以前也沒有什么特別好的技術(shù)。被 Apple 收購用于提供 Apple 內(nèi)部服務(wù)的 FoundationDB，也就能 Scale 到一百臺(tái)左右的規(guī)模。很多同行都走了很多的彎路，Spanner 一出，架構(gòu)就得跟著重新去改。
　　而使用開源數(shù)據(jù)庫，無論是從被綁架的風(fēng)險(xiǎn)，還是說靈活程度，可擴(kuò)展性，甚至是和其他工具的整合，都有明顯的優(yōu)勢。
　　首先是不會(huì)被某個(gè)數(shù)據(jù)庫綁架。其次，開源是大家協(xié)作的一個(gè)系統(tǒng)，通常你遇到問題很有可能被別人 Fix 掉了，而且你也有很多地方可以交流經(jīng)驗(yàn)。同時(shí)，很多人會(huì)參與貢獻(xiàn)，哪怕是一點(diǎn)小需求，只要用的人足夠多，官方一般都會(huì)接納——就算官方不接納，你也可以 Fork 一些分支完成自己的需求，這是商業(yè)數(shù)據(jù)庫不可能做得到。另外是和其他開源工具的整合，開源對開源一般都會(huì)很友好，比如整個(gè)阿帕奇社區(qū)幾乎所有的東西都可以很好地整合，Hadoop、Spark、Flink 最終會(huì)形成一個(gè)相互依存、良性競爭的超級(jí)大的生態(tài)。
　　TiDB 的研發(fā)思路
　　CSDN：談到 Google Spanner 的論文，TiDB 在哪些方面借鑒了它的設(shè)計(jì)，哪些方面是有獨(dú)到的一些創(chuàng)意？
　　劉奇：TiDB 大量地借鑒了 Google 的論文，也做了很多自己的改進(jìn)。比如說：
　　Google 使用的是 tech source，盡管有其他的實(shí)現(xiàn)，但沒有一個(gè)真正受過大規(guī)模生產(chǎn)環(huán)境的考驗(yàn)。我們在協(xié)議上選擇的 Raft，也是經(jīng)過了非常嚴(yán)峻的生產(chǎn)環(huán)境的考驗(yàn)，比如 etcd 、Hashicorp 都在用 Raft，大家還有很多基于 Raft 專門造的各種輪子，同時(shí) Raft 性能和 Paxos 差不多，但簡潔性是后者所不具備的。
　　關(guān)于協(xié)議，還有 Google 內(nèi)部使用了自己的 ORM，而我們兼容的是 MySQL 協(xié)議，在易用性上比 Spanner 或者說比 F1 要好很多，用戶不需要重新學(xué)一套新的東西就可以直接用；我們接下來還會(huì)支持 MySQL 的 Documents store，用起來就更爽了。
　　另外在整個(gè)架構(gòu)上，Google 依賴自己的 Colossus 分布式文件系統(tǒng)，而我們是不依賴的。如果依賴一個(gè)分布式文件系統(tǒng)，用戶需要多部署一個(gè)新的組件，同時(shí)也會(huì)造成一定的 latency 上升，這是我們不希望看到的。
　　再一個(gè)比較重要的改進(jìn)就是原子鐘，這是 Spanner 最強(qiáng)的地方—— Google 內(nèi)部有一個(gè)原子鐘加 GPS 時(shí)鐘，組成一套精確的時(shí)鐘系統(tǒng)，這在外面是沒有的。我們在事務(wù)模型上面使用了 Percolator，是 Google 之前發(fā)表的另一篇論文里提到的一個(gè)增量處理的事務(wù)模型，這也是外面沒有原子鐘的變通方案。
　　CSDN：能否解釋具體是怎么實(shí)現(xiàn)的？
　　劉奇：按照原來的 Percolator，會(huì)有一個(gè) Server 提供直接時(shí)鐘服務(wù)，也就是單調(diào)遞增的時(shí)間戳的分配，它本身是高可用的，通常會(huì)部署三到五個(gè)副本，大概每秒可以分配四百萬到八百萬個(gè)時(shí)間戳。從目前的需求來看，每秒四百萬個(gè)時(shí)間戳是綽綽有余的，這是在沒有原子鐘的時(shí)候的一個(gè)替代方案。另外一個(gè)方案就是 HLC，但 HLC 如果要保證線性隔離級(jí)別，需要設(shè)置一個(gè)時(shí)鐘適中的精度，但是沒有云廠商明確說時(shí)鐘精度一定保持在什么范圍。這是一個(gè)比較大的問題，如果時(shí)鐘精度超出這個(gè)范圍，結(jié)果就是錯(cuò)的。我們不想因?yàn)闀r(shí)鐘精度造成用戶數(shù)據(jù)出錯(cuò)的可能，所以就選擇一個(gè)更加穩(wěn)定的一個(gè)方案。HLC 也是Kudu 和 CockroachDB 采用的幾乎同時(shí)發(fā)表的技術(shù)極為相似的兩篇論文。
　　CSDN：兼容 MySQL 的方式是業(yè)界通用的做法嗎？
　　劉奇：不是，主流做法是我搞一套我自己的，讓用戶切進(jìn)來，這對于新東西的推廣的壓力非常大。兼容它很重要一點(diǎn)是數(shù)據(jù)庫的測試，我們現(xiàn)在測試用例都是用幾百萬級(jí)的，600 多萬個(gè) Tests，可以把 MySQL 的兼容，大量 Test 拿過來用來測試，如果靠人去構(gòu)建這個(gè) Test 基本上是不現(xiàn)實(shí)的事情。MySQL 已經(jīng)是一個(gè)很好的平臺(tái)，融入平臺(tái)，可以讓大量已有的生產(chǎn)力得到發(fā)揮。如果不能很好地兼容這個(gè)平臺(tái)上所有的東西，反而自己去建立一個(gè)平臺(tái)，周期是很嚇人的。
　　CSDN：會(huì)追的最新版本的 MySQL 嗎？
　　劉奇：我們現(xiàn)在追的是 5.6，因?yàn)?5.7 的官方也還在快速的更新，比如說5.7推出的 Documents store，現(xiàn)在還沒有用戶，我們這時(shí)候去支持它是沒有太大的意義。我們做一個(gè)東西一定是滿足用戶需求，然后兼容協(xié)議，對用戶來說遷移特別簡單，就比如說現(xiàn)在直接測試。
　　CSDN：是否需要開發(fā)一些專用的工具來支持 MySQL 到 TiDB 的遷移？
　　劉奇：不需要其他所謂的第三方工具，直接使用任何已有的 MySQL備份、恢復(fù)工具就可以了。我們現(xiàn)在的測試都是直接把 MySQL 數(shù)據(jù)導(dǎo)出來，導(dǎo)入到 TiDB，再拿 TiDB 的數(shù)據(jù)導(dǎo)回 MySQL，完全不需要任何新的工具。絕大多數(shù)時(shí)候一行代碼都不改，立刻可以獲得所有的新特性和分布式的優(yōu)勢。
　　CSDN：傳統(tǒng)的 DB2、Oracle 的遷移也是一樣簡單的嗎？
　　劉奇：這個(gè)事情就比較麻煩了，因?yàn)槲覀儾⒉患嫒葸@個(gè) Oracle，也不兼容 DB2，而且它們互相也不兼容。這時(shí)候用戶如果要遷移，用戶需要改它的 SQL，需要改掉存儲(chǔ)過程，因?yàn)槲覀儾恢С执鎯?chǔ)過程、觸發(fā)器這些前兩代單機(jī)數(shù)據(jù)庫的技術(shù)，對一個(gè)分布式系統(tǒng)來說，如果在這個(gè)地方寫個(gè)存儲(chǔ)過程，這個(gè)存儲(chǔ)過程訪問的數(shù)據(jù)，又跑在其他的機(jī)器上面，這個(gè)時(shí)候存儲(chǔ)過程的理解，和用戶對于前面兩代的傳統(tǒng)數(shù)據(jù)庫技術(shù)的理解是不一樣的，那按照它前面這個(gè)思路去寫現(xiàn)在這個(gè)程序有可能會(huì)出現(xiàn)一個(gè)比較大的問題。所以傳統(tǒng)像 DB2，Oracle 遷過來是稍微有點(diǎn)麻煩的，就是他們需要自己去改 SQL。
　　CSDN：對 NoSQL 端的兼容有什么樣的計(jì)劃？
　　劉奇：我們不考慮兼容 NoSQL（當(dāng)然用戶可以自己去修改兼容MongoDB 或者 HBase 的 API）。NoSQL 已經(jīng)是上一代的技術(shù)，我們沒有必要在上面再做太多的別的一些東西，直接跳到 NewSQL 這一代就可以了。國外有人在 PostgresSQL 上做一套 MongoDB 的兼容，我們認(rèn)為沒什么意義。而我們兼容 MySQL 協(xié)議，是給 MySQL 提供了很多原本不能夠?qū)崿F(xiàn)的東西，比如說異地多活，跨數(shù)據(jù)中心復(fù)制和容災(zāi)，水平伸縮。
　　CSDN：水平伸縮能夠支持多大的規(guī)模？
　　劉奇：我們的設(shè)計(jì)，單個(gè)數(shù)據(jù)庫支持千級(jí)別的機(jī)器，如果超過這個(gè)數(shù)量可以重新再布一個(gè)新的實(shí)例，又可以支持這種千級(jí)別的機(jī)器。但目前還沒有找到這么大的業(yè)務(wù)。
　　CSDN：目前有如何商業(yè)化的考慮嗎？
　　劉奇：TiDB 的核心技術(shù)是完全開源的，但我們將來會(huì)提供企業(yè)版。我們有一個(gè) On-Premise 的版本 ，提供的一些監(jiān)控和管理工具，這些工具就不需要開源了。這其實(shí)也是目前開源數(shù)據(jù)庫的主流做法。比如 MongoDB，它的核心東西都是開源的，一般用戶從來不用考慮付費(fèi)問題，但是它會(huì)給企業(yè)用戶提供一套收費(fèi)的非常漂亮的管理界面，這是一個(gè)主流的收費(fèi)模式。另外還可以給用戶提供技術(shù)支持和維護(hù)的服務(wù)，以及咨詢服務(wù)。開源不影響賣 License，我們?nèi)匀粸槠髽I(yè)提供 License 授權(quán)。
　　云計(jì)算環(huán)境的整合
　　CSDN：開源分布式數(shù)據(jù)庫想要在云上做為一個(gè)服務(wù)提供給用戶和開發(fā)者，最重要的工作是什么呢？
　　劉奇：對用戶體驗(yàn)最好的，肯定是和云做深度整合，用戶不需要關(guān)心新啟一個(gè)機(jī)器這種細(xì)節(jié)，只要設(shè)定一個(gè)配額，容量不夠的時(shí)候自動(dòng)給我擴(kuò)容就好了（同時(shí)發(fā)郵件通知），這樣 易用性是最友好的，這在國外也比較常見，可以保證業(yè)務(wù)完全不停，國內(nèi)很多上第三方市場的方式，就沒有和云做深度整合，易用性相對還是弱一點(diǎn)。
　　CSDN：要滿足異地多活等特性，TiDB 對云資源的使用上遇到過一些問題呢？
　　劉奇：異地多活，起碼異地之間的 latency 不能太大，否則用戶一個(gè)正常請求，盡管 TiDB 是采用 Raft 這樣的多數(shù)派復(fù)制的方案，復(fù)制到多個(gè)數(shù)據(jù)中心延遲就比較大了，像 Spanner 可能在百毫秒級(jí)別的，它最夸張業(yè)務(wù)會(huì)復(fù)制五到七個(gè)副本，分布在五個(gè)不同的地區(qū)?，F(xiàn)在國內(nèi)的普遍做法是同城異地，同城機(jī)房可以保持很好的同步，因?yàn)?latency 特別小，異地的機(jī)房之間仍然保證不中斷業(yè)務(wù)，但 latency 會(huì)上來。
　　CSDN：異地同步可以交給云來自動(dòng)做嗎？
　　劉奇：這個(gè)顯然要由數(shù)據(jù)庫層來做，因?yàn)橹挥袛?shù)據(jù)庫層才知道這事該怎么做，否則底下的存儲(chǔ)層很難做出最優(yōu)雅的決定，比如說沒有這個(gè)數(shù)據(jù)庫之前，MySQL 在云上是沒有辦法 scale 的。但是云可以提供很好的支撐，比如說拉專線讓 latency 變小，相當(dāng)于從硬件層解決問題。簡單來講，數(shù)據(jù)庫可能是造車的，機(jī)房的專線就相當(dāng)于一條高速公路，因?yàn)樗?latency 很小，很適合數(shù)據(jù)庫做異地多活。
　　CSDN：硬件層的故障對 CAP 的影響，要通過什么方式來解決呢？
　　劉奇：我們使用 Raft 的協(xié)議，容災(zāi)的能力就是二分之 N（N 為奇數(shù)），最多不超過二分之 N 的機(jī)器掛掉時(shí)候可以正常使用，所以在云上面，如果說一個(gè)機(jī)器掛掉，對于整個(gè)系統(tǒng)是沒有影響的，或者一個(gè)機(jī)器網(wǎng)絡(luò)出了問題，它被隔離掉也沒有影響。機(jī)制上它并不依賴與云給它提供的穩(wěn)定性和安全性，這個(gè)協(xié)議本身就負(fù)責(zé)保證它的穩(wěn)定性和安全性。
　　CSDN：TiDB 要部署到云上，對于下層 IaaS 的需求就是一個(gè)高速公路嗎？
　　劉奇：主要就是高速公路，另外對機(jī)器或者容器的彈性支持，因?yàn)閿?shù)據(jù)庫擴(kuò)容的前提，是新加一個(gè)機(jī)器，必須要給我提供一個(gè) API，或者提供API 讓我馬上加個(gè) Container，無所謂是 Docker 還是 Rocket。
　　CSDN：開源分布式數(shù)據(jù)庫未來一定要和 Container 結(jié)合嗎？
　　劉奇：結(jié)合是肯定的事情。未來分布式數(shù)據(jù)庫會(huì)往多租戶的方向走，但是目前對多租戶還沒有很好的技術(shù)支持，這時(shí)候怎么去做隔離，容器化是個(gè)很好的思路。但是分布式數(shù)據(jù)庫也不是簡單的容器化的問題，因?yàn)樗桓綦x在很多機(jī)器上面，它的配額，或者說它的請求，時(shí)時(shí)刻刻都在變，你對它的約束必須是在整個(gè)系統(tǒng)級(jí)別的約束，而不是單機(jī)上的約束。未來的程序一定是跑在容器里面的，但是存儲(chǔ)可能掛在容器外面。目前我們已經(jīng)初步完成了跟 Kubernetes 的整合，還在做進(jìn)一步的測試。目前我們希望很好地跟 Kubernetes 或者跟 OpenStack 整合。我們有 Dockerfile，可以直接通過 Container 部署，很多熱愛開源的開發(fā)者希望自己去編譯，也支持直接 apt-get、RPM 來安裝。
　　開發(fā)工具與難點(diǎn)
　　CSDN：使用 Golang 開發(fā)的是因?yàn)槟瞄LGo嗎？
　　劉奇：我擅長 Go，也擅長 Rust，但我之前寫了六七年的 C++，再之前大概寫了兩年的 C、一年的匯編，中間還寫過大概半年的 C#，C++ 是用得最久的。但 TiDB 其實(shí)是兩層，包括 SQL 層的 TiDB 和 KV 層的 TiKV，分別對應(yīng)著 Google 的 F1 和 Spanner。TiDB 之所以用 Go 開發(fā)是因?yàn)殚_發(fā)速度快——實(shí)現(xiàn) MySQL 兼容需要非常大的工作量（目前為止還沒有完全實(shí)現(xiàn)兼容），需要選好開發(fā)語言讓我們很快地適應(yīng) MySQL 的變化。另外，TiKV 是用 Rust 寫的，Rust 的性能非常好，可以滿足 KV 操作的需求；同時(shí)它沒有 GC，可以避免了 Go 語言里面本身存在的一些問題；此外 Rust 對錯(cuò)誤檢查又嚴(yán)格無比，這對一個(gè)非常重視質(zhì)量的項(xiàng)目來說非常重要，可以很好地解決了這個(gè)多線程數(shù)據(jù)競爭等問題。
　　CSDN：Go的 GC 問題如何解決呢？
　　劉奇：在壓力大時(shí)候，GC 就是個(gè)問題，這需要去不斷地優(yōu)化。我們整個(gè)系統(tǒng)的實(shí)現(xiàn)，減少內(nèi)存的分配、重用對象等常規(guī)的優(yōu)化 GC 的算法都用的上。
　　CSDN：到目前為止，開發(fā)過程中最耗費(fèi)精力的是哪一項(xiàng)工作呢？
　　劉奇：應(yīng)該是測試。分布式系統(tǒng)的測試本身就非常困難，對數(shù)據(jù)庫的測試要求就更高了，必須要非常嚴(yán)謹(jǐn)?shù)刈鏊械目赡苄缘臏y試，我們需要有工具不斷地去模擬機(jī)器掛掉、網(wǎng)絡(luò)斷開、磁盤損壞/變慢、程序被kill等所有的故障，我們現(xiàn)在有 Test 不間斷地殺程序，殺完之后馬上檢查數(shù)據(jù)有沒有丟，以保證無論出現(xiàn)什么極端的情況，數(shù)據(jù)都是正確的、完整的，這種測試是非常重要。然后我們還同時(shí)跑著幾百萬個(gè) Test，目前也是分布式在跑。我們有很多關(guān)于分布式系統(tǒng)的論文，但是關(guān)于分布式系統(tǒng)的測試的論文其實(shí)很少，高質(zhì)量的就更少，Google 也沒有告訴大家說 Spanner、F1 到底怎么做的 Test，外面的經(jīng)驗(yàn)跟 Google 還是有差距的。
　　TiDB 的適用場景
　　CSDN：測試如此重要，那不同行業(yè)的數(shù)據(jù)庫應(yīng)用場景千差萬別，我們是要把所有的方向都測試，還是說目前有些側(cè)重的場景？
　　劉奇：首先我們能夠支持傳統(tǒng)的 sysbench 之類的常規(guī)測試。至于各種行業(yè)的不同應(yīng)用類型，我們不可能完全測試到。我們這邊模擬的方案，和用戶那邊實(shí)際報(bào)過來的 case，以及用戶提供的數(shù)據(jù)，我們都會(huì)進(jìn)行統(tǒng)一的測試。但是開源帶來的好處，是用戶可以下載幫我們做測試。
　　CSDN：你認(rèn)為哪些場景、哪些應(yīng)用應(yīng)該使用 TiDB ？
　　劉奇：在數(shù)據(jù)庫上遇到瓶頸的地方都可以。數(shù)據(jù)庫不應(yīng)該是卡住業(yè)務(wù)的瓶頸，當(dāng)業(yè)務(wù)在快速發(fā)展的時(shí)候，如果這數(shù)據(jù)庫遇到了性能問題、擴(kuò)展性、數(shù)據(jù)保護(hù)等問題，需要多數(shù)據(jù)中心的容災(zāi)能力，這個(gè)時(shí)候可以上 TiDB。不一定是場景驅(qū)動(dòng)，只要數(shù)據(jù)庫真的遇到問題，就可以上一個(gè)更好的數(shù)據(jù)庫。
　　CSDN：采用 TiDB 之前，應(yīng)該做哪些準(zhǔn)備工作？
　　劉奇：如果是 MySQL，那比較簡單，可以拿真實(shí)數(shù)據(jù)直接去測試，可以像互聯(lián)網(wǎng)應(yīng)用常規(guī)做法，先導(dǎo)一部分流量進(jìn)來，可以很好做一個(gè)雙寫，去驗(yàn)證這個(gè)系統(tǒng)，并保持這種狀態(tài)持續(xù)一定的時(shí)間。然后如果不是MySQL，可能就需要先轉(zhuǎn)化到 MySQL 這種語句，最好是拿自己實(shí)際業(yè)務(wù)去測試，這樣發(fā)現(xiàn)問題也比較聚焦，不建議只是簡單地 bench 一下。
?

普通下載普通下載

相關(guān)電子資料下載

• 多方位優(yōu)化！憶聯(lián)分布式數(shù)據(jù)庫存儲(chǔ)解決方案，助力MySQL實(shí)現(xiàn)高性能、低時(shí)延 357
• **分布式數(shù)據(jù)庫|數(shù)據(jù)庫數(shù)據(jù)類型** 157
• 數(shù)字化轉(zhuǎn)型下我國分布式數(shù)據(jù)庫應(yīng)用挑戰(zhàn)及發(fā)展建議 213
• 華為云新一代分布式數(shù)據(jù)庫GaussDB正式發(fā)布 521
• 華為新一代分布式數(shù)據(jù)庫GaussDB向全球客戶提供服務(wù) 223
• 華為云新一代分布式數(shù)據(jù)庫GaussDB，給世界一個(gè)更優(yōu)選擇 386
• 如何對全國分布式數(shù)據(jù)庫機(jī)房動(dòng)環(huán)進(jìn)行監(jiān)控和報(bào)警 59
• 美國數(shù)倉巨頭退出中國 國產(chǎn)新一代分布式數(shù)據(jù)庫開啟達(dá)夢新紀(jì)元 209
• 低延遲的分布式數(shù)據(jù)庫架構(gòu)對于新興的霧應(yīng)用程序至關(guān)重要 250
• 榮膺桂冠！中興GoldenDB蟬聯(lián)中國金融級(jí)分布式數(shù)據(jù)庫第一 640