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

張若冰

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

關鍵詞：BIM；IFC；模型；

主要內容

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

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

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

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

步驟三：從文檔數據庫MongoDB中讀取當前使用頻繁的IFC模型數據存儲到內存數據庫Redis存儲；

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

具體實施方式

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

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

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

具體實施方式如下：

步驟一：

服務端解析IFC模型文件，將模型數據分為屬性數據、材質數據、幾何數據三種，這三種數據獨立存儲，通過模型構件唯一ID關聯。

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

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

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

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

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

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

參數3：立方體高度

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

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

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

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

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

步驟二：

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

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

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

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

步驟三：

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

步驟四：

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

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

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

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

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