IT就到黑馬程序員.gif "學(xué)IT就到黑馬程序員")
數(shù)據(jù)庫技術(shù)產(chǎn)生于20世紀(jì)60年代末70年代初，其主要主要研究如何存儲(chǔ)，使用和管理數(shù)據(jù)。隨著計(jì)算機(jī)硬件和軟件的發(fā)展，數(shù)據(jù)庫技術(shù)也不斷地發(fā)展。數(shù)據(jù)庫技術(shù)在理論研究和系統(tǒng)開發(fā)上都取得了輝煌的成就。
從數(shù)據(jù)管理的角度看，數(shù)據(jù)庫技術(shù)到目前共經(jīng)歷了如下三個(gè)階段：
1. 人工管理階段-數(shù)據(jù)量小獨(dú)立,用戶直接管理
2. 文件系統(tǒng)階段-使用文件存取數(shù)據(jù),冗余度高,管理維護(hù)難
3. 數(shù)據(jù)庫系統(tǒng)階段-專門的數(shù)據(jù)庫軟件系統(tǒng)管理數(shù)據(jù),高效方便,易于共享維護(hù)
按照數(shù)據(jù)模型發(fā)展的主線，數(shù)據(jù)庫技術(shù)的形成過程和發(fā)展可分為如下三個(gè)階段：
1. 層次和網(wǎng)狀數(shù)據(jù)庫管理系統(tǒng)-可以理解為使用指針來表示數(shù)據(jù)之間的聯(lián)系
2. 關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)-可以理解為理解為使用二維表來表示維護(hù)數(shù)據(jù)間的關(guān)系
3. 新一代數(shù)據(jù)庫技術(shù)的研究和發(fā)展-針對(duì)關(guān)系型數(shù)據(jù)庫存在數(shù)據(jù)模型，性能，擴(kuò)展性，伸縮性等方面的缺點(diǎn)，出現(xiàn)了：
ORDBMS:面向?qū)ο髷?shù)據(jù)庫技術(shù)。如：PostGreSQL
NoSQL:非結(jié)構(gòu)化數(shù)據(jù)庫技術(shù)。如
1):鍵值存儲(chǔ)數(shù)據(jù)庫：Redis
2):列式儲(chǔ)數(shù)數(shù)據(jù)庫：HBase
3):文檔型數(shù)據(jù)庫：MongoDB
4):圖形數(shù)據(jù)庫：Neo4J
NewSQL:這類數(shù)據(jù)庫不僅具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性。如：TiDB
如今的數(shù)據(jù)庫種類繁多，RDBMS（關(guān)系型數(shù)據(jù)庫）、NoSQL（Not Only SQL）、NewSQL，在數(shù)據(jù)庫領(lǐng)域均有一席之地，可謂百家爭(zhēng)鳴之勢(shì)。那么我們?yōu)槭裁匆獙W(xué)習(xí)使用TiDB呢？接下來就從我們最熟悉的MySQL的使用說起！
假設(shè)現(xiàn)在有一個(gè)高速發(fā)展的互聯(lián)網(wǎng)公司,核心業(yè)務(wù)庫MySQL的數(shù)據(jù)量已經(jīng)近億行,且還在不斷增長(zhǎng)中,公司對(duì)于數(shù)據(jù)資產(chǎn)較為重視,所有數(shù)據(jù)要求多副本保存至少5年,且除了有對(duì)歷史數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析的離線報(bào)表業(yè)務(wù)外,還有一些針對(duì)用戶數(shù)據(jù)實(shí)時(shí)查詢的需求,如用戶歷史訂單實(shí)時(shí)查詢。
由此產(chǎn)生了下面的問題：
1.MySQL能否滿足上述場(chǎng)景需求?
根據(jù)以往的MySQL使用經(jīng)驗(yàn)，MySQL單表在 5000 萬行以內(nèi)時(shí)，性能較好，單表超過5000萬行后，數(shù)據(jù)庫性能、可維護(hù)性都會(huì)極劇下降。當(dāng)然這時(shí)候可以做MySQL分庫分表,如使用Mycat或Sharding-jdbc
2.分庫分表的能否解決問題?
分庫分表的優(yōu)點(diǎn)非常明顯，如：
將大表拆分成小表，單表數(shù)據(jù)量控制在 5000 萬行以內(nèi)，使 MySQL 性能穩(wěn)定可控。
將單張大表拆分成小表后，能水平擴(kuò)展，通過部署到多臺(tái)服務(wù)器，提升整個(gè)集群的 QPS、TPS、Latency 等數(shù)據(jù)庫服務(wù)指標(biāo)。
但是，此方案的缺點(diǎn)也非常明顯：
分表跨實(shí)例后，產(chǎn)生分布式事務(wù)管理難題，一旦數(shù)據(jù)庫服務(wù)器宕機(jī)，有事務(wù)不一致風(fēng)險(xiǎn)。
分表后，對(duì) SQL 語句有一定限制，對(duì)業(yè)務(wù)方功能需求大打折扣。尤其對(duì)于實(shí)時(shí)報(bào)表統(tǒng)計(jì)類需求，限制非常之大。事實(shí)上，報(bào)表大多都是提供給高層領(lǐng)導(dǎo)使用的，其重要性不言而喻。
分表后，需要維護(hù)的對(duì)象呈指數(shù)增長(zhǎng)（MySQL實(shí)例數(shù)、需要執(zhí)行的 SQL 變更數(shù)量等）。
問題解決：
于以上核心痛點(diǎn)，我們需要探索新的數(shù)據(jù)庫技術(shù)方案來應(yīng)對(duì)業(yè)務(wù)爆發(fā)式增長(zhǎng)所帶來的挑戰(zhàn)，為業(yè)務(wù)提供更好的數(shù)據(jù)庫服務(wù)支撐。
調(diào)研市場(chǎng)上的各大數(shù)據(jù)庫,我們可以考慮選用NewSQL技術(shù)來解決,因?yàn)镹ewSQL技術(shù)有如下顯著特點(diǎn):
- 無限水平擴(kuò)展能力
- 分布式強(qiáng)一致性，確保數(shù)據(jù) 100% 安全
- 完整的分布式事務(wù)處理能力與 ACID 特性
而TiDB數(shù)據(jù)庫 GitHub的活躍度及社區(qū)貢獻(xiàn)者方面都可以算得上是國(guó)際化的開源項(xiàng)目,是NewSQL技術(shù)中的代表性產(chǎn)品,所以我們可以選擇使用TiDB數(shù)據(jù)庫!
總結(jié)
傳統(tǒng)關(guān)系型數(shù)據(jù)庫歷史比較久，目前RDBMS的代表為Oracle、MySQL、PostgreSQL，在數(shù)據(jù)庫領(lǐng)域也是“輩份”比較高的，其廣泛應(yīng)用在各行各業(yè)，RDBMS大多為本地存儲(chǔ)或共享存儲(chǔ)。
但是此類數(shù)據(jù)庫存在著一些問題，如自身容量的限制。隨著業(yè)務(wù)量不斷增加，容量漸漸成為瓶頸，此時(shí)DBA會(huì)通過多次的庫表sharding，以此來緩解容量問題。大量的分庫分表，不僅耗費(fèi)了大量人力，還使得業(yè)務(wù)訪問數(shù)據(jù)庫的路由邏輯變得復(fù)雜。除此之外，RDBMS伸縮性比較差，通常集群擴(kuò)容縮容成本較高，且不滿足分布式的事務(wù)。
NoSQL類數(shù)據(jù)庫的代表為Hbase、Redis、MongoDB、Cassandra等，這類數(shù)據(jù)庫解決了 RDBMS伸縮性差的問題，集群容量擴(kuò)容變得方便很多，但是由于存儲(chǔ)方式為多個(gè)KV存儲(chǔ)，所以對(duì)SQL的兼容性就大打折扣。對(duì)于NoSQL類數(shù)據(jù)庫來說，只能滿足部分分布式事務(wù)的特點(diǎn)。
NewSQL領(lǐng)域的代表是Google的spanner和F1，其號(hào)稱可以實(shí)現(xiàn)全球數(shù)據(jù)中心容災(zāi)，且完全滿足分布式事務(wù)的ACID，但是只能在Google云上使用。
TiDB誕生在大背景下，也彌補(bǔ)了國(guó)內(nèi)在NewSQL領(lǐng)域中的空缺。TiDB自2015年5月寫下第一行代碼以來，至今已發(fā)布大小版本幾十次，版本迭代十分迅速猜你喜歡：
什么是數(shù)據(jù)庫事務(wù)?
使用MySQL數(shù)據(jù)庫,實(shí)現(xiàn)你的第一個(gè)JDBC程序
使用Django開發(fā)網(wǎng)站，如何優(yōu)化數(shù)據(jù)庫？
黑馬程序員python大數(shù)據(jù)開發(fā)課程
javaee科列表頁面右側(cè)廣告圖.jpg)
python大數(shù)據(jù)
web科列表頁面右側(cè)廣告圖230x148.jpg)
ui據(jù)學(xué)科列表頁右側(cè).png)
cloud科列表頁面右側(cè)廣告圖.jpg)
test
c
netmarket
pm
Linux
movies
robot
uids
AI.jpg)
jdbc
JavaEE
鴻蒙應(yīng)用開發(fā)
HTML&JS+前端
Python+大數(shù)據(jù)開發(fā)
人工智能開發(fā)
AI+設(shè)計(jì)
軟件測(cè)試
新媒體+短視頻
集成電路應(yīng)用開發(fā)
