自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

數(shù)據(jù)庫的存儲引擎優(yōu)化是一個揚長避短的過程

數(shù)據(jù)庫 其他數(shù)據(jù)庫
LSM-TREE的出現(xiàn)是在內(nèi)存成本第一次大幅下降之后的,因此基于memtab可以大幅優(yōu)化高并發(fā)寫入的性能,同時SSTABLE可以更加充分的利用存儲,更加有利于數(shù)據(jù)壓縮。

?這兩天要和一個數(shù)據(jù)庫廠商交流關(guān)于存儲引擎的事情,這些天這方面考慮的多一些,今天就來聊聊數(shù)據(jù)庫存儲引擎的事情。一說到存儲引擎,可能很多朋友就會說,某某存儲引擎技術(shù)比較先進,比傳統(tǒng)數(shù)據(jù)庫的好。實際上再先進的存儲引擎也有其缺點,可能先進只是指出現(xiàn)的較晚而已,并不是后出現(xiàn)的存儲引擎一定全面優(yōu)于老的存儲引擎。數(shù)據(jù)庫的存儲引擎經(jīng)過數(shù)十年的發(fā)展,實際上到現(xiàn)在為止也并沒有出現(xiàn)特別多的流派。大體上歸納起來還是B樹(含HEAP)和基于日志結(jié)構(gòu)的存儲引擎這兩大類(最著名的是LSM-TREE)。雖然LSM-TREE的出現(xiàn)比B樹存儲引擎晚了二十多年,不過其出現(xiàn)并不是作為替代B樹引擎的,而是有著特定的目的的。

LSM-TREE的出現(xiàn)是在內(nèi)存成本第一次大幅下降之后的,因此基于memtab可以大幅優(yōu)化高并發(fā)寫入的性能,同時SSTABLE可以更加充分的利用存儲,更加有利于數(shù)據(jù)壓縮。LSM-TREE被大規(guī)模應用到關(guān)系型數(shù)據(jù)庫上則是SSD逐漸普及后才出現(xiàn)的,因為開銷巨大甚至可能導致系統(tǒng)不穩(wěn)定的后臺壓縮讓對于延時十分敏感的OLTP系統(tǒng)無法承受。而SSD可以緩解這種問題。

B樹存儲引擎一般采用IN-PLACE-REPLACE,所以其性能相對穩(wěn)定,雖然會因為PAGE的碎片而導致一些浪費,但是總體來說是較為均衡的。與LSM-TREE相比,因為B樹存儲引擎的這個特點導致并發(fā)寫入的性能是會遇到瓶頸的。幾年前我們測試過一個每隔5分鐘有數(shù)億條數(shù)據(jù)并發(fā)寫入,并需要進行實時統(tǒng)計分析的場景,在Oracle數(shù)據(jù)庫上在每秒寫入1000萬條以后明顯就很難提升了,而在LSM-TREE引擎的分布式系統(tǒng)中,很輕松就超過2000萬/秒。雖然在寫入上B樹存儲引擎的性能無法與LSM-TREE相媲美,不過B樹存儲引擎在數(shù)據(jù)讀取上有著明顯的優(yōu)勢。在MVCC的實現(xiàn)上,以及對數(shù)據(jù)的復雜查詢上面,B樹存儲引擎都比LSM-TREE有明顯的優(yōu)勢。雖然LSM-TREE存儲引擎在查找數(shù)據(jù)上也通過布魯姆過濾器以及內(nèi)存主范圍索引等方式進行優(yōu)化,但是其開銷還是會比B樹存儲引擎要大的多。目前很多基于LSM-TREE的分布式數(shù)據(jù)庫往往都是依靠并行掃描的方法,以眾敵寡,勉強和B樹結(jié)構(gòu)的集中式數(shù)據(jù)庫打個平手。

實際上兩種存儲引擎的一些優(yōu)缺點也并不容易區(qū)分清楚,如果站在某個立場上,就會有不同的分析結(jié)論。比如寫放大的問題上,LSM-TREE的支持者會說LSM-TREE結(jié)構(gòu)更加緊湊,數(shù)據(jù)沒有碎片,而B樹存儲引擎經(jīng)常會出現(xiàn)某個PAGE中只寫了很少一部分數(shù)據(jù),導致寫被放大了。實際上LSM-TREE雖然不存在這種寫放大,但是一個KEY會被多處存儲,也會造成另外一個意義上的寫放大。再加上現(xiàn)代硬件對于寫IO的能力已經(jīng)極大提高了,這個問題其實并不會對絕大多數(shù)場景造成影響。

