基于Redis和MongoDB的IFC模型存儲展示方式

張若冰

摘 要：做為世界上每年新建建筑量最大的國家，中國的工程建設行業(yè)正在發(fā)生著翻天覆地的變化，一場由 BIM 引領的技術大變革已然開始。住建部、交通部、中國鐵路總公司、水利水電部等多部委都將 BIM 技術列為“十三五”首選推廣技術，BIM 技術也必然成為“智慧城市”建設的基礎技術。2017 年中國大地掀起了 BIM 應用的浪潮，各個地方政府不斷出臺BIM 應用的強制性或指導性文件及規(guī)范，推動 BIM 技術在項目中的普遍應用。隨著國內(nèi)BIM技術的迅猛發(fā)展，高速增長的BIM數(shù)據(jù)對存儲系統(tǒng)的高可用性、負載均衡、橫向擴容等功能以及如何快速展示存儲的BIM數(shù)據(jù)提出了更高的要求。本文就BIM行業(yè)中IFC數(shù)據(jù)的存儲展示，設計了一種以非關系型文檔數(shù)據(jù)庫MongoDB和內(nèi)存數(shù)據(jù)庫Redis組合的方式存儲展示IFC數(shù)據(jù)。

關鍵詞：BIM；IFC；模型；

主要內(nèi)容

本發(fā)明提供了一種以非關系型文檔數(shù)據(jù)庫MongoDB和內(nèi)存數(shù)據(jù)庫Redis組合的方式存儲展示IFC數(shù)據(jù)，解決海量建筑信息模型IFC數(shù)據(jù)的存儲及Web展示問題。

具體發(fā)明內(nèi)容包括：

步驟一：解析IFC模型數(shù)據(jù)，并進行模型輕量化處理；

步驟二：將解析后IFC模型數(shù)據(jù)存儲到非關系型文檔數(shù)據(jù)庫MongoDB；

步驟三：從文檔數(shù)據(jù)庫MongoDB中讀取當前使用頻繁的IFC模型數(shù)據(jù)存儲到內(nèi)存數(shù)據(jù)庫Redis存儲；

步驟四：Web端通過Webworker線程根據(jù)IFC模型唯一ID從內(nèi)存數(shù)據(jù)庫Redis中快速讀取模型數(shù)據(jù)，Web端主線程通過繪圖技術標準WebGL渲染展模型數(shù)據(jù)；

具體實施方式

本發(fā)明由Web端、服務端、Redis內(nèi)存數(shù)據(jù)庫、MongoDB非關系型文檔數(shù)據(jù)庫幾大部分組成。

服務端負責解析建筑BIM模型的IFC數(shù)據(jù)，進行輕量化處理，然后存儲到Redis內(nèi)存數(shù)據(jù)庫和MongoDB文檔數(shù)據(jù)庫中，同時負責響應Web端的請求。

Web端從服務端讀取輕量化后的建筑BIM模型IFC數(shù)據(jù)并渲染展示。

具體實施方式如下：

步驟一：

服務端解析IFC模型文件，將模型數(shù)據(jù)分為屬性數(shù)據(jù)、材質(zhì)數(shù)據(jù)、幾何數(shù)據(jù)三種，這三種數(shù)據(jù)獨立存儲，通過模型構件唯一ID關聯(lián)。

IFC標準整體的信息描述分為四個層次， 從下往上分別為資源層、核心層、共享層、領域?qū)樱?每個層次又包含若干模塊，相關工程信息集中在一個模塊里描述。資源層里多是基礎信息定義， 如材料、幾何、拓撲等；核心層定義信息模型的整體框架， 如工程對象之間的關系、工程對象的位和幾何形狀等；該層主要描述建筑工程信息的整體框架，其將資源層的信息用一個整體框架組織起來，使它們相互聯(lián)系和連接，組成一個整體，真實反映現(xiàn)實世界的結(jié)構。共享層定義跨專業(yè)交換的信息， 例如墻、梁、住、門、窗等；領域?qū)佣x各自領域的信息， 例如暖通領域的鍋爐、風扇、節(jié)氣閥等。

針對模型幾何數(shù)據(jù)，通過參數(shù)化幾何圖形描述和圖元合并兩種方式進行輕量化處理：

1）參數(shù)化幾何圖形描述輕量化處理：

用多個參數(shù)來描述一個幾何體，我們稱之為參數(shù)化幾何描述。

例如：一個立方體8個頂點，可以使用3個參數(shù)描述：

參數(shù)1、2：立方體底部矩形斜對角頂點坐標

參數(shù)3：立方體高度

這樣，就能用較少的數(shù)據(jù)來描述保存圖元，非常精簡，參數(shù)化幾何描述可以將單個圖元做到最極致的輕量化，有效減少單個圖元的體量。

2）圖元合并輕量化處理：

