RavenDB 3.0 新特性：索引後端

RavenDB 3.0 新特性：索引後端

RavenDB 索引絕對不是簡單的對 key/value 進行儲存, 其功能要強大的多. 就像3.0版本的其他特性一樣,  是汗水與智慧的結晶。本文我主要介紹索引在後端都有哪些變動, 使它變得更快， 更穩定， 效能更好。 至於那些使用者能看得到的新特性, 會在下一篇文章中提到。

記憶體中的索引. 曆史一次又一次地證明, 只有從硬碟著手, 我們才能跟系統最佳化工具說再見。 為了提高建立新索引的資料讀寫速度, 2.5版本中開始引入只在記憶體中建立新索引的新概念. 而在3.0中, 這一功能得到了進一步完善. 索引資料由原來的頻繁地對硬碟讀寫, 改為存進記憶體緩衝區. 只有在一些特殊情況下(如：記憶體不足等), 才會將索引資料寫入硬碟.

通過這種方式, 可以大量減少讀寫索引資料的時間, 以及維護和最佳化硬碟的時間. 擺脫這些束縛, 即使在高負荷的情況下, 也能保持極好的效能. 而在日常使用中, 負荷的偶爾波動也不會導致硬碟出現問題.

非同步刪除索引. RavenDB 中的索引包含兩部分, 實際資料跟中繼資料. 一般情況下, 中繼資料的要比實際資料少. 但是對於 map/reduce 索引來說, 情況剛好相反, 因為它的中繼資料套件含了許多中間步驟相關的資料. 如果你在大規模資料庫中使用LoadDocument, 我們還需要維護文檔的引用,這需要大量的儲存空間. 結果導致在 RavenDB 2.5 中刪除索引的過程變得極其緩慢.

到了 RavenDB 3.0, 隨著非同步刪除索引的出現, 你可迅速刪除索引. 表面上看, 索引被刪除了, 其實刪掉的是索引名稱, 其他清理工作則留給後台非同步處理. 別擔心如果你需要中途重啟資料庫, 那麼在資料庫啟動後, 那些未完成的清理工作仍然會在後台繼續. 這種非同步刪除方式使維護和刪除包含大量資料的索引變得相當簡便.

非同步刪除索引. RavenDB 中的索引包含兩部分, 實際資料跟中繼資料. 一般情況下, 中繼資料的要比實際資料少. 但是對於 map/reduce 索引來說, 情況剛好相反, 因為它的中繼資料套件含了許多中間步驟相關的資料. 如果你在大規模資料庫中使用LoadDocument, 我們還需要維護文檔的引用,這需要大量的儲存空間. 結果導致在 RavenDB 2.5 中刪除索引的過程變得極其緩慢.

到了 RavenDB 3.0, 隨著非同步刪除索引的出現, 你可迅速刪除索引. 表面上看, 索引被刪除了, 其實刪掉的是索引名稱, 其他清理工作則留給後台非同步處理. 別擔心如果你需要中途重啟資料庫, 那麼在資料庫啟動後, 那些未完成的清理工作仍然會在後台繼續. 這種非同步刪除方式使維護和刪除包含大量資料的索引變得相當簡便.

索引跟任務交替執行. 任務這個詞對於 RavenDB來說, 基本上指清理索引資料. 如: 清理那些已經被刪除的索引記錄, 或者是對已經發生改變的引用文檔重新索引. 在 2.5 版本中, 這些任務會排成長隊, 在隊列表中等待執行, 導致許多索引任務沒有及時執行. 例如:每天都有一大堆刪除索引的任務在隊列中排隊等待, 每執行一個這樣的任務又很耗時間. 在 3.0 中, 我們做了些調整,  索引跟任務的執行交替進行, 不管隊列排的多滿, 都不會對索引帶來太大影響.

大文檔索引. RavenDB 對文檔大小沒有限制, 這對使用者來說是好事, 但是如果 RavenDB 要對這些文檔索引, 那就亞曆山大了.  假如我們要對一大堆文檔進行索引. 那麼我們會加大每一批索引的數量. 隨著系統跟文檔變得越來越大, 問題就開始出現了. 許多文檔在索引更新後會變得變原來的檔案要大的多. 比方說, 每一批處理 128K 個文檔, 每個文檔 250Kb, 那就意味著每一批要索引 31GB 的文檔.

這麼大的資料要從磁碟讀出來, 需要一定的時間, 這還不包括對記憶體的讀寫時間.而使用者通常都會對大資料件壓縮處理. 這會導致問題變得更加嚴重. 因為 RavenDB只會讀取文檔在磁碟上的檔案大小, 也就是壓縮以後的檔案大小. 結果可想而知. 在 3.0 中, 對這個問題采我們採取了一些預防措施. 首先是計算在內容中的文檔大小，同時也能更好的限制每次大量操作記憶體的數量。

被I/O限制的批量索引. RavenDB的一個核心方案是在雲端服務器上運行. 但實際上, 我們的客戶所用的伺服器各式各樣. 從i2.8xlarge EC2 (32 核, 244GB 記憶體, 8 x 800 GB SSD 硬碟) 到 A0 Azure (共用的 CPU, 768 MB 記憶體, 硬碟無力吐槽, 淚奔) 都有. 由於我們實際只使用了伺服器上1/4左右的可用資源. 客戶老是抱怨為什麼沒有把剩下的資源也用上.  問題是他們用來計算可用資源的演算法跟 RavenDB 的不一樣, 效能方面沒什麼可抱怨的, 就把火發在 RavenDB 沒有“有效”利用資源上.

看起來很搞笑, 其實不然. 低端的雲端服務器速度慢, 效能差. 尤其是I/O 的傳輸速率相當慢. 如果你在這樣一台伺服器上給一個已經在使用中的資料庫建立索引, 你會發現大部分的時間都是用來等I/O操作. 久而久之, 這個問題就會越來越嚴重. RavenDB一開始會從硬碟讀取少量資料進行批量索引(比如花個半秒鐘從硬碟上讀出資料). 然後下一批, 再下一批, 就這樣一批接一批的處理. 當 RavenDB 發現要處理的資料太多了, 它就會增加每一批處理的數量.  結果導致等待資料從硬碟讀出來的時間變得越來越久. 在網管看來, RavenDB 基本上就是卡死在那, 什麼都沒做.

在 RavenDB 3.0 中, 我們不再糾結I/O的速度問題. 先從硬碟讀取一部分資料, 如果在一段合理的時間段內依然無法讀取足夠的資料, 那我們會先將已讀到的資料索引, 與此同時把讀取資料的任務放到後台繼續執行.  等到索引執行完後, 又可以對後台讀取出來的那部分資料進行索引. 這樣做可以很大程度上提高效能. (客戶能看到索引跟讀寫操作在同事進行, 不會埋怨我們的軟體無所事事)

總結 – 基本上這幾個新特性都是在後台運行, 使用者在前台是看不到變化的. 但是他們能協調合作, 給大家帶來更好的使用者體驗.

英文原文：What is New in RavenDB 3.0: Indexing Backend

本文永久更新連結地址：