相比于 Intel 的 x86-64 架構(gòu)，ARM 架構(gòu)雖然作為后來者，但在服務(wù)器領(lǐng)域也開始在不停地攻城拔寨，很多企業(yè)也開始將自己的服務(wù)遷移到 ARM 架構(gòu)上面，自然，對于 TiDB 來說，大家也想將 TiDB 運(yùn)行到 ARM 上面。因?yàn)?AWS 上面直接提供了 ARM 機(jī)型，所以我們決定先嘗試在 AWS 的 ARM 上面編譯運(yùn)行 TiDB。
目前創(chuàng)新互聯(lián)建站已為上1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站托管、服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計(jì)、四方臺網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
TiDB 主要包含三個組件 - PD，TiKV 和 TiDB，對于 PD 和 TiDB 來說，使用的是 Go 進(jìn)行編譯的，所以我們只需要在 ARM 機(jī)器上面裝好 Go 的版本就可以了。這里，我使用的是 go1.12.6.linux-arm64 這個版本。
用 Go 編譯 TiDB 和 PD 比較容易，中途遇到了一個 TiDB 的編譯問題，只需要升級下 vendor 就解決了。
編譯 TiKV 就比較麻煩了，因?yàn)槲覀兪褂玫氖?CentOS 系統(tǒng)，系統(tǒng)用 yum 就能安裝相關(guān)的依賴，除了 cmake3 ，裝 cmake 需要做如下處理：
當(dāng)然，編譯 RocksDB 還有 Titan 的時候還遇到了一些錯誤，不過多數(shù)就是傳遞編譯參數(shù)的時候需要處理下 ARM64 相關(guān)的選項(xiàng)，并不是特別的困難。
總的來說，編譯并沒有花太多的時間，這里有一個 腳本 ，大家可以自行去看如何在 ARM64 上面編譯 TiDB。對于運(yùn)行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。
編譯好了 ARM64 的版本，自然就是測試了，這里我使用了 go-ycsb 進(jìn)行了簡單的測試，這里我使用的是 16c32g 的 ARM64 機(jī)器，順帶也開了一臺同配置的 x86 作為對比。
在每臺測試機(jī)器上面，啟動一個 PD，一個 TiKV，使用的是默認(rèn)配置，然后 go-ycsb 使用 100 并發(fā)，導(dǎo)入 1 百萬數(shù)據(jù)，操作次數(shù) 1 百萬，batch size 為 0。
結(jié)果如下：
可以看到，ARM 的機(jī)器性能比 x86 的差了很多，需要來優(yōu)化了。在網(wǎng)上找了這篇 文章 ，使用了上面的腳本，但發(fā)現(xiàn)沒有什么變化。在這個腳本里面，主要的優(yōu)化就是將網(wǎng)卡中斷的處理綁定到某一個 CPU 上面，然后將 RPS 分散到不同的 CPU。對于 16c32g 的機(jī)器來說，這個腳本將網(wǎng)卡中斷的處理綁定到 CPU core 0 和 8 上面，然后把 RPS 分散到所有的 CPU 上面，但是我通過 mpstat 發(fā)現(xiàn)，core 0 和 8 幾乎被打滿：
于是我重新調(diào)了下，將 RPS 分散到除開 core 0 和 8 的地方：
然后 OPS 稍微提升了一點(diǎn)，但 CPU core 0 和 8 仍然是瓶頸。而這個瓶頸明顯是網(wǎng)絡(luò)處理造成的，直觀的優(yōu)化就是減少網(wǎng)絡(luò)消息的處理，于是將 batch size 設(shè)為 128，可以發(fā)現(xiàn)在 ARM 上面性能提升很多，譬如對于 workload C，OPS 能提升到 118270。但即使這樣，CPU core 0 和 8 還是會成為瓶頸。
對比 ARM，x86 下面 CPU 的分配明顯的均勻很多：
所以后面我們要考慮的事情就是如何讓 ARM 能更好的處理網(wǎng)絡(luò)消息。
上面簡單的說了一下如何在 ARM 上面編譯運(yùn)行 TiDB，以及一些調(diào)優(yōu)策略。個人認(rèn)為，雖然 ARM 在性能上面還趕不上相同配置的 x86，但低功耗，成本這些是一個非常大的優(yōu)勢，加上很多不可說的原因，個人認(rèn)為會有越來越多的企業(yè)使用 ARM，所以這塊也會是趨勢。
1、對硬盤要求很高，沒上SSD硬盤的不建議使用
2、不支持分區(qū)，刪除數(shù)據(jù)是個大坑。
解決方案：set @@session.tidb_batch_delete=1;?
3、插入數(shù)據(jù)太大也會報(bào)錯
解決方案：set @@session.tidb_batch_insert=1;?
4、刪除表數(shù)據(jù)時不支持別名
delete from 表名 表別名?where?表別名.col = '1' ?會報(bào)錯
5、內(nèi)存使用有問題，GO語言導(dǎo)致不知道回收機(jī)制什么時候運(yùn)作。內(nèi)存使用過多會導(dǎo)致TIDB當(dāng)機(jī)（這點(diǎn)完全不像MYSQL）
測試情況是，32G內(nèi)存，在10分鐘后才回收一半。
6、數(shù)據(jù)寫入的時候，tidb壓力很大, tikv的CPU也占用很高
7、不支持GBK
8、不支持存儲過程
9、列數(shù)支持太少，只支持100列，和oralce/mysql的1000列少太多（Oracle 最大列數(shù)為 1000；MySQL對于每個表具有4096個列的硬限制, 其中InnoDB每個表的限制為1017列, 最大行大小限制為65,535字節(jié)）
1、測試環(huán)境推薦配置
2、生產(chǎn)環(huán)境推薦配置
3、 如果 tikv 服務(wù)器的 CPU及磁盤配置較高，可以考慮多實(shí)例部署，按照每個 tikv 實(shí)例16~20core + 64G 內(nèi)存 + 800G 磁盤的比例分配硬件資源。
同時需要注意 inventory.ini 及 ansible/conf/tikv.yml 的相關(guān)配置。
4、tidb 服務(wù)器視業(yè)務(wù)類型，如果業(yè)務(wù)邏輯有偏 AP 類的 SQL，需要考慮配置大內(nèi)存，防止出現(xiàn) OOM。
如果是純 TP 類業(yè)務(wù)，tidb 服務(wù)器 CPU 配置較高的話，也可以考慮多實(shí)例部署，每個 tidb-server 分配20~32core，可以避免無謂的CPU上下文切換， 減少 system cpu 消耗。
5、pd 服務(wù)器的磁盤可以配置200~500G 的SSD 盤，主要用來保存源數(shù)據(jù)信息。在集群規(guī)模較大，源數(shù)據(jù)信息較多的時候，SSD 磁盤能夠避免源數(shù)據(jù)信息存取成為集群的瓶頸點(diǎn)。
1、操作系統(tǒng)版本要求
建議 centos 7.3及以上，支持 redhat 7.3版本及以上，不推薦其他版本的系統(tǒng)。
2、ansible、jinja 等軟件依賴包版本，只需要驗(yàn)證中控機(jī)（運(yùn)行ansible 機(jī)器）上軟件版本滿足條件即可
中控機(jī)：
監(jiān)控機(jī)（grafana）：
3、測試環(huán)境磁盤 IO 不滿足需求
ansible-playbook bootstrap.yml --extra-vars "dev_mode=True"
加上 dev_mode=True 可以在部署時，繞過系統(tǒng)磁盤相關(guān)的 benchmark
4、關(guān)閉防火墻、開啟時鐘同步
systemctl status firewalld
systemctl status chronyd/ntpd
5、集群下所有服務(wù)器要配置不同的 hostname
如果否，可以編輯 inventory.ini 的配置項(xiàng) set_hostname=True 來自動修改 hostname
6、調(diào)整參數(shù)
參數(shù)在 ansible/conf/目錄下，tidb.yml，tikv.yml，常見的可能需要調(diào)整的參數(shù)
tidb.yml：
grpc-connection-count: 如果服務(wù)器 CPU 配置較高，tikv 實(shí)例個數(shù)較多，該參數(shù)可以調(diào)整至20~32之間
slow-threshold：slow-query 記錄的閾值，默認(rèn)300ms
level：日志級別，默認(rèn) info，可以視情況調(diào)整為 debug 或 error
tikv.yml：
sync-log：raft-log sync配置，默認(rèn)值true，對于磁盤 io 消耗較高，測試/非金融生產(chǎn)環(huán)境建議設(shè)置為 false
region-split-check-diff：檢測 region 分裂的閾值，非 SSD 磁盤建議調(diào)大至32MB
rocksdb defaultcf block-cache-size(GB)?= MEM * 80% / TiKV 實(shí)例數(shù)量 * 30%（多實(shí)例部署下配置，單實(shí)例部署不需要修改）
rocksdb writecf block-cache-size(GB)?= MEM * 80% / TiKV 實(shí)例數(shù)量 * 45%（多實(shí)例部署下配置，單實(shí)例部署不需要修改）
rocksdb lockcf block-cache-size(GB)?= MEM * 80% / TiKV 實(shí)例數(shù)量 * 2.5% (最小 128 MB)（多實(shí)例部署下配置，單實(shí)例部署不需要修改）
raftdb defaultcf block-cache-size(GB)?= MEM * 80% / TiKV 實(shí)例數(shù)量 * 2.5% (最小 128 MB)（多實(shí)例部署下配置，單實(shí)例部署不需要修改）
多實(shí)例情況下，需要修改?
readpool:
coprocessor:
high-concurrency
normal-concurrency
low-concurrency
三個參數(shù)，推薦為實(shí)例數(shù)*參數(shù)值 = CPU 核數(shù) * 0.8。
raftstore:
capacity
磁盤總?cè)萘?/ TiKV 實(shí)例數(shù)量，例如 “100GB”
修改完后，可以使用下面命令驗(yàn)證
cat tidb-ansible/conf/tikv.yml |grep -Ev "^$|#"
無誤后執(zhí)行?
ansible-playbook rolling_update.yml --tags=tidb/tikv
滾動升級，tags 可選
7、官網(wǎng)有比較完善的在線+離線部署方案、在線升級指導(dǎo)、在線擴(kuò)容縮容文檔，具體參考：
1、從 MySQL 遷移
TiDB 兼容 MySQL 語法，小數(shù)據(jù)量建議直接使用 mysqldump、mydumper 來全量導(dǎo)出數(shù)據(jù)，再通過 source、myloader 的方式導(dǎo)入 TiDB。
./bin/mydumper -h?127.0.0.1 -P?3306?-u root -t?16?-F?64?-B test -T t1,t2 --skip-tz-utc -o ./var/test
./bin/loader -h?127.0.0.1 -u root -P?4000?-t?32?-d ./var/test
詳情請參考： 使用-mydumper-loader-全量導(dǎo)入數(shù)據(jù)
如果數(shù)據(jù)量較大，超過幾百 G，可以聯(lián)系原廠申請?jiān)囉?lightning 工具，loader 導(dǎo)入數(shù)據(jù)平均速度是20G/小時，lightning 約為100~150G/小時
2、從 Oracle 遷移
目前有幾種方式可以參考
使用 OGG 做全量+增量同步
使用 Navicat Premium 版的 data transfer 功能，支持從 Oracle/SqlServer 遷移全量數(shù)據(jù)至 TiDB
通過 kafka 等消息隊(duì)列工具，解析 OGG 的日志，開發(fā)寫入 TiDB/MySQL 的工具
目前我們也在積極跟專業(yè)的數(shù)據(jù)異構(gòu)平臺合作，爭取能夠盡快在更多的數(shù)據(jù)遷移工具中兼容 TiDB 數(shù)據(jù)源。
1、啟動集群
ansible-playbook start.yml --tags=tidb/tikv/pd
在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選
2、停止集群
ansible-playbook stop.yml --tags=tidb/tikv/pd
在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選
3、停止單個 tidb-server / tikv-server
ansible-playbook stop.yml --tags=tidb/tikv/pd -l IP
-l 后面接 inventory.ini 配置的IP 或別名
4、訪問 tidb
TiDB 兼容 MySQL 協(xié)議，所有連接 MySQL 的方式都適用于TiDB
mysql -uroot -h127.0.0.1 -P4000 -p
常見的圖形化界面工具，navicat 等都可以直接訪問 tidb
同時也支持jdbc、odbc 等，需要注意的是 mysql 8.0版本的客戶端，及 mariadb 客戶端可能存在兼容性問題，不建議使用
SQL 語法基本兼容 MySQL，某些不兼容的場景見： 與-mysql-兼容性對比
5、修改參數(shù)
可以通過修改 tidb-ansible/conf/tidb.yml 配置文件，然后執(zhí)行
ansible-playbook rolling_update.yml --tags=tidb/tikv
也可以直接登錄服務(wù)器，找到deploy_dir/conf/tidb.toml，直接編輯文件，然后 pkill tidb-server 來重啟服務(wù)
6、查看 tidb 版本信息
select tidb_version();
Release Version: v2.1.0-rc.3-24-g23f90a6
Git Commit Hash: 23f90a68be321e724280da6033a2b63ebf6cc7dd
Git Branch: HEAD
UTC Build Time: 2018-10-10 09:18:39
GoVersion: go version go1.11 linux/amd64
Race Enabled: false
TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e
Check Table Before Drop: false
7、備份 tidb 數(shù)據(jù)
全量備份可以采用 mydumper，增量備份需要開啟 binlog，實(shí)時恢復(fù)采用商業(yè)版工具 reparo。
8、查看監(jiān)控?cái)?shù)據(jù)
在 ansible 的配置文件 inventory.ini 里，有一個監(jiān)控服務(wù)器的配置
[monitoring_servers]
10.1.163.87
deploy 的時候會默認(rèn)在這個配置服務(wù)器上部署 grafana 組件，通過
admin/admin? 訪問
具體一些常見的監(jiān)控指標(biāo)，請參考：
9、收集統(tǒng)計(jì)信息
set @@tidb_build_stats_concurrency=20;
set @@tidb_distsql_scan_concurrency=100;
set @@tidb_index_serial_scan_concurrency=20;
analyze table xxx index xxx;
修改上面三個參數(shù)可以提升 scan 效率。
具體統(tǒng)計(jì)信息相關(guān)，請參考： 統(tǒng)計(jì)信息簡介
1、Transaction too large
TiDB 對于事務(wù)有限制，簡單來說以下幾點(diǎn)：
單個事務(wù)的SQL 語句數(shù)量不能超過5000，（ 在 tidb.yml 可配 stmt-count-limit ）
單條 KV entry 不超過 6MB
KV entry 的總條數(shù)不超過 30w
KV entry 的總大小不超過 100MB
備注：假設(shè)某張表有4個索引，那么一條數(shù)據(jù)對應(yīng)的 kv entry 為數(shù)據(jù)+索引，一共5個kv 記錄。
如果是批量 insert 或delete，建議先修改
set tidb_batch_insert = 1;?
set?tidb_batch_delete = 1;
update mysql.tidb set variable_value='24h' where variable_name='tikv_gc_life_time';
再執(zhí)行 SQL。
如果是批量 update，建議采用 limit 循環(huán)的方式執(zhí)行。
2、GC life time is shorter than transaction duration
GC Life Time?間隔時間過短，長事務(wù)本應(yīng)讀到的數(shù)據(jù)可能被清理了，可使用如下命令增加?GC Life Time?：
update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';
3、Lost connection to MySQL server during query
log 中是否有 panic
dmesg 中是否有 oom，命令：?dmesg -T | grep -i oom
長時間沒有訪問，也會收到這個報(bào)錯，一般是 tcp 超時導(dǎo)致的，tcp 長時間不用, 會被操作系統(tǒng) kill。
tidb數(shù)據(jù)庫和mysql的區(qū)別為：開發(fā)公司不同、事務(wù)更新機(jī)制不同、事務(wù)方式不同。
一、開發(fā)公司不同
1、tidb數(shù)據(jù)庫：tidb數(shù)據(jù)庫是北京的創(chuàng)業(yè)公司PingCAP的產(chǎn)品。
2、mysql：mysql是由瑞典MySQL AB 公司開發(fā)，屬于?Oracle?旗下產(chǎn)品。
二、事務(wù)更新機(jī)制不同
1、tidb數(shù)據(jù)庫：tidb數(shù)據(jù)庫采用樂觀鎖機(jī)制來保證事務(wù)更新的一致性和持久性。
2、mysql：mysql采用redo log機(jī)制來保證事務(wù)更新的一致性和持久性。
三、事務(wù)方式不同
1、tidb數(shù)據(jù)庫：tidb數(shù)據(jù)庫使用的是扁平事務(wù)。
2、mysql：mysql使用的是分布式事務(wù)。
Go語言由Google公司開發(fā)，并于2009年開源，相比Java/Python/C等語言，Go尤其擅長并發(fā)編程，性能堪比C語言，開發(fā)效率肩比Python，被譽(yù)為“21世紀(jì)的C語言”。
Go語言在云計(jì)算、大數(shù)據(jù)、微服務(wù)、高并發(fā)領(lǐng)域應(yīng)用應(yīng)用非常廣泛。BAT大廠正在把Go作為新項(xiàng)目開發(fā)的首選語言。
Go語言應(yīng)用范圍：
1、服務(wù)端開發(fā)：以前你使用C或者C++做的那些事情，用Go來做很合適，例如日志處理、文件系統(tǒng)、監(jiān)控系統(tǒng)等;
2、DevOps：運(yùn)維生態(tài)中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go語言開發(fā);
3、網(wǎng)絡(luò)編程：大量優(yōu)秀的Web框架如Echo、Gin、Iris、beego等，而且Go內(nèi)置的 net/http包十分的優(yōu)秀;
4、Paas云平臺領(lǐng)域：Kubernetes和Docker Swarm等;
5、分布式存儲領(lǐng)域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、區(qū)塊鏈領(lǐng)域：區(qū)塊鏈里面有兩個明星項(xiàng)目以太坊和fabric都使用Go語言;
7、容器虛擬化：大名鼎鼎的Docker就是使用Go語言實(shí)現(xiàn)的;
8、爬蟲及大數(shù)據(jù)：Go語言天生支持并發(fā)，所以十分適合編寫分布式爬蟲及大數(shù)據(jù)處理。
TiDB 是 PingCAP 自主研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，具備商業(yè)級數(shù)據(jù)庫的數(shù)據(jù)可靠性，可用性，安全性等特性，支持在線彈性水平擴(kuò)展，兼容 MySQL 協(xié)議及生態(tài)，創(chuàng)新性實(shí)現(xiàn) OLTP 及 OLAP 融合。
TiDB 3.0 版本顯著提升了大規(guī)模集群的穩(wěn)定性，集群支持 150+ 存儲節(jié)點(diǎn)，300+TB 存儲容量長期穩(wěn)定運(yùn)行。易用性方面引入大量降低用戶運(yùn)維成本的優(yōu)化，包括引入 Information_Schema 中的多個實(shí)用系統(tǒng)視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因?qū)崿F(xiàn) View 可以執(zhí)行，至此 TPC-H 22 個 Query 均可正常運(yùn)行。新功能方面增加了窗口函數(shù)、視圖（實(shí)驗(yàn)特性）、分區(qū)表、插件系統(tǒng)、悲觀鎖（實(shí)驗(yàn)特性）。
截止本文發(fā)稿時 TiDB 已在 500+ 用戶的生產(chǎn)環(huán)境中長期穩(wěn)定運(yùn)行，涵蓋金融、保險(xiǎn)、制造，互聯(lián)網(wǎng)， 游戲 等領(lǐng)域，涉及交易、數(shù)據(jù)中臺、 歷史 庫等多個業(yè)務(wù)場景。不同業(yè)務(wù)場景對關(guān)系型數(shù)據(jù)庫的訴求可用 “百花齊放”來形容，但對關(guān)系數(shù)據(jù)庫最根本的訴求未發(fā)生任何變化，如數(shù)據(jù)可靠性，系統(tǒng)穩(wěn)定性，可擴(kuò)展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什么樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規(guī)模集群的穩(wěn)定性，支持單集群 150+ 存儲節(jié)點(diǎn)，300+TB 存儲容量長期穩(wěn)定運(yùn)行，主要的優(yōu)化點(diǎn)如下：
1. 優(yōu)化 Raft 副本之間的心跳機(jī)制，按照 Region 的活躍程度調(diào)整心跳頻率，減小冷數(shù)據(jù)對集群的負(fù)擔(dān)。
2. 熱點(diǎn)調(diào)度策略支持更多參數(shù)配置，采用更高優(yōu)先級，并提升熱點(diǎn)調(diào)度的準(zhǔn)確性。
3. 優(yōu)化 PD 調(diào)度流程，提供調(diào)度限流機(jī)制，提升系統(tǒng)穩(wěn)定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統(tǒng)穩(wěn)定性。
眾所周知，數(shù)據(jù)庫查詢計(jì)劃的穩(wěn)定性對業(yè)務(wù)至關(guān)重要，TiDB 3.0 版本采用多種優(yōu)化手段提升查詢計(jì)劃的穩(wěn)定性，如下：
1. 新增 Fast Analyze 功能，提升收集統(tǒng)計(jì)信息的速度，降低集群資源的消耗及對業(yè)務(wù)的影響。
2. 新增 Incremental Analyze 功能，提升收集單調(diào)遞增的索引統(tǒng)計(jì)信息的速度，降低集群資源的消耗及對業(yè)務(wù)的影響。
3. 在 CM-Sketch 中新增 TopN 的統(tǒng)計(jì)信息，緩解 CM-Sketch 哈希沖突導(dǎo)致估算偏大，提升代價估算的準(zhǔn)確性，提升查詢計(jì)劃的穩(wěn)定性。
4. 引入 Skyline Pruning 框架，利用規(guī)則防止查詢計(jì)劃過度依賴統(tǒng)計(jì)信息，緩解因統(tǒng)計(jì)信息滯后導(dǎo)致選擇的查詢計(jì)劃不是最優(yōu)的情況，提升查詢計(jì)劃的穩(wěn)定性。
5. 新增 SQL Plan Management 功能，支持在查詢計(jì)劃不準(zhǔn)確時手動綁定查詢計(jì)劃，提升查詢計(jì)劃的穩(wěn)定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優(yōu)化點(diǎn)如下：
1. TiDB 持續(xù)優(yōu)化 SQL 執(zhí)行器，包括：優(yōu)化 NOT EXISTS 子查詢轉(zhuǎn)化為 Anti Semi Join，優(yōu)化多表 Join 時 Join 順序選擇等。
2. 優(yōu)化 Index Join 邏輯，擴(kuò)大 Index Join 算子的適用場景并提升代價估算的準(zhǔn)確性。
3. TiKV 批量接收和發(fā)送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。
4. TiKV 優(yōu)化內(nèi)存管理，減少 Iterator Key Bound Option 的內(nèi)存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁盤 IO 的占用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節(jié)點(diǎn)內(nèi)可擴(kuò)展性，進(jìn)而提升單節(jié)點(diǎn)內(nèi)并發(fā)處理能力和資源利用率，降低延時，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優(yōu)化點(diǎn)，如下：
1. 提升 SQL 轉(zhuǎn)化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導(dǎo)入性能，單表支持批量導(dǎo)入。
3. 提升 TiKV-Importer 導(dǎo)入數(shù)據(jù)性能，支持將數(shù)據(jù)和索引分別導(dǎo)入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的權(quán)限訪問控制） 是商業(yè)系統(tǒng)中最常見的權(quán)限管理技術(shù)之一，通過 RBAC 思想可以構(gòu)建最簡單“用戶-角色-權(quán)限”的訪問權(quán)限控制模型。RBAC 中用戶與角色關(guān)聯(lián)，權(quán)限與角色關(guān)聯(lián)，角色與權(quán)限之間一般是多對多的關(guān)系，用戶通過成為什么樣的角色獲取該角色所擁有的權(quán)限，達(dá)到簡化權(quán)限管理的目的，通過此版本的迭代 RBAC 功能開發(fā)完成。
IP 白名單功能（企業(yè)版特性） ：TiDB 提供基于 IP 白名單實(shí)現(xiàn)網(wǎng)絡(luò)安全訪問控制，用戶可根據(jù)實(shí)際情況配置相關(guān)的訪問策略。
Audit log 功能（企業(yè)版特性） ：Audit log 記錄用戶對數(shù)據(jù)庫所執(zhí)行的操作，通過記錄 Audit log 用戶可以對數(shù)據(jù)庫進(jìn)行故障分析，行為分析，安全審計(jì)等，幫助用戶獲取數(shù)據(jù)執(zhí)行情況。
加密存儲（企業(yè)版特性） ：TiDB 利用 RocksDB 自身加密功能，實(shí)現(xiàn)加密存儲的功能，保證所有寫入到磁盤的數(shù)據(jù)都經(jīng)過加密，降低數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
完善權(quán)限語句的權(quán)限檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句權(quán)限檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢?nèi)罩緝?nèi)容，如：Coprocessor 任務(wù)數(shù)，平均/最長/90% 執(zhí)行/等待時間，執(zhí)行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產(chǎn)品易用性。
2. 新增系統(tǒng)配置項(xiàng)合法性檢查，優(yōu)化系統(tǒng)監(jiān)控項(xiàng)等，提升產(chǎn)品易用性。
3. 新增對 TableReader、IndexReader 和 IndexLookupReader 算子內(nèi)存使用情況統(tǒng)計(jì)信息，提高 Query 內(nèi)存使用統(tǒng)計(jì)的準(zhǔn)確性，提升處理內(nèi)存消耗較大語句的效率。
4. 制定日志規(guī)范，重構(gòu)日志系統(tǒng)，統(tǒng)一日志格式，方便用戶理解日志內(nèi)容，有助于通過工具對日志進(jìn)行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調(diào)優(yōu)的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接數(shù)據(jù)庫。
8. 新增快速恢復(fù)被刪除表功能，當(dāng)誤刪除數(shù)據(jù)時可通過此功能快速恢復(fù)數(shù)據(jù)。
TiDB 3.0 新增 TiFlash 組件，解決復(fù)雜分析及 HTAP 場景。TiFlash 是列式存儲系統(tǒng)，與行存儲系統(tǒng)實(shí)時同步，具備低延時，高性能，事務(wù)一致性讀等特性。 通過 Raft 協(xié)議從 TiKV 中實(shí)時同步行存數(shù)據(jù)并轉(zhuǎn)化成列存儲格式持久化到一組獨(dú)立的節(jié)點(diǎn)，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統(tǒng)（TiKV）實(shí)時鏡像，實(shí)時鏡像可獨(dú)立于行存儲系統(tǒng)，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優(yōu)推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務(wù)，提升約 10 倍復(fù)雜的混合查詢的性能。
TiFlash 目前處于 Beta 階段，計(jì)劃 2019 年 12 月 31 日之前 GA，歡迎大家申請?jiān)囉谩?/p>
未來我們會繼續(xù)投入到系統(tǒng)穩(wěn)定性，易用性，性能，彈性擴(kuò)展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗(yàn)，極致的用戶體驗(yàn)。
穩(wěn)定性方面 V4.0 版本將繼續(xù)完善 V3.0 未 GA 的重大特性，例如：悲觀事務(wù)模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復(fù)解決分布數(shù)據(jù)庫備份恢復(fù)難題；優(yōu)化 PD 調(diào)度功能等。
性能方面 V4.0 版本將繼續(xù)優(yōu)化事務(wù)處理流程，減少事務(wù)資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴(kuò)展方面，PD 將提供彈性擴(kuò)展所需的元信息供外部系統(tǒng)調(diào)用，外部系統(tǒng)可根據(jù)元信息及負(fù)載情況動態(tài)伸縮集群規(guī)模，達(dá)成節(jié)省成本的目標(biāo)。
我們相信戰(zhàn)勝“未知”最好的武器就是社區(qū)的力量，基礎(chǔ)軟件需要堅(jiān)定地走開源路線。截止發(fā)稿我們已經(jīng)完成 41 篇源碼閱讀文章。TiDB 開源社區(qū)總計(jì) 265 位 Contributor，6 位 Committer，在這里我們對社區(qū)貢獻(xiàn)者表示由衷的感謝，希望更多志同道合的人能加入進(jìn)來，也希望大家在 TiDB 這個開源社區(qū)能夠有所收獲。
TiDB 3.0 GA Release Notes：
重慶分公司
重慶分公司