在一個BIM模型中，會有很多重復的圖元，可以采用相似性算法判斷圖元是否為同一個，主要判斷兩個圖元是否經(jīng)過剛體變換，包含平移變換、旋轉(zhuǎn)變換和鏡像變換三種情況。

重復的圖元只是位置不一樣，這個時候我們可以做圖元合并：只保留一個圖元的幾何數(shù)據(jù)，其它圖元用該圖元的位置坐標和圖元幾何數(shù)據(jù)的唯一ID表示。

通過這種方式我們可以有效減少圖元數(shù)量，達到輕量化的目的。

步驟二：

IFC格式BIM模型是基于STEP標準，是采用EXPRESS數(shù)據(jù)建模語言描述的實體關系模型， 作為建筑行業(yè)的通用數(shù)據(jù)標準，IFC提供了跨多個領域的實體模型。IFC的可擴展性使得可通過預定義或擴展屬性集描述增加模型的實體類型和屬性信息。

IFC龐大、復雜的定義使得IFC數(shù)據(jù)的處理成為影響其實際應用的重要技術難題?，F(xiàn)有IFC數(shù)據(jù)存儲方式可以分為3類：關系數(shù)據(jù)庫、對象數(shù)據(jù)庫、非關系型（NoSQL）數(shù)據(jù)庫。在數(shù)據(jù)量達到一定量級時，非關系數(shù)據(jù)庫相較傳統(tǒng)數(shù)據(jù)庫在存取效率上將體現(xiàn)出較大的優(yōu)勢。

文檔數(shù)據(jù)庫MongoDB是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫的。它支持的數(shù)據(jù)結(jié)構非常松散，是類似json的bson格式，因此可以存儲比較復雜的數(shù)據(jù)類型。IFC的EXPRESS格式數(shù)據(jù)屬于聚合類型數(shù)據(jù)，比較適合用JSON來表示，可以用MongoDB來存儲。Mongo非常適合由數(shù)十或數(shù)百臺服務器組成的數(shù)據(jù)庫。Mongo的路線圖中已經(jīng)包含對MapReduce引擎的內(nèi)置支持，支持海量數(shù)據(jù)存儲。

對于單個的模型IFC文件，服務端解析完IFC數(shù)據(jù)后，存儲在單獨的MongoDB集合中，IFC文件中的屬性數(shù)據(jù)、幾何數(shù)據(jù)、材質(zhì)數(shù)據(jù)，則存儲于集合的文檔中。

步驟三：

內(nèi)存數(shù)據(jù)庫Redis是一個開源的、分布式、可基于內(nèi)存亦可持久化的鍵-值型存儲系統(tǒng)。Redis最大特點在于使用內(nèi)存進行數(shù)據(jù)的存取，極大提升了數(shù)據(jù)的讀寫速度，同時分布式的設計使得Redis能夠利用計算機集群的性能，解決單機內(nèi)存容量可能不足的問題。本專利利用Redis高速讀寫、高并發(fā)能力的特點，在服務端啟動時，將從MongoDB中讀取目前頻繁使用的IFC模型數(shù)據(jù)存儲于Redis集群中，在內(nèi)存中構建鍵-值格式IFC模型高速緩存，供WEB端調(diào)用。

步驟四：

HTML5中提出了多線程WebWorker的概念，使得瀏覽器可以使用利用多線程去完成一些復雜的工作。本專利中，WebWorker負責一般的交互請求以及數(shù)據(jù)獲取，瀏覽器主線程中只負責BIM模型的渲染工作。

目前BIM模型Web端渲染模型有兩種方式：發(fā)送多個請求獲取數(shù)據(jù)，拿到所有數(shù)據(jù)后統(tǒng)一進行模型的渲染；或者每發(fā)送一個數(shù)據(jù)請求都調(diào)用渲染接口進行部分數(shù)據(jù)渲染。

常規(guī)選擇的是方法一，這種方法在數(shù)據(jù)下載時，頁面呈現(xiàn)空白狀態(tài)，用戶可能會感覺頁面卡死或者網(wǎng)絡報錯，當數(shù)據(jù)量比較大時，數(shù)據(jù)全部下載占用的時間比較長，用戶體驗很不好。

方法二是在下載數(shù)據(jù)的同時也進行模型渲染，配合WebWorker多線程技術，可以使兩個步驟同步執(zhí)行，用戶可以馬上看見模型一塊一塊出現(xiàn)，而不用等待很長時間，這樣速度快，用戶體驗也比較好。

結(jié)語：本方法能將IFC格式的BIM模型數(shù)據(jù)存儲于MongoDB和Redis中，實現(xiàn)BIM海量模型數(shù)據(jù)的存儲以及高效讀取展示。BIM技術的諸多特性，使其應用能夠滿足施工企業(yè)轉(zhuǎn)型升級的要求。從中可以普及可視化、參數(shù)化、三維模型設計，以提高設計水平，降低工程投資，實現(xiàn)從設計、采購、建造、投產(chǎn)到運行的全過程集成運用。