數(shù)據(jù)庫技術(shù)發(fā)展簡史，3分鐘了解數(shù)據(jù)庫技術(shù)

更新時間:2021年09月29日18時28分來源:傳智教育瀏覽次數(shù):

數(shù)據(jù)庫技術(shù)產(chǎn)生于20世紀60年代末70年代初，其主要主要研究如何存儲，使用和管理數(shù)據(jù)。隨著計算機硬件和軟件的發(fā)展，數(shù)據(jù)庫技術(shù)也不斷地發(fā)展。數(shù)據(jù)庫技術(shù)在理論研究和系統(tǒng)開發(fā)上都取得了輝煌的成就。
從數(shù)據(jù)管理的角度看，數(shù)據(jù)庫技術(shù)到目前共經(jīng)歷了如下三個階段：
1. 人工管理階段-數(shù)據(jù)量小獨立,用戶直接管理
2. 文件系統(tǒng)階段-使用文件存取數(shù)據(jù),冗余度高,管理維護難
3. 數(shù)據(jù)庫系統(tǒng)階段-專門的數(shù)據(jù)庫軟件系統(tǒng)管理數(shù)據(jù),高效方便,易于共享維護

按照數(shù)據(jù)模型發(fā)展的主線，數(shù)據(jù)庫技術(shù)的形成過程和發(fā)展可分為如下三個階段：
1. 層次和網(wǎng)狀數(shù)據(jù)庫管理系統(tǒng)-可以理解為使用指針來表示數(shù)據(jù)之間的聯(lián)系
2. 關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)-可以理解為理解為使用二維表來表示維護數(shù)據(jù)間的關(guān)系
3. 新一代數(shù)據(jù)庫技術(shù)的研究和發(fā)展-針對關(guān)系型數(shù)據(jù)庫存在數(shù)據(jù)模型，性能，擴展性，伸縮性等方面的缺點，出現(xiàn)了：
ORDBMS:面向?qū)ο髷?shù)據(jù)庫技術(shù)。如：PostGreSQL
NoSQL:非結(jié)構(gòu)化數(shù)據(jù)庫技術(shù)。如
1):鍵值存儲數(shù)據(jù)庫：Redis
2):列式儲數(shù)數(shù)據(jù)庫：HBase
3):文檔型數(shù)據(jù)庫：MongoDB
4):圖形數(shù)據(jù)庫：Neo4J
NewSQL:這類數(shù)據(jù)庫不僅具有NoSQL對海量數(shù)據(jù)的存儲管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性。如：TiDB

如今的數(shù)據(jù)庫種類繁多，RDBMS（關(guān)系型數(shù)據(jù)庫）、NoSQL（Not Only SQL）、NewSQL，在數(shù)據(jù)庫領(lǐng)域均有一席之地，可謂百家爭鳴之勢。那么我們?yōu)槭裁匆獙W習使用TiDB呢？接下來就從我們最熟悉的MySQL的使用說起！
假設現(xiàn)在有一個高速發(fā)展的互聯(lián)網(wǎng)公司,核心業(yè)務庫MySQL的數(shù)據(jù)量已經(jīng)近億行,且還在不斷增長中,公司對于數(shù)據(jù)資產(chǎn)較為重視,所有數(shù)據(jù)要求多副本保存至少5年,且除了有對歷史數(shù)據(jù)進行統(tǒng)計分析的離線報表業(yè)務外,還有一些針對用戶數(shù)據(jù)實時查詢的需求,如用戶歷史訂單實時查詢。

