關係型資料庫,NoSQL資料庫整理:mysql,mariaDB,Percona Server,MongoDB,Redis,RocksDB
資料庫分類對比
英文名 | 中文名 | 定義 | 儲存方式 | ACID規則支援情況 | CAP原理支援情況 |
---|---|---|---|---|---|
Relational database | 關係型資料庫 | 採用了關係模型來組織資料的資料庫 | 表格 | 支援ACID規則 | 滿足CP,但A不完美 |
NoSQL | 非關係型資料庫 | 泛指非關係型的資料庫,不保證關係資料的ACID特性 | 鍵值儲存、列儲存、文件儲存等 | 不一定完全支援ACID規則 | 滿足AP,但C不完美 |
NewSQL | NewSQL | NewSQL是對各種新的可擴充套件/高效能資料庫的簡稱 | 多種儲存方式 | 支援ACID規則 | 滿足CAP |
ACID規則
- 原子性(A)
一個事務的所有系列操作步驟被看成一個動作,所有的步驟要麼全部完成,要麼一個也不會完成。如果在事務過程中發生錯誤,則會回滾到事務開始前的狀態,將要被改變的資料庫記錄不會被改變。 - 一致性(C)
一致性是指在事務開始之前和事務結束以後,資料庫的完整性約束沒有被破壞,即資料庫事務不能破壞關係資料的完整性及業務邏輯上的一致性。 - 隔離性(I)
主要用於實現併發控制,隔離能夠確保併發執行的事務按順序一個接一個地執行。通過隔離,一個未完成事務不會影響另外一個未完成事務。 - 永續性(D)
一旦一個事務被提交,它應該持久儲存,不會因為與其他操作衝突而取消這個事務。
CAP原理
- Consistency(一致性): 資料一致更新,所有資料變動都是同步的
- Availability(可用性): 好的響應效能
- Partition tolerance(分割槽耐受性): 可靠性
舉例來說在高可用的網站架構中,對於資料基礎提出了以下的要求:
- 分割槽耐受性
保證資料可持久儲存,在各種情況下都不會出現資料丟失的問題。為了實現資料的永續性,不但需要在寫入的時候保證資料能夠持久儲存,還需要能夠將資料備份一個或多個副本,存放在不同的物理裝置上,防止某個儲存裝置發生故障時,資料不會丟失。 - 資料一致性
在資料有多份副本的情況下,如果網路、伺服器、軟體出現了故障,會導致部分副本寫入失敗。這就造成了多個副本之間的資料不一致,資料內容衝突。 - 資料可用性
多個副本分別儲存於不同的物理裝置的情況下,如果某個裝置損壞,就需要從另一個資料儲存裝置上訪問資料。如果這個過程不能很快完成,或者在完成的過程中需要停止終端使用者訪問資料,那麼在切換儲存裝置的這段時間內,資料就是不可訪問的。
關係型資料庫,是指採用了關係模型來組織資料的資料庫
- 關係模型指的就是二維表格模型,而一個關係型資料庫就是由二維表及其之間的聯絡所組成的一個資料組織。
- 通過SQL結構化查詢語句儲存資料。
- 強調ACID規則, 保持資料一致性。
? MySQL
? 知識體系
MySQL體系詳解
MySQL體系詳解
MySQL架構圖
MySQL架構圖
MySQL億級訂單資料分庫分表設計架構圖
MySQL億級訂單資料分庫分表設計架構圖(鑫語人間)
MySQL億級流量系統設計每秒十萬查詢的高併發架構圖
MySQL億級流量系統設計每秒十萬查詢的高併發架構圖(石杉)
? 儲存引擎
- MyISAM引擎使用B+Tree作為索引結構,葉節點的data域存放的是資料記錄的地址。
- InnoDB引擎使用B+Tree作為索引結構,葉節點儲存了完整的資料記錄(資料和索引)。
- B+樹原理詳解
MyISAM引擎
MyISAM索引實現
- MyISAM引擎使用B+Tree作為索引結構,葉節點的data域存放的是資料記錄的地址。
這裡設表一共有三列,假設我們以Col1為主鍵,則上圖是一個MyISAM表的主索引(Primary key)示意。可以看出MyISAM的索引檔案僅僅儲存資料記錄的地址。在MyISAM中,主索引和輔助索引(Secondary key)在結構上沒有任何區別,只是主索引要求key是唯一的,而輔助索引的key可以重複。如果我們在Col2上建立一個輔助索引,則此索引的結構如下圖所示:
同樣也是一顆B+Tree,data域儲存資料記錄的地址。因此,MyISAM中索引檢索的演算法為首先按照B+Tree搜尋演算法搜尋索引,如果指定的Key存在,則取出其data域的值,然後以data域的值為地址,讀取相應資料記錄。
MyISAM的索引方式也叫做“非聚集”的,之所以這麼稱呼是為了與InnoDB的聚集索引區分。
MyISAM引擎特點
- 不支援事務
- 表級鎖定 資料更新時鎖定整個表:其鎖定機制是表級鎖定,也就是對錶中的一個資料進行操作都會將這個表鎖定,其他人不能操作這個表,這雖然可以讓鎖定的實現成本很小但是也同時大大降低了其併發效能。
- 讀寫互相阻塞 不僅會在寫入的時候阻塞讀取,MyISAM還會再讀取的時候阻塞寫入,但讀本身並不會阻塞另外的讀。
- 只會快取索引 MyISAM可以通過key_buffer_size的值來提高快取索引,以大大提高訪問效能減少磁碟IO,但是這個快取區只會快取索引,而不會快取資料。
- 讀取速度較快 佔用資源相對較少
- 不支援外來鍵約束,但只是全文索引
- MyISAM引擎是MySQL5.5版本之前的預設引擎,是對最初的ISAM引擎優化的產物。
MyISAM引擎適用的生產業務場景
- 不需要事務支援的業務(例如轉賬就不行,充值也不行)
- 一般為讀資料比較多的應用,讀寫都頻繁場景不適合,讀多或者寫多的都適合。
- 讀寫併發訪問都相對較低的業務(純讀純寫高併發也可以)(鎖定機制問題)
- 資料修改相對較少的業務(阻塞問題)
- 以讀為主的業務,例如:blog,圖片資訊資料庫,使用者資料庫,商品庫等業務
- 對資料一致性要求不是很高的業務。
- 中小型的網站部分業務會用。
- 小結:單一對資料庫的操作都可以示用MyISAM,所謂單一就是儘量純讀,或純寫(insert,update,delete)等。
MyISAM引擎調優精要
- 設定合適的索引(快取機制)(where、join後面的列建立索引,重複值比較少的建索引等)
- 調整讀寫優先順序,根據實際需求確保重要操作更優先執行,讀寫的時候可以通過引數設定優先順序。
- 啟用延遲插入改善大批量寫入效能(降低寫入頻率,儘可能多條資料一次性寫入)。
- 儘量順序操作讓insert資料都寫入到尾部,較少阻塞。
- 分解大的操作,降低單個操作的阻塞時間,就像作業系統控制cpu分片一樣。
- 降低併發數(減少對MySQL訪問),某些高併發場景通過應用進行排隊佇列機制Q佇列。
- 對於相對靜態(更改不頻繁)的資料庫資料,充分利用Query Cache(可以通過配置檔案配置)或memcached快取服務可以極大的提高訪問頻率。
- MyISAM的Count只有在全表掃描的時候特別高效,帶有其他條件的count都需要進行實際的資料訪問。
InnoDB引擎
InnoDB索引實現
- InnoDB也使用B+Tree作為索引結構,但具體實現方式卻與MyISAM截然不同。葉節點儲存了完整的資料記錄(資料和索引)。
InnoDB的資料檔案本身就是索引檔案。從上文知道,MyISAM索引檔案和資料檔案是分離的,索引檔案僅儲存資料記錄的地址。而在InnoDB中,表資料檔案本身就是按B+Tree組織的一個索引結構,這棵樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵,因此InnoDB表資料檔案本身就是主索引。
上圖是InnoDB主索引(同時也是資料檔案)的示意圖,可以看到葉節點包含了完整的資料記錄。這種索引叫做聚集索引。因為InnoDB的資料檔案本身要按主鍵聚集,所以InnoDB要求表必須有主鍵(MyISAM可以沒有),如果沒有顯式指定,則MySQL系統會自動選擇一個可以唯一標識資料記錄的列作為主鍵,如果不存在這種列,則MySQL自動為InnoDB表生成一個隱含欄位作為主鍵,這個欄位長度為6個位元組,型別為長整形。
第二個與MyISAM索引的不同是InnoDB的輔助索引data域儲存相應記錄主鍵的值而不是地址。換句話說,InnoDB的所有輔助索引都引用主鍵作為data域。例如,下圖為定義在Col3上的一個輔助索引:
這裡以英文字元的ASCII碼作為比較準則。聚集索引這種實現方式使得按主鍵的搜尋十分高效,但是輔助索引搜尋需要檢索兩遍索引:首先檢索輔助索引獲得主鍵,然後用主鍵到主索引中檢索獲得記錄。
InnoDB引擎適用的生產業務場景
- 支援事務
- 行級鎖定對高併發有很好的適應能力,但需要確保查詢是通過索引完成。
- 資料更新較為頻繁的場景,如:BBS(論壇)、SNS(社交平臺)、微博等
- 資料一致性要求較高的業務,例如:充值轉賬,***轉賬。
- 硬體裝置記憶體較大,可以利用InnoDB較好的快取能力來提高記憶體利用率,儘可能減少磁碟IO,可以通過一些引數來設定
- 相比MyISAM引擎,Innodb引擎更消耗資源,速度沒有MyISAM引擎快
InnoDB引擎調優精要
- 主鍵儘可能小,避免給Secondery index帶來過大的空間負擔。
- 避免全表掃描,因為會使用表鎖。
- 儘可能快取所有的索引和資料,提高響應速度,較少磁碟IO消耗。
- 在大批量小插入的時候,儘量自己控制事務而不要使用autocommit自動提交,有開關可以控制提交方式。
- 合理設定innodb_flush_log_at_trx_commit引數值,不要過度追求安全性。 如果innodb_flush_log_at_trx_commit的值為0,log buffer每秒就會被刷寫日誌檔案到磁碟,提交事務的時候不做任何操作。
- 避免主鍵更新,因為這會帶來大量的資料移動。
其他引擎
⭕ 面試題
? 優化與叢集架構
? 原始碼與配置引數
- MySQL5.7原始碼地址: dev.mysql.com/get/Downloads/MySQL-...
- MySQL8.0原始碼地址: cdn.mysql.com//Downloads/MySQL-8.0...
- MySQL原始碼檔案結構及主要資料結構
- MySQL5.7配置檔案
- MySQL8.0配置檔案
? 視訊資源
? 文章
? 電子書籍
? Paper
⚒ 叢集架構
後續新增…
? 常見問題
? MariaDB
MariaDB資料庫管理系統是MySQL的一個分支,主要由開源社群在維護,採用GPL授權許可 MariaDB的目的是完全相容MySQL,包括API和命令列,使之能輕鬆成為MySQL的代替品。
在儲存引擎方面,使用XtraDB來代替MySQL的InnoDB。
MariaDB基於事務的Maria儲存引擎,替換了MySQL的MyISAM儲存引擎。
MariaDB直到5.5版本,均依照MySQL的版本。
MariaDB專案
MariaDB與MySQL比較
MariaDB第三方工具
- DBEdit 一個免費的MariaDB資料庫和其他資料庫管理應用程式。
- Navicat 一系列Windows、Mac OS X、Linux下專有資料庫管理應用程式。
- HeidiSQL 一個Windows上自由和開放原始碼的MySQL客戶端。它支援MariaDB的5.2.7版本和以後的版本。[5][6]
- phpMyAdmin 一個基於網路的MySQL資料庫管理應用程式
? Percona Server
Percona Server專案
Percona Server由領先的MySQL諮詢公司Percona釋出。
Percona Server是一款獨立的資料庫產品,其可以完全與MySQL相容,可以在不更改程式碼的情況了下將儲存引擎更換成XtraDB。是最接近官方MySQL Enterprise發行版的版本。
Percona提供了高效能XtraDB引擎,還提供PXC高可用解決方案,並且附帶了percona-toolkit等DBA管理工具箱。
Percona Server 只包含 MySQL 的伺服器版,並沒有提供相應對 MySQL 的 Connector 和 GUI 工具進行改進。
Percona Server 使用了一些 google-mysql-tools, Proven Scaling, Open Query 對 MySQL 進行改造。
MySQL,MariaDB,Percona Server如何選擇
綜合多年使用經驗和效能對比,首選Percona分支,其次是MariaDB,如果你不想冒一點風險,那就選擇MYSQL官方版本。
鍵值(Key-Value)儲存資料庫
- 相關產品: Redis、RocksDB
- 典型應用: 內容快取,主要用於處理大量資料的高訪問負載。
- 資料模型: 一系列鍵值對
- 優勢: 快速查詢
- 劣勢: 儲存的資料缺少結構化
? Redis
? 知識體系
Redis知識體系圖
Redis知識體系圖
Redis Cluster方案圖
官方Redis Cluster 方案(服務端路由查詢)
Redis叢集方案(單副本)
Redis叢集方案(單副本)
♨ 資料型別
Redis的五大資料型別也稱五大資料物件;Redis並沒有直接使用這些結構來實現鍵值對資料庫,而是使用這些結構構建了一個物件系統redisObject;
這個物件系統包含了五大資料物件,字串物件(string)、列表物件(list)、雜湊物件(hash)、集合(set)物件和有序集合物件(zset);
而這五大物件的底層資料編碼可以用命令OBJECT ENCODING來進行檢視。
//redisObjecttypedef struct redisObject {
// 型別屬性儲存的是物件的型別,也就是我們說的 string、list、hash、set、zset中的一種, //可以使用命令 TYPE key 來檢視。
unsigned type:4;
// 編碼,記錄了隊形所使用的編碼,即這個物件底層使用哪種資料結構實現。
unsigned encoding:4;
// 指向底層實現資料結構的指標
void *ptr;
// ...
} robj;
redis是以鍵值對儲存資料的,所以物件又分為鍵物件和值物件,即儲存一個key-value鍵值對會建立兩個物件,鍵物件和值物件。鍵物件總是一個字串物件,而值物件可以是五大物件中的任意一種。
⭕ 面試題
? 優化與叢集架構
Redis叢集方式
? 原始碼與配置引數
? 視訊資源
? 文章
後續補充…
? Paper
? 電子書籍
? 常見問題
? RocksDB
RocksDB特點:
RocksDB是嵌入式持久化儲存系統,它是一個單點高效能的儲存DB,不是分散式儲存系統。
RocksDB能支援非常高吞吐量的IO讀寫,可以作為大型分散式儲存系統後設資料的儲存媒介,比如Hadoop Ozone就將其後設資料使用RocksDB作為後設資料的結果寫出。
高效能: RocksDB使用一套日誌結構的資料庫引擎,為了更好的效能,這套引擎是用C++編寫的。 Key和value是任意大小的位元組流。
為快速儲存而優化: RocksDB為快速而又低延遲的儲存裝置(例如快閃記憶體或者高速硬碟)而特殊優化處理。 RocksDB將最大限度的發揮快閃記憶體和RAM的高度率讀寫效能。
可適配性: RocksDB適合於多種不同工作量型別。 從像MyRocks這樣的資料儲存引擎, 到應用資料快取, 甚至是一些嵌入式工作量,RocksDB都可以從容面對這些不同的資料工作量需求。
基礎和高階的資料庫操作: RocksDB提供了一些基礎的操作,例如開啟和關閉資料庫。 對於合併和壓縮過濾等高階操作,也提供了讀寫支援。
RocksDB的典型場景(低延時訪問):
- 需要儲存使用者的查閱歷史記錄和網站使用者的應用
- 需要快速訪問資料的垃圾檢測應用
- 需要實時scan資料集的圖搜尋query
- 需要實時請求Hadoop的應用
- 支援大量寫和刪除操作的訊息佇列
? 知識體系
RocksDB5大子模組,分別為:
- Basic Operation,基本操作定義
- Terminology,內部術語定義
- Tool,內部工具
- Logging/Monitoring ,日誌和監控
- System Behavior,內部系統行為
本作品採用《CC 協議》,轉載必須註明作者和本文連結