從上面的分析來看,確實沒有完美的存儲引擎,每個引擎都有其優(yōu)點,也同時必然有其缺點。我們要做的實際上是利用現(xiàn)代硬件的特點,盡可能地彌補其缺點,發(fā)揚其優(yōu)點。隨著IO越來越好,CPU越來越便宜,LSM-TREE存儲引擎被越來越廣泛地使用也是一個很好的例子。

前些年我和INTEL合作研究傲騰內(nèi)存的使用場景的時候,曾經(jīng)考慮過是不是把沒有壓縮的sstable先存儲到傲騰內(nèi)存里,在傲騰內(nèi)存里做壓縮后,逐漸把歷史數(shù)據(jù)下沉到性能相對較差的持久存儲上。這樣可以大大降低壓縮帶來的負面影響。再用CGROUP隔離后臺壓縮進程,這樣就可以避免壓縮給數(shù)據(jù)庫帶來的抖動。

前些天我看到一篇北京大學Baoyue Yan的論文,他們提出了一種利用傲騰內(nèi)存優(yōu)化LSM-TREE存儲引擎的算法,在實踐中獲得了很好的效果,在TPCC基準測試中獲得了2倍的提升。

圖片

左邊的圖是基于傳統(tǒng)的LSM-TREE存儲引擎的數(shù)據(jù)庫,而右邊是他們優(yōu)化過的方案。實際上這張圖并不完整,還缺少了一個傳統(tǒng)內(nèi)存的區(qū)域。在傳統(tǒng)內(nèi)存區(qū)域里,他們放置了可丟失的半持久化索引數(shù)據(jù),傳統(tǒng)寫入memtab的數(shù)據(jù)被寫入非易失性內(nèi)存中的sp-m,sp-m寫滿后被鎖定為sp-im,然后在非易失性內(nèi)存中進行壓縮,寫入SSD的持久化存儲系統(tǒng)中。

因為主數(shù)據(jù)被寫入非易失性內(nèi)存,因此通過WAL來保證數(shù)據(jù)庫的一致性需求也沒那么強烈了,因此可以使用更為輕量級的Recorder Ring來替換WAL,保證事務(wù)一致性。這種利用非易失性內(nèi)存這種現(xiàn)代的硬件來優(yōu)化數(shù)據(jù)庫架構(gòu),甚至顛覆傳統(tǒng)數(shù)據(jù)庫架構(gòu)的嘗試是十分值得肯定的,也是十分有價值的。

可能有朋友要說了,非易失性內(nèi)存那么貴,不是任何用戶用得起的,所以這種數(shù)據(jù)庫是不是很難普及啊。實際上說這句話的時候想想十年前,當時大家都在說SSD那么貴,不是任何人都用得起的。而現(xiàn)在,好像不是那么回事了吧。

責任編輯:武曉燕 來源: 白鱔的洞穴
相關(guān)推薦

2010-05-06 13:04:23

全局負載均衡

2018-05-25 15:03:11

借貸寶

2010-01-14 09:46:48

第三層交換技術(shù)

2017-03-24 16:43:09

開發(fā)者故事

2023-01-31 12:08:05

2019-10-12 00:39:23

MySQL數(shù)據(jù)庫Oracle

2016-12-20 10:59:43

MySQL存儲insert

2013-06-07 15:04:24

軟件

2011-08-29 14:33:02

Oracle存儲過程

2011-08-18 18:18:05

MySQL數(shù)據(jù)庫優(yōu)化

2011-07-21 16:28:20

MySQL數(shù)據(jù)庫帶游標的存儲過程

2021-06-22 07:45:57

React18startTransiReact

2024-09-26 19:00:54

2024-08-09 08:28:14

品牌數(shù)據(jù)庫產(chǎn)品

2014-05-07 14:09:20

Fourinone

2019-07-23 15:34:29

MySQL存儲引擎

2009-03-17 15:51:41

數(shù)據(jù)庫存儲過程封裝

2022-03-21 08:49:01

存儲引擎LotusDB

2010-10-14 13:18:55

MySQL存儲過程

2011-08-29 10:55:03

SQL Server分頁存儲過程優(yōu)化效率分
點贊
收藏

51CTO技術(shù)棧公眾號