為了幫助數據庫開發(fā)者、用戶和對數據庫有興趣的同學，更好地了解和運用數據庫，柏睿數據數據庫團隊特別策劃出品《深入淺出話DB》系列文章，以全內存分布式數據庫RapidsDB為實例開啟連載，從數據庫高性能入手，到柏睿數據經典實戰(zhàn)案例解讀，帶你走進全內存分布式數據庫的世界。第四回，并發(fā)查詢，Here we go！

　　相信各位朋友都有這樣的認知，傳統(tǒng)分析型分布式數據庫對海量數據處理能力很強，就是任務并發(fā)表現上就略顯無力。那么作為新型的分析型分布式數據庫，RapidsDB又有什么手段處理并發(fā)查詢？RapidsDB在底層存儲、工作負載、分布式服務3個層面并發(fā)查詢上優(yōu)化：

　　首先的也是最核心的存儲引擎層面上：RapidsDB的存儲引擎使用使用無鎖跳表，使得RapidsDB以非常高吞吐量進行高度并發(fā)的讀寫。

　　那么無鎖跳表索引又有什么不同，它是怎么體現優(yōu)勢？

　　無鎖跳表索引：又稱跳表索引，它是RapidsDB中的默認索引類，對比其他大多數數據庫（比如MYSQL）使用的B-Tree索引。跳表索引被RapidsDB優(yōu)化為在內存中運行，它不僅可以實現無鎖并提供極快的插入性能。而且它提供Btree類似的O(log(n))查找性能，非常適合順序遍歷。

　　但跳表索引也有與B-trees不同的地方，RapidsDB中的跳表索引是單向的（也就是單鏈表）。混合跳表索引中的每一列都可以指定為升序（ASC）或降序（DESC），默認值為升序。選擇哪一個不會影響查找性能，但會影響數據掃描性能，具體取決于索引的數據掃描的方向。反向掃描跳表索引的成本大約是正向掃描的兩倍。因此，如果用戶有一個升序索引，并且運行一個按降序遍歷該索引的查詢（例如按ORDER BY DESC的順序），那么該查詢將需要比索引DESC更高昂的迭代。

　　比如對于數據增刪改等寫入操作。傳統(tǒng)的關系型數據庫管理系統(tǒng)使用磁盤作為數據的主要存儲，使用內存作為緩存。管理這個緩存層時會增加開銷并引發(fā)資源爭用，從而降低吞吐量和并發(fā)性。這些限制導致隨機讀寫I/O，這會給旋轉和固態(tài)磁盤帶來了巨大的壓力。RapidsDB主要將數據存儲在內存中，并以壓縮格式備份到磁盤。因此，RapidsDB只使用順序I/O，并且事務日志的大小會小很多。這種I/O模式針對旋轉磁盤和固態(tài)磁盤進行了優(yōu)化。此外，RapidsDB中的讀取可以使用內存優(yōu)化的無鎖跳表和哈希表，這些都不會被在緩存池中管理。

　　在內存中運行的跳表在這種樣的設計下，可以自由地直接使用指向行的指針，而無需像傳統(tǒng)數據庫那樣，檢索行需要通過其他方式而不是指向內存的指針來尋址，因為傳統(tǒng)數據庫的數據主要存儲位置在磁盤上。這種間接訪問通常采用內存駐留頁面緩存（通常稱為緩沖池）的形式，查詢該緩存是為了找到特定行的內存地址，或者在需要使用時先將數據從磁盤讀入內存。

　　這種間接檢索方式對系統(tǒng)開支很昂貴，并且通常在頁面級別完成（例如，在 SQL Server中一次 8K）。而RapidsDB沒有這種計算開銷。取消引用指針的跳表索引比在緩沖池中查找頁面要節(jié)省資源得多。

　　無鎖（或者叫非阻塞）算法是RapidsDB索引的另外一個特點：數據庫線程始終可以運行，完全適應操作系統(tǒng)對線程的調度執(zhí)行。這也是RapidsDB支持在多核CPU硬件上運行的高并發(fā)工作負載的原因。它還擺脫了Btrees需要使用復雜的鎖定方案來實現線程安全的困局。對比較新的無鎖索引數據結構，例如BWtree，雖然可以避免這個問題。但同樣，BWTree數據結構的復雜性遠遠超過了跳表甚至傳統(tǒng)的Btree本身。因此跳表的簡單性使其非常適合無鎖實現。

　　使用無鎖數據結構來優(yōu)化對表的其他數據庫中的B-trees有相似的功能和性能特征。跳表是為有序數據優(yōu)化的數據結構，它將行存儲在越來越小的有序列表集合中。查詢可以通過使用不同大小的列表進行二進制搜索來快速查找數據，并且可以通過遍歷最大的列表來快速掃描數據范圍。對于多列索引，查詢篩選器必須匹配索引列列表的前綴，以便能利用該索引。

　　其次是工作負載層面上：遇到需要跨分片數據移動的查詢，即涉及表數據進行廣播和重新分區(qū)的查詢，通常比其他查詢請求更多的連接和線程。這類查詢的并發(fā)性由工作負載管理自動管理。在大多數情況下，工作負載管理的默認設置將適當地安排用戶的工作負載，以利用集群資源，而不會耗盡連接和線程限制。

　　最后是分布式服務層面上：分布式查詢優(yōu)化器通過平均分配處理大量工作，以最大限度地提高CPU使用效率。查詢計劃被編譯為機器代碼并且被緩存，來加速后續(xù)的查詢，這些經過編譯的查詢計劃的一個關鍵特征是它們并沒有預先設定的參數值。這個機制允許RapidsDB能根據不同的請求來替換這些值，這使得相同查詢結構的后續(xù)查詢能夠快速的執(zhí)行，大大提高并發(fā)執(zhí)行的效率，尤其是同類查詢的效率。

免責聲明：以上內容為本網站轉自其它媒體，相關信息僅為傳遞更多信息之目的，不代表本網觀點，亦不代表本網站贊同其觀點或證實其內容的真實性。如稿件版權單位或個人不想在本網發(fā)布，可與本網聯系，本網視情況可立即將其撤除。