1樓：Bigdata234
@繆偉為了解決不同的應用場景而出現的。
實際上，目前關係型資料庫都是滿足的。比如Oracle，Mysql同時也支援OLTP和OLAP。就看你怎麼操作了。
你可以搭建兩個Mysql的集群，乙個用於OLTP，乙個用於OLAP。OLAP的集群每天定時從OLTP上同步即可。
當然，資料量大的時候關係型資料庫就扛不住了。這時候那些支援實時查詢的大資料NOSQL開始登場了，如HBase，ElasticSearch等。
2樓：Ed Huang
我主要說說 TiDB 吧，TiDB 是乙個可以用來做 OLTP 的*分布式關係型資料庫*，同時因為天然分布式，面對很多複雜查詢（偏 OLAP）有不錯的表現，本質上來說是乙個 100% OLTP + 80% OLAP 的關係型資料庫，這個是根本的不同，HAWQ 和 GPDB 一樣本質上是乙個偏分析型的資料庫，對於高併發寫入，ACID 事務，彈性伸縮，高可用這些問題不是它們側重點，所以本質上更像乙個 query engine。
1. TiDB 是支援絕大多數 MySQL 語法（包括子查詢/JOIN什麼的複雜查詢）對外暴露的是 MySQL 的網路協議，使用者是可以直接使用 MySQL 的客戶端或者 driver 來使用 TiDB。
2. TiDB 從出生的第一天就是為了 OLTP 業務而生的，支援 ACID 事務，高併發的插入，修改什麼的。
3. TiDB 儲存層並沒有依賴 DFS（分布式檔案系統），而是基於 Raft 實現的複製基礎之上，自己實現彈性伸縮能力，可用性和效能會更好（對於關係型資料庫裡的結構化資料而言）。
4. TiDB 的 SQL 優化器是乙個分布式的 SQL 優化器，用了很多現代的分布式 SQL 優化技術，特別是對於很多資料量比較大的場景通過謂詞（聚合）下推等手段其實能比單機的資料庫快幾多個數量級（畢竟能夠利用多機的計算能力併發的運算）。
所以一些典型的場景：替換 MySQL Sharding 或者中介軟體的方案，同時一些 AdHoc 的分析不需要再倒騰到Hadoop之類的資料倉儲中，直接在 TiDB 中完成，省掉了煩人的 ETL 過程。有點下一代 Hybrid Database 的意思。
tl;dr
TiDB 是乙個可以彈性伸縮的 MySQL，相容大多數 MySQL 的語法，擅長海量併發的查詢和事務寫入（毫秒級別），大資料量下對複雜查詢速度的速度比單機好得多。就醬。
可否對比一下 TiDB 與 AWS Aurora ？
胡彬 從架構上說，TiDB是share nothing，Aurora是share disk，兩種架構的不同前面幾位大牛說得很清楚了，這裡從使用維度做下比較 1.相容性 Aurora是基於MySQL或PostgreSQL的開源版本，其改動主要集中在儲存層面，不說100 相容 比如tablespace等...
tidb是抄的ob麼？
Cloud Gao TiDB和OB底層差異那麼大，怎麼抄？何況OB又不是開源的。PS 如果換我是提問者，這個公司給offer都不會接的，這面試官也太奇葩了。 shane.qian 好奇，闖進來了。有沒抄ob不知道，沒有且估計也不會有機會去使用ob，但看tidb的構架，發覺一些熟悉的味道。region...
TiDB能否覆蓋HBase的絕大多數使用場景？
看場景，高併發，寫多讀少的場景，HBase應該還是有明顯優勢的。借助於Hadoop生態的天然融合和HDFS對資料多副本的細節隱藏，HBase本身架構更加清晰明了。 阿里封神 目前hbase解決的問題是海量儲存量及超高的併發，主要適合大資料的場景，比如blukload匯入資料 跟hadoop生態的結合...