⑴ 資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之為什麼要分庫分表？
數
據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增
刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、
數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶數據
庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2
何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫
上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、
part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，
然後將這些表按照一定的規則存儲到多個userDB上。
3.3 應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而
如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體
的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額
外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於
一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order
by語句就可以搞定，但是在進行分表之後，將需要n個order
by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
⑵ 2019數據架構選型必讀：1月資料庫產品技術解析
本期目錄
DB-Engines資料庫排行榜
新聞快訊
一、RDBMS家族
二、Nosql家族
三、NewSQL家族
四、時間序列
五、大數據生態圈
六、國產資料庫概覽
七、雲資料庫
八、推出dbaplus Newsletter的想法
九、感謝名單
為方便閱讀、重點呈現，本期Newsletter（2019年1月）將對各個板塊的內容進行精簡。需要閱讀全文的同學可點擊文末 【閱讀原文】 或登錄https://pan..com/s/13BgipbaHeMfvm0YPtiYviA
DB-Engines資料庫排行榜
以下取自2019年1月的數據，具體信息可以參考http://db-engines.com/en/ranking/，數據僅供參考。
DB-Engines排名的數據依據5個不同的因素：
新聞快訊
1、2018年9月24日，微軟公布了SQL Server2019預覽版，SQL Server 2019將結合Spark創建統一數據平台。
2、2018年10月5日，ElasticSearch在美國紐約證券交易所上市。
3、亞馬遜放棄甲骨文資料庫軟體，導致最大倉庫之一在黃金時段宕機。受此消息影響，亞馬遜盤前股價小幅跳水，跌超2%。
4、2018年10月31日，Percona發布了Percona Server 8.0 RC版本，發布對MongoDB 4.0的支持，發布對XtraBackup測試第二個版本。
5、2018年10月31日，Gartner陸續發布了2018年的資料庫系列報告，包括《資料庫魔力象限》、《資料庫核心能力》以及《資料庫推薦報告》。
今年的總上榜資料庫產品達到了5家，分別來自：阿里雲，華為，巨杉資料庫，騰訊雲，星環 科技 。其中阿里雲和巨杉資料庫已經連續兩年入選。
6、2018年11月初，Neo4j宣布完成E輪8000萬美元融資。11月15日，Neo4j宣布企業版徹底閉源：
7、2019年1月8日，阿里巴巴以1.033億美元（9000萬歐元）的價格收購了Apache Flink商業公司DataArtisans。
8、2019年1月11日早間消息，亞馬遜宣布推出雲資料庫軟體，亞馬遜和MongoDB將會直接競爭。
RDBMS家族
Oracle 發布18.3版本
2018年7月，Oracle Database 18.3通用版開始提供下載。我們可以將Oracle Database 18c視為採用之前發布模式的Oracle Database 12c第2版的第一個補丁集。未來，客戶將不再需要等待多年才能用上最新版Oracle資料庫，而是每年都可以期待新資料庫特性和增強。Database 19c將於2019年Q1率先在Oracle cloud上發布雲版本。
Oracle Database 18c及19c部分關鍵功能：
1、性能
2、多租戶，大量功能增強及改進，大幅節省成本和提高敏捷性
3、高可用
4、數據倉庫和大數據
MySQL發布8.0.13版本
1、賬戶管理
經過配置，修改密碼時，必須帶上原密碼。在之前的版本，用戶登錄之後，就可以修改自己的密碼。這種方式存在一定安全風險。比如用戶登錄上資料庫後，中途離開一段時間，那麼非法用戶可能會修改密碼。由參數password_require_current控制。
2、配置
Innodb表必須有主鍵。在用戶沒有指定主鍵時，系統會生成一個默認的主鍵。但是在主從復制的場景下，默認的主鍵，會對叢庫應用速度帶來致命的影響。如果設置sql_require_primary_key，那麼資料庫會強制用戶在創建表、修改表時，加上主鍵。
3、欄位默認值
BLOB、TEXT、GEOMETRY和JSON欄位可以指定默認值了。
4、優化器
1）Skip Scan
非前綴索引也可以用了。
之前的版本，任何沒有帶上f1欄位的查詢，都沒法使用索引。在新的版本中，它可以忽略前面的欄位，讓這個查詢使用到索引。其實現原理就是把(f1 = 1 AND f2 > 40) 和(f1 = 2 AND f2 > 40)的查詢結果合並。
2）函數索引
之前版本只能基於某個列或者多個列加索引，但是不允許在上面做計算，如今這個限制消除了。
5、SQL語法
GROUP BY ASC和GROUP BY DESC語法已經被廢棄，要想達到類似的效果，請使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。
6、功能變化
1）設置用戶變數，請使用SET語句
如下類型語句將要被廢棄SELECT @var, @var:=@var+1。
2）新增innodb_fsync_threshold
該變數是控制文件刷新到磁碟的速率，防止磁碟在短時間內飽和。
3）新增會話級臨時表空間
在以往的版本中，當執行SQL時，產生的臨時表都在全局表空間ibtmp1中，及時執行結束，臨時表被釋放，空間不會被回收。新版本中，會為session從臨時表空間池中分配一個臨時表空間，當連接斷開時，臨時表空間的磁碟空間被回收。
4）在線切換Group Replication的狀態
5）新增了group_replication_member_expel_timeout
之前，如果某個節點被懷疑有問題，在5秒檢測期結束之後，那麼就直接被驅逐出這個集群。即使該節點恢復正常時，也不會再被加入集群。那麼，瞬時的故障，會把某些節點驅逐出集群。
group_replication_member_expel_timeout讓管理員能更好的依據自身的場景，做出最合適的配置（建議配置時間小於一個小時）。
MariaDB 10.3版本功能展示
1、MariaDB 10.3支持update多表ORDER BY and LIMIT
1）update連表更新，limit語句
update t1 join t2 on t1.id=t2.id set t1.name='hechunyang' limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
2）update連表更新，ORDER BY and LIMIT語句
update t1 join t2 on t1.id=t2.id set t1.name='HEchunyang' order by t1.id DESC limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
參考：
https://jira.mariadb.org/browse/MDEV-13911
2、MariaDB10.3增補AliSQL補丁——安全執行Online DDL
Online DDL從名字上看很容易誤導新手，以為不論什麼情況，修改表結構都不會鎖表，理想很豐滿，現實很骨感，注意這個坑！
有以下兩種情況執行DDL操作會鎖表的，Waiting for table metadata lock（元數據表鎖）：
針對第二種情況，MariaDB10.3增補AliSQL補丁-DDL FAST FAIL，讓其DDL操作快速失敗。
例：
如果線上有某個慢SQL對該表進行操作，可以使用WAIT n（以秒為單位設置等待）或NOWAIT在語句中顯式設置鎖等待超時，在這種情況下，如果無法獲取鎖，語句將立即失敗。 WAIT 0相當於NOWAIT。
參考：
https://jira.mariadb.org/browse/MDEV-11388
3、MariaDB Window Functions窗口函數分組取TOP N記錄
窗口函數在MariaDB10.2版本里實現，其簡化了復雜SQL的撰寫，提高了可讀性。
參考：
https://mariadb.com/kb/en/library/window-functions-overview/
Percona Server發布8.0 GA版本
2018年12月21日，Percona發布了Percona Server 8.0 GA版本。
在支持MySQL8.0社區的基礎版上，Percona Server for MySQL 8.0版本中帶來了許多新功能：
1、安全性和合規性
2、性能和可擴展性
3、可觀察性和可用性
Percona Server for MySQL 8.0中將要被廢用功能：
Percona Server for MySQL 8.0中刪除的功能：
RocksDB發布V5.17.2版本
2018年10月24日，RocksDB發布V5.17.2版本。
RocksDB是Facebook在LevelDB基礎上用C++寫的高效內嵌式K/V存儲引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底層的存儲都是基於RocksDB來構建。
PostgreSQL發布11版本
2018年10月18日，PostgreSQL 11發布。
1、PostgreSQL 11的重大增強
2、PostgreSQL 插件動態
1）分布式插件citus發布 8.1
citus是PostgreSQL的一款sharding插件，目前國內蘇寧、鐵總、探探有較大量使用案例。
https://github.com/citusdata/citus
2）地理信息插件postgis發布2.5.1
PostGIS是專業的時空資料庫插件，在測繪、航天、氣象、地震、國土資源、地圖等時空專業領域應用廣泛。同時在互聯網行業也得到了對GIS有性能、功能深度要求的客戶青睞，比如共享出行、外賣等客戶。
http://postgis.net/
3）時序插件timescale發布1.1.1
timescale是PostgreSQL的一款時序資料庫插件，在IoT行業中有非常好的應用。github star數目前有5000多，是一個非常火爆的插件。
https://github.com/timescale/timescaledb
4）流計算插件 pipelinedb 正式插件化
Pipelinedb是PostgreSQL的一款流計算插件，使用這個創建可以對高速寫入的數據進行實時根據定義的聚合規則進行聚合（支持概率計算），實時根據定義的規則觸發事件（支持事件處理函數的自定義）。可用於IoT，監控，FEED實時計算等場景。
https://github.com/pipelinedb/pipelinedb
3、PostgreSQL衍生開源產品動態
1）agensgraph發布 2.0.0版本
agensgraph是兼容PostgreSQL、opencypher的專業圖資料庫，適合圖式關系的管理。
https://github.com/bitnine-oss/agensgraph
2）gpdb發布5.15
gpdb是兼容PostgreSQL的mpp資料庫，適合OLAP場景。近兩年，gpdb一直在追趕PostgreSQL的社區版本，預計很快會追上10的PostgreSQL，在TP方面的性能也會得到顯著提升。
https://github.com/greenplum-db/gpdb
3）antdb發布3.2
antdb是以Postgres-XC為基礎開發的一款PostgreSQL sharding資料庫，亞信主導開發，開源，目前主要服務於亞信自有客戶。
https://github.com/ADBSQL/AntDB
4）遷移工具MTK發布52版本
MTK是EDB提供的可以將Oracle、PostgreSQL、MySQL、MSSQL、Sybase資料庫遷移到PostgreSQL, PPAS的產品，遷移速度可以達到100萬行/s以上。
https://github.com/digoal/blog/blob/master/201812/20181226_01.md
DB2發布 11.1.4.4版本
DB2最新發布Mod Pack 4 and Fix Pack 4，包含以下幾方面的改動及增強：
1、性能
2、高可用
3、管理視圖
4、應用開發方面
5、聯邦功能
6、pureScale
NoSQL家族
Redis發布5.0.3版本
MongoDB升級更新MongoDB Mobile和MongoDB Stitch
2018年11月21日，MongoDB升級更新MongoDB Mobile和MongoDB Stitch，助力開發人員提升工作效率。
MongoDB 公司日前發布了多項新產品功能，旨在更好地幫助開發人員在世界各地管理數據。通過利用存儲在移動設備和後台資料庫的數據之間的實時、自動的同步特性，MongoDB Mobile通用版本助力開發人員構建更快捷、反應更迅速的應用程序。此前，這只能通過在移動應用內部安裝一個可供選擇或限定功能的資料庫來實現。
MongoDB Mobile在為客戶提供隨處運行的自由度方面更進了一步。用戶在iOS和安卓終端設備上可擁有MongoDB所有功能，將網路邊界擴展到其物聯網資產范疇。應用系統還可以使用MongoDB Stitch的軟體開發包訪問移動客戶端或後台數據，幫助開發人員通過他們希望的任意方式查詢移動終端數據和物聯網數據，包括本地讀寫、本地JSON存儲、索引和聚合。通過Stitch移動同步功能(現可提供beta版)，用戶可以自動對保存在本地的數據以及後台資料庫的數據進行同步。
本期新秀：Cassandra發布3.11.3版本
2018年8月11日，Cassandra發布正式版3.11.3。
Apache Cassandra是一款開源分布式NoSQL資料庫系統，使用了基於Google BigTable的數據模型，與面向行(row)的傳統關系型資料庫或鍵值存儲key-value資料庫不同，Cassandra使用的是寬列存儲模型(Wide Column Stores)。與BigTable和其模仿者HBase不同，數據並不存儲在分布式文件系統如GFS或HDFS中，而是直接存於本地。
Cassandra的系統架構與Amazon DynamoDB類似，是基於一致性哈希的完全P2P架構，每行數據通過哈希來決定應該存在哪個或哪些節點中。集群沒有master的概念，所有節點都是同樣的角色，徹底避免了整個系統的單點問題導致的不穩定性，集群間的狀態同步通過Gossip協議來進行P2P的通信。
3.11.3版本的一些bug fix和改進：
NewSQL家族
TiDB 發布2.1.2版本
2018 年 12 月 22 日，TiDB 發布 2.1.2 版，TiDB-Ansible 相應發布 2.1.2 版本。該版本在 2.1.1 版的基礎上，對系統兼容性、穩定性做出了改進。
TiDB 是一款定位於在線事務處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型資料庫產品。除了底層的 RocksDB 存儲引擎之外，分布式SQL層、分布式KV存儲引擎（TiKV）完全自主設計和研發。
TiDB 完全開源，兼容MySQL協議和語法，可以簡單理解為一個可以無限水平擴展的MySQL，並且提供分布式事務、跨節點 JOIN、吞吐和存儲容量水平擴展、故障自恢復、高可用等優異的特性；對業務沒有任何侵入性，簡化開發，利於維護和平滑遷移。
TiDB：
PD：
TiKV：
Tools：
1）TiDB-Lightning
2）TiDB-Binlog
EsgynDB發布R2.5版本
2018年12月22日，EsgynDB R2.5版本正式發布。
作為企業級產品，EsgynDB 2.5向前邁進了一大步，它擁有以下功能和改進：
CockroachDB發布2.1版本
2018年10月30日，CockroachDB正式發布2.1版本，其新增特性如下：
新增企業級特性：
新增SQL特性：
新增內核特性：
Admin UI增強：
時間序列
本期新秀：TimescaleDB發布1.0版本
10月底，TimescaleDB 1.0宣布正式推出，官方表示該版本已可用於生產環境，支持完整SQL和擴展。
TimescaleDB是基於PostgreSQL資料庫開發的一款時序資料庫，以插件化的形式打包提供，隨著PostgreSQL的版本升級而升級，不會因為另立分支帶來麻煩。
TimescaleDB架構：
數據自動按時間和空間分片(chunk)
更新亮點：
https://github.com/timescale/timescaledb/releases/tag/1.0.0
大數據生態圈
Hadoop發布2.9.2版本
2018年11月中旬，Hadoop在2.9分支上發布了新的2.9.2版本，該版本進行了204個大大小小的變更，主要變更如下：
Greenplum 發布5.15版本
Greenplum最新的5.15版本中發布了流式數據載入工具。
該版本中的Greenplum Streem Server組件已經集成了Kafka流式載入功能，並通過了Confluent官方的集成認證，其支持的主要功能如下：
國產資料庫概覽
K-DB發布資料庫一體機版
2018年11月7日，K-DB發布了資料庫一體機版。該版本更新情況如下：
OceanBase遷移服務發布1.0版本
1月4日，OceanBase 正式發布OMS遷移服務1.0版本。
以下內容包含 OceanBase 遷移服務的重要特性和功能：
SequoiaDB發布3.0.1新版本
1、架構
1）完整計算存儲分離架構，兼容MySQL協議、語法
計算存儲分離體系以松耦合的方式將計算與存儲層分別部署，通過標准介面或插件對各個模塊和組件進行無縫替換，在計算層與存儲層均可實現自由的彈性伸縮。
SequoiaDB巨杉資料庫「計算-存儲分離」架構詳細示意
用戶可以根據自身業務特徵選擇面向交易的SQL解析器（例如MySQL或PGSQL）或面向統計分析的執行引擎（例如SparkSQL）。眾所周知，使用不同的SQL優化與執行方式，資料庫的訪問性能可能會存在上千上萬倍的差距。計算存儲分離的核心思想便是在數據存儲層面進行一體化存儲，在計算層面則利用每種執行引擎的特點針對不同業務場景進行選擇和優化，用戶可以在存儲層進行邏輯與物理的隔離，將面向高頻交易的前端業務與面向高吞吐量的統計分析使用不同的硬體進行存儲，確保在多類型數據訪問時互不幹擾，以真正達到生產環境可用的多租戶與HTAP能力。
2、其他更新信息
1）介面變更：
2）主要特性：
雲資料庫
本期新秀：騰訊發布資料庫CynosDB，開啟公測
1、News
1）騰訊雲資料庫MySQL2018年重大更新：
2）騰訊雲資料庫MongoDB2018年重大更新：
3）騰訊雲資料庫Redis/CKV+2018年重大更新：
4）騰訊雲資料庫CTSDB2018年重大更新：
2、Redis 4.0集群版商業化上線
2018年10月，騰訊雲資料庫Redis 4.0集群版完成邀測、公測、商業化三個迭代，在廣州、上海、北京正式全量商業化上線。
產品特性：
使用場景：
官網文檔：
https://cloud.tencent.com/document/proct/239/18336
3、騰訊自研資料庫CynosDB發布，開啟公測
2018年11月22日，騰訊雲召開新一代自研資料庫CynosDB發布會，業界第一款全面兼容市面上兩大最主流的開源資料庫MySQL和PostgreSQL的高性能企業級分布式雲資料庫。
本期新秀：京東雲DRDS發布1.0版本
12月24日，京東雲分布式關系型資料庫DRDS正式發布1.0版本。
DRDS是京東雲精心自研的資料庫中間件產品，獲得了2018年 」可信雲技術創新獎」。DRDS可實現海量數據下的自動分庫分表，具有高性能，分布式，彈性升級，兼容MySQL等優點，適用於高並發、大規模數據的在線交易， 歷史 數據查詢，自動數據分片等業務場景，歷經多次618，雙十一的考驗，已經在京東集團內大規模使用。
京東雲DRDS產品有以下主要特性
1）自動分庫分表
通過簡單的定義即可自動實現分庫分表，將數據實際存放在多個MySQL實例的資料庫中，但呈現給應用程序的依舊是一張表，對業務透明，應用程序幾乎無需改動，實現了對資料庫存儲和處理能力的水平擴展。
2）分布式架構
基於分布式架構的集群方案，多個對等節點同時對外提供服務，不但可有效規避服務的單點故障，而且更加容易擴展。
3）超強性能
具有極高的處理能力，雙節點即可支持數萬QPS，滿足用戶超大規模處理能力的需求。
4）兼容MySQL
兼容絕大部分MySQL語法，包括MySQL語法、數據類型、索引、常用函數、排序、關聯等DDL，DML語句，使用成本低。
參考鏈接：
https://www.jdcloud.com/cn/procts/drds
RadonDB發布1.0.3版本
2018年12月26日，MyNewSQL領域的RadonDB雲資料庫發布1.0.3版本。
推出dbaplus Newsletter的想法
dbaplus Newsletter旨在向廣大技術愛好者提供資料庫行業的最新技術發展趨勢，為社區的技術發展提供一個統一的發聲平台。為此，我們策劃了RDBMS、NoSQL、NewSQL、時間序列、大數據生態圈、國產資料庫、雲資料庫等幾個版塊。
我們不以商業宣傳為目的，不接受任何商業廣告宣傳，嚴格審查信息源的可信度和准確性，力爭為大家提供一個純凈的技術學習環境，歡迎大家監督指正。
至於Newsletter發布的周期，目前計劃是每三個月左右會做一次跟進， 下期計劃時間是2019年4月14日~4月25日， 如果有相關的信息提供請發送至郵箱：[email protected]
感謝名單
最後要感謝那些提供寶貴信息和建議的專家朋友，排名不分先後。
往期回顧：
↓↓別忘了點這里下載 2019年1月 完整版Newsletter 哦~
⑶ 咋測試tidb自增id是不是唯一
咋測試tidb自增id是唯一。tidb的自增id只能保證唯一性，不保證自增性和連續性，也不支持在線添加列auto_increment屬性，tidb的主鍵索引和唯一索引的存儲方式相同，不支持全文索引、空間索引、僅支持utf8/utf8mb4/ascii/latin1/binary幾個字元集。
tidb的存儲能力
無限水平擴展是TiDB的一大特點，這里說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server負責處理SQL請求，隨著業務的增長，可以簡單的添加TiDB Server節點，提高整體的處理能力，提供更高的吞吐。
TiKV負責存儲數據，隨著數據量的增長，可以部署更多的TiKV Server節點解決數據Scale的問題。PD會在TiKV節點之間以Region為單位做調度，將部分數據遷移到新加的節點上。所以在業務的早期，可以只部署少量的服務實例（推薦至少部署3個TiKV，3個PD，2個TiDB），隨著業務量的增長，按照需求添加TiKV或者TiDB實例。
⑷ 騰訊tidb是自研的嗎
不是的。
最開始，我們調研了開源的分布式NewSQL方案：TIDB。雖然TIDB是非常優秀的NewSQL產品，但是對於我們的業務場景來說，TIDB並不是非常適合，原因如下：
需要一款高吞吐，低延遲的資料庫解決方案，但是TIDB由於要滿足事務，2pc方案天然無法滿足低延遲（100ms以內的99rt，甚至50ms內的99rt）
多數業務，並不真正需要分布式事務，或者說可以通過其他補償機制，繞過分布式事務。這是由於業務場景決定的。
TIDB三副本的存儲空間成本相對比較高。
內部一些離線數據導入在線系統的場景，不能直接和TIDB打通。
基於以上原因，我們開啟了自研符合自己業務需求的NewSQL之路。
⑸ newsql和nosql的區別和聯系
TiDB 是 PingCAP 公司設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是為 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。
TiDB 具備如下特性：
高度兼容 MySQL
大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。
水平彈性擴展
通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。
分布式事務
TiDB 100% 支持標準的 ACID 事務。
真正金融級高可用
相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。
一站式 HTAP 解決方案
TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。
雲原生 SQL 資料庫
TiDB 是為雲而設計的資料庫，支持公有雲、私有雲和混合雲，配合TiDB Operator 項目可實現自動化運維，使部署、配置和維護變得十分簡單。
TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以通過TiSpark 項目來完成。
TiDB 對業務沒有任何侵入性，能優雅地替換傳統的資料庫中間件、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專注於業務開發，極大地提升研發的生產力。
⑹ 國內做分布式資料庫開發的現狀如何
應該說，現在是國產分布式資料庫發展的利好時期。在討論發展前景前，首先要先看看分布式資料庫的發展方向。
大家把傳統關系型資料庫稱作oldSQL，給人感覺要被淘汰似的。但其實數據量不是很大或者事務處理的場景夏，關系型資料庫的還是占優的。
關系型資料庫的主要問題在於：
性能瓶頸，
單一模型（關系模型），只適合OLTP
應對業務的靈活性不夠，
彈性擴充能力不夠，
兩地三中心和雙活等問題上不足。
隨著互聯網和手機的飛速發展，無論從用戶規模、使用頻率、還是場景多樣性都使得這些問題浮出水面。其實Oracle在92年就開始嘗試轉向分布式，還當時引起了業界的巨大爭論，最後失敗。更何況過去CPU、內存、存儲、帶寬的高成本導致分布式資料庫的性價比並不高，只能停留在學術階段，限制了分布式的發展。
新分布式資料庫首先是要避免和傳統關系型資料庫的競爭，這是明智的選擇，能夠輕裝上陣。因此從幾個方面入手，應對海量數據處理、分析、緩存、流式處理、開發模式等等。相對應列式，KV，Document等多種存儲數據結構。
所有這些都被稱為NoSQL資料庫，放棄ACID和事務能力還換取性能。然而，NoSQL又收到了大量的批評反對意見，主要是說把資料庫應該處理的問題交還給了開發是種發展的倒退。這些問題包括，索引、版本、SQL支持、事務支持等等。市場上超過90%的開發員都需要SQL，而且SQL也是非常有效和成熟。於是大家無論底層是什麼存儲結構又開始支持SQL，形成了NewSQL。
這里插一句題外話，在矽谷已經不再用SQL、NoSQL、NewSQL來劃分資料庫了。理由很簡單，SQL是一種語言，從來沒有SQL資料庫的說法，自然也不應該有NoSQL資料庫的說法。NewSQL資料庫就更不合理，用的SQL並非什麼「New「的新東西。所以專業上用關系型和非關系型資料庫來劃分，分布式資料庫主要都是非關系型資料庫。
回過頭來看國內分布式資料庫市場需求，中小企業不滿足Mysql的性能，分庫分表又很難搞，也不徹底；大型企業被Oracle等壟斷支付高額成本，而且又不解決實際碰到的瓶頸問題。因此，用戶都在尋找新的解決方案。小型用戶、雲計算的用戶、大型企業都需要對應的分布式資料庫產品。
再加上國產自主和去IOE浪潮，更加推動了國產分布式資料庫的發展利好。值得注意的是，資料庫研發是個嚴肅的事情，沒法短平快。
⑺ TiDB 集群的可用性詳解及 TiKV Label 規劃
目 錄
一、前言
二、TiDB 集群核心組件可用性概覽
1. TiDB Server 的可用性
三、Multi-Raft 集群的可用性限制
1. Raft 簡介
2. Raft Group 副本數的選擇
3. PD 是單一 Raft Group
4. TiKV 是 Multi-Raft 系統
5. Multi-Raft 集群的可用性限制
四、規劃 TiKV Label 以提升 TiKV 集群的可用性
1. TiKV Label 簡介
2. Label 相關的 PD 調度策略解讀
3. TiKV Label 的規劃
4. 使用 Label 的注意事項
五、典型兩地三中心跨中心高可用多活容災備配置
1. 物理伺服器主機配置
2. 伺服器，機櫃，機房，網路要求
3. 兩地三中心集群的擴容策略
分布式系統的核心理念是讓多台伺服器協同工作，完成單台伺服器無法處理的任務。單點的硬體和網路等都是不可靠的，想要提高硬體的可靠性需要付出大量的成本，因此分布式系統往往通過軟體來實現對於硬體的容錯，通過軟體來保證整體系統的高可靠性。
TiDB 集群中包含了串-並聯系統，表決系統等，相對於一般的分布式系統更為復雜，TiDB 中所保存的數據的可用性由諸多因素控制，通過本篇文章的介紹，您可以了解到怎樣在給定的資源下設計部署架好頃皮構以盡可能地提高數據的可用性。
在 TiDB 集群的三個核心組件 PD，TiKV，TiDB 中，PD 和 TiKV 都採用 Raft 協議實現持久化數據的容災以及自動的故障轉移，有關 PD 和 TiKV 的可用性的詳細解讀，請參見第三章的內容。
TiDB Server 組件不涉及數據的持久化，因此 TiDB 被設計成了無狀態的，TiDB 進程可以在任意位置被啟動，多個 TiDB 之間的關系是對等的，並發的事務通過同一台 TiDB 發送給集群和通過多台 TiDB 發送給集群所表現的行為完全一致。單一 TiDB 的故障只會影響這個 TiDB 上當前的連接，對其他 TiDB 上的連接沒有任何影響。
根據用戶最佳實踐，在 TiDB 之上一般會部署負載均衡器（F5，LVS，HAproxy，Nginx 等），因此負載均衡器所連接的 TiDB 越多，其整體可用性就越高，其整體所能承載的並發請求數量也越多。
在使用負載均衡器的場景下，建議使用的負載均衡演算法為 least connection，當某個 TiDB 發生故障依然會導致當時連接到該 TiDB 上的請求失敗，負載均衡器識別到 TiDB 的故障之後，將不再向此 TiDB 建立新的連接，而是將新的連接建立到可用的 TiDB 上，以此來實現整體的高可用。
Raft 是一種分布式一致性演算法，在 TiDB 集群的多種組件中，PD 和 TiKV 都通過 Raft 實現了數據的容災。Raft 的災難恢復能力通過如下機制實現：
Raft 演算法本身以及 TiDB 中的 Raft 實現都沒有限制一個 Raft Group 的副本數，這個副本數可以為任意正整數，當副本數為 n 的時候，一個 Raft Group 的可靠性如下：
我們一般建議將 Raft Group 的副本數設置為奇數，其原因如下：
在一般的非關鍵業務場景乎旅下，建議將副本數選為 3；而在關鍵業務中建議將副本數選為 5。
遵循 Raft 可靠性的特點，放到現實場景中：
PD 集群只包含一個 Raft Group，即 PD 集群中 PD 服務的個數決定了 PD 的副本數，3 PD 節點集群的 PD 副本數為 3，5 PD 節點集群的 PD 副本數為 5。
由上一段落中 Raft 原理可知，一個 Raft Group 的容災能力隨節點數增加而加強，在一般的非關鍵業務場景下，建議部署 3 個 PD；建議在關鍵業務中部署 5 個 PD。
TiKV 是一個 Key-Value 存儲系友差統，它是一個巨大的 Map，TiKV 提供有序遍歷方法。下圖展示了 region 以 3 副本模式存儲在 4 台 TiKV 節點上的數據分布，TiKV 中的數據被切分成了 5 份 —— region 1~5，每個 region 的 3 個副本構成了一個 Raft Group，集群中共有 5 個 Raft Group，因此 TiKV 是 Multi-Raft 系統。
如上圖所展示，雖然這個集群當前有 4 個 TiKV 實例，但一個 region 的 3 個副本只會被調度到其中 3 個 TiKV 上，也就是說 region 的副本數與 TiKV 實例數量無關，即使將上圖的集群擴容到 1000 個 TiKV 實例，它也仍然是一個 3 副本的集群。
前面說到 3 副本的 Raft Group 只能容忍 1 副本故障，當上圖的集群被擴容到 1000 個 TiKV 實例時，這個集群依然只能容忍一個 TiKV 實例的故障，2 個 TiKV 實例的故障可能會導致某些 region 丟失多個副本，整個集群的數據也不再完整，訪問到這些 region 上的數據的 SQL 請求將會失敗。
而 1000 個 TiKV 中同時有兩個發生故障的概率是遠遠高於 3 個 TiKV 中同時有兩個發生故障的概率的，也就是說 Multi-Raft 集群在逐步擴容中，其可用性是逐漸降低的。
TiKV Label 用於描述 TiKV 的位置信息，在 inventory.ini 中，其寫法如下：
上面案例中規劃了 4 層位置信息的 Label，Label 信息會隨著 deploy.yml 或 rolling_update.yml 操作刷新到 TiKV 的啟動配置文件中，啟動後的 TiKV 會將自己最新的 Label 信息上報給 PD，PD 根據用戶登記的 Label 名稱（也就是 Label 元信息），結合 TiKV 的拓撲進行 region 副本的最優調度。用戶可以根據自己的需要來定製 Label 名稱，以及 Label 層級（注意層級有先後順序），但需要注意 PD 會根據它讀到的 Label 名稱（含層級關系）去匹配 TiKV 的位置信息，如果 PD 讀到的 TiKV Label 信息與 PD 中設置的 Label 名稱不匹配的話，就不會按用戶設定的方式進行副本調度。Label 名稱的設置方法如下，在初次啟動集群時，PD 會讀取 inventory.ini 中的設置：
非初次啟動的集群，需要使用 pd-ctl 工具進行 Label 名稱設置：
從本質上來說，Label 系統是一種 PD 對 region 副本（replica）的隔離調度策略。
PD 首先讀取到集群的 region 副本數信息*，假定副本數為 5。PD 將所有 TiKV 匯報給它的 Label 信息進行匯總（以本章第 1 小節的 TiKV 集群為例），PD 構建了整個 TiKV 集群的拓撲，其邏輯如下圖所示：
PD 識別到第一層 Label - dc 有 3 個不同的值，無法在本層實現 5 副本的隔離。PD 進而判斷第二層 Label - zone，本層有 z1~z5 這 5 個 zone，可以實現 5 副本的隔離調度，PD 會將各個 region 的 5 個副本依次調度到 z1~z5 中，因此 z1~z5 各自所對應的 4 個 TiKV 所承載的 region 數量總和應完全一致。此時，PD 的常規調度策略，如 balance-region，hot-region 等 region 相關的 scheler 將嚴格遵守 Label 的隔離策略進行調度，在帶有 z1~z5 Label 信息的 TiKV 尚在的情況下不會將同一個 region 的多個副本調度到同一個 zone 中。如圖，圖中將 TiKV 按照 zone 做 4 個一組隔離開了，一個 region 的一個副本只會在本 zone 的 4 個 TiKV 之間調度。
PD 天生不會將同一個 region 的多個副本調度到同一個 TiKV 實例上，增加 Label 信息後，PD 不會將同一個 region 的多個副本調度到同一個 host 上，以避免單台伺服器的宕機導致丟失多個副本。
當帶有某一個 zone Label 的 TiKV 全部故障時，如圖中所有帶有 z5 Label 的幾個 TiKV 實例 kv252-1，kv252-2，kv253-1，kv253-2 同時故障時，集群會進入缺失一個副本的狀態，在達到 TiKV 最大離線時間的設置值（max-store-down-time，默認值 30min）之後，PD 便開始在其他 4 個 zone 中補全所有缺失副本的 region，同時遵循上面一段所提到的約束，在為 region1 補全副本時，PD 會避開所有包含 region1 的伺服器（本例中的 host）h208，h210，h414，h416 所涉及的 8 個 TiKV 實例，而在另外 8 個 TiKV 實例中挑選一個進行副本補全調度。
*副本數設置方法如下，以 5 副本為例：
Label 登記的是 TiKV 的物理位置信息，PD 根據 TiKV 的物理位置進行最優調度，其目的是在具有相近物理位置的 TiKV 上只放置一個副本，以盡可能的提高 TiKV 集群的可用性。舉個例子，假設某一時刻集群中一定要有兩個 TiKV 同時發生故障，那麼你一定不想它們上面存儲著一個 region 的兩個副本，而通過合理規劃讓同時故障的兩個 TiKV 出現在同一個隔離區的概率變高，TiKV 集群的整體可用性也就越高。因此 Label 規劃要與 TiKV 物理位置規劃一起進行，兩者是相輔相成的。
舉例而言，機房可能會由於電源故障，空調故障，網路故障，火災，自然災害等原因而整體不可用；機櫃可能由於交換機故障，UPS 故障，消防噴淋等原因而整體不可用；伺服器可能由於常見的內存等故障而宕機。通過妥善的 Label 規劃，使 region 調度按物理位置進行隔離，可以有效地降低一個區域故障造成的整體影響。
物理位置的層級結構一般為機房，機櫃，伺服器，在大型基礎設施中還會在機房與機櫃之間多一個樓層信息。設計 Label 層級結構的最佳實踐是基於物理層級結構再加上一層邏輯層級，該邏輯層級專門用於控制保持與集群副本數一致，在本案例中，zone 就是邏輯層級，該層級的值在集群搭建初期與 rack 保持一一對應，用於控制副本的隔離。而不直接採用 dc，rack，host 三層 Label 結構的原因是考慮到將來可能發生 rack 的擴容（假設新擴容的 rack 編號是 r6，r7，r8，r9，r10），這個擴容會導致 rack 數變多，當多個 TiKV 實例同時發生故障時，這些故障的 TiKV 出現在在多個 rack 上的概率也會增加，也就是會將第三章提到的 Multi-Raft 集群的可用性隨節點數增加而下降問題再次引入到集群中。而通過使用邏輯層級 zone 保持與副本數一致可以將多個故障的 TiKV 出現在不同的隔離區（本例中的 zone）的概率降至最低，將來擴容 rack 也可以充分的利用到更多的 rack 的物理隔離來提高可用性。
在使用了 Label 隔離的集群中，存在以下限制：
規劃了 Label 的集群再擴容時需要對每個隔離區進行容量一致的擴容，在本章的案例中，隔離區為 dc 和 rack 標示的位置，因此需要對每種 dc+rack 組合的區域進行容量一致的擴容，比如將要擴容 5 台 TiKV 伺服器，其分配方法如下：
zone1=>dc1:rack1 增加一台 TiKV
zone2=>dc1:rack2 增加一台 TiKV
zone3=>dc2:rack1 增加一台 TiKV
zone4=>dc2:rack2 增加一台 TiKV
zone5=>dc3:rack1 增加一台 TiKV**