由此產(chǎn)生了下面的問題：
1.MySQL能否滿足上述場景需求?
根據(jù)以往的MySQL使用經(jīng)驗，MySQL單表在 5000 萬行以內(nèi)時，性能較好，單表超過5000萬行后，數(shù)據(jù)庫性能、可維護性都會極劇下降。當然這時候可以做MySQL分庫分表,如使用Mycat或Sharding-jdbc
2.分庫分表的能否解決問題?
分庫分表的優(yōu)點非常明顯，如：
將大表拆分成小表，單表數(shù)據(jù)量控制在 5000 萬行以內(nèi)，使 MySQL 性能穩(wěn)定可控。
將單張大表拆分成小表后，能水平擴展，通過部署到多臺服務器，提升整個集群的 QPS、TPS、Latency 等數(shù)據(jù)庫服務指標。
但是，此方案的缺點也非常明顯：
分表跨實例后，產(chǎn)生分布式事務管理難題，一旦數(shù)據(jù)庫服務器宕機，有事務不一致風險。
分表后，對 SQL 語句有一定限制，對業(yè)務方功能需求大打折扣。尤其對于實時報表統(tǒng)計類需求，限制非常之大。事實上，報表大多都是提供給高層領(lǐng)導使用的，其重要性不言而喻。
分表后，需要維護的對象呈指數(shù)增長（MySQL實例數(shù)、需要執(zhí)行的 SQL 變更數(shù)量等）。
問題解決：
于以上核心痛點，我們需要探索新的數(shù)據(jù)庫技術(shù)方案來應對業(yè)務爆發(fā)式增長所帶來的挑戰(zhàn)，為業(yè)務提供更好的數(shù)據(jù)庫服務支撐。
調(diào)研市場上的各大數(shù)據(jù)庫,我們可以考慮選用NewSQL技術(shù)來解決,因為NewSQL技術(shù)有如下顯著特點:
- 無限水平擴展能力
- 分布式強一致性，確保數(shù)據(jù) 100% 安全
- 完整的分布式事務處理能力與 ACID 特性
而TiDB數(shù)據(jù)庫 GitHub的活躍度及社區(qū)貢獻者方面都可以算得上是國際化的開源項目,是NewSQL技術(shù)中的代表性產(chǎn)品,所以我們可以選擇使用TiDB數(shù)據(jù)庫!

總結(jié)

傳統(tǒng)關(guān)系型數(shù)據(jù)庫歷史比較久，目前RDBMS的代表為Oracle、MySQL、PostgreSQL，在數(shù)據(jù)庫領(lǐng)域也是“輩份”比較高的，其廣泛應用在各行各業(yè)，RDBMS大多為本地存儲或共享存儲。
但是此類數(shù)據(jù)庫存在著一些問題，如自身容量的限制。隨著業(yè)務量不斷增加，容量漸漸成為瓶頸，此時DBA會通過多次的庫表sharding，以此來緩解容量問題。大量的分庫分表，不僅耗費了大量人力，還使得業(yè)務訪問數(shù)據(jù)庫的路由邏輯變得復雜。除此之外，RDBMS伸縮性比較差，通常集群擴容縮容成本較高，且不滿足分布式的事務。
NoSQL類數(shù)據(jù)庫的代表為Hbase、Redis、MongoDB、Cassandra等，這類數(shù)據(jù)庫解決了 RDBMS伸縮性差的問題，集群容量擴容變得方便很多，但是由于存儲方式為多個KV存儲，所以對SQL的兼容性就大打折扣。對于NoSQL類數(shù)據(jù)庫來說，只能滿足部分分布式事務的特點。
NewSQL領(lǐng)域的代表是Google的spanner和F1，其號稱可以實現(xiàn)全球數(shù)據(jù)中心容災，且完全滿足分布式事務的ACID，但是只能在Google云上使用。
TiDB誕生在大背景下，也彌補了國內(nèi)在NewSQL領(lǐng)域中的空缺。TiDB自2015年5月寫下第一行代碼以來，至今已發(fā)布大小版本幾十次，版本迭代十分迅速

猜你喜歡：

如何優(yōu)化數(shù)據(jù)庫的查詢提高查詢效率？

JDBC連接oracle數(shù)據(jù)庫步驟【實戰(zhàn)教程】

Mybatis原理介紹：MyBatis如何操作數(shù)據(jù)庫？

MySQL數(shù)據(jù)庫常用的搜索引擎有哪些，區(qū)別是什么？

傳智教育python大數(shù)據(jù)開發(fā)培訓

上一篇：Kafka基準測試怎樣進行？ 下一篇：什么是Kafka？Kafka誕生的背景是什么？