越nb的工程師越喜歡高性能,認爲越快越好。可是 TiDB 的首要目標不是作到最快,而是作到 Availability reliability 穩定性 IO和 無限擴展。高性能的成本過高,要根據用戶的硬件優化。可是這裏是通用的數據庫,不可能去優化各類場景。簡單留給用戶,複雜留給本身(跟AWS意見相反)。mysql
認爲 eventual consistency 是個僞概念,實際上就是沒一致性或者弱一致性。好比 cassandra WRN 設置好了,但到底過多久 可以resolve?不肯定。太複雜,用戶最好不須要知道操心這些複雜的設置。算法
跑分不是惟一的指標,TPCC/TPCH 分數高對實際沒有太多指導意義。數據庫是磨出來的。好比第一家客戶,遊戲公司,竟然建立了3萬張表,json 的 meta 信息連起來很是慢。sql
構架上不是 P2P,而是不一樣角色分得很清楚。數據庫
KV 用的是 RocksDB 可是典型的 LSM tree 的寫放大是15倍,這裏優化到 value 拆出來,解決寫放大的問題。json
支持 MySQL 的client,也支持 SparkSQL 的讀。api
SQL layer 沒有用 MySQL 的模塊。一開始有試過,可是1)下面很難分佈式 2)代碼太爛很難改。魔改的話,半年能作;可是長期的維護成本更高。重作不麻煩,都重構了三次了。這裏用 Go 比用 C/C++/Rust 重構更方便。分佈式
一開始只想作 F1只作sql,和 CockroachDB 合做,後來他們往sql這邊作,這邊就只能往storage 作性能
挖了 Rust core team 的兩我的。rust 很難招人,通常是招 C++的人而後轉rust,他們會以爲不少腦殼裏的約定編譯器幫你搞定了。優化
不要低估造工業級輪子的難度。用 grpc,raft,rocksdb的好處是,若是業界有新的進展,會直接讓使用者收益。接口
Chunk (region) split 作了兩個月,merge 作了三年。merge 作了形式化證實。
爲何是如今?
Everything is pluggable , 頂層 api 不變,下面即插即用可替換
Distributed Transaction
Multi-tenancy achieved by kubernetes
本文首發於硅谷io