基于分布式樹狀結構的資源管理方法

楊超

摘 要：文章描述了使用標識服務管理物聯網中的實體對象資源以及其相關的數據資源，并為實體對象分配含有對象間關系的對象標識。文章主要設計尋址機制，通過對對象標識的尋址定位來獲取相關數據資源，滿足用戶對實體對象相關信息的檢索需求。最后通過實驗驗證了資源尋址機制在物聯網數據資源大規模擴的情況下同樣具有良好的可展性。

關鍵詞：分布式樹狀結構；資源管理；尋址定位

一般來說，我們使用標識服務管理物聯網中的實體對象資源，建立能表述物理實體間關系的映射模型。這樣一來，物聯網實體對象的相關資源信息就可以共享到網絡中，由于已經為每個實體對象分配了標識，所以可以借助相關方面的一些標識通過相應的尋址相關方面的一些機制實現用戶對于實體相關方面的一些對象相關資源數據的相關方面的一些檢索需求。

目前應用最為廣泛的尋址服務是互聯網的DNS域名系統，它為人們提供了易于理解的域名標識到主機通信使用的IP標識之間的映射查詢。在此基礎上美國麻省理工學院Auto-ID Labs提出了針對物聯網的標識解析服務——對象名解析服務（Object Name Service，ONS）。該解析服務為公眾提供了通過產品電子代碼（ Electronic Product Code，EPC）編碼到EPC信息服務器的查詢服務。與上述兩種使用樹狀結構維護映射記錄的方式不同，Benjamin Fabian等提出對象信息分布式體系結構，同樣可以實現標識到信息服務器的一對一解析查詢。

區別于上述解析服務，另一類尋址機制——發現服務針對的是在請求者掌握先驗知識不足的情況下，檢索多個信息服務器來獲取全部相關信息的過程。前人在EPCglobal網絡的基礎上提出了類似于ONS的發現服務結構體系，該方法將一個標識的全部映射記錄保存在單一的發現服務器中，查詢時根據EPC表示定位到發現服務器獲取全部映射記錄。IBM開發的Theseos系統為了打破上述集中保存的模式提出了將信息服務器和名字服務器合二為一并使用無結構化P2P網絡的形式組織。

上述方案都在標識服務的尋址機制上作出了巨大貢獻，然而他們忽略了相關方面的一些實體對象間的關聯相關方面的一些關系，查詢對象的數據信息也可以用它的相關對象的某些屬性數據來表示。因此，結合上文提到的實體對象命名方法以及對象映射模型研究具體的尋址方法，實現實體對象相關信息檢索十分有必要。然而基于上文的實體對象管理模型實現對象相關信息檢索還存在這樣一個問題，在存在地理鏈關系的兩個實體對象之間，雖然動態感知數據可以共享，但是由于實體對象位置的轉變，父對象只有某段時間內的感知數據可以用來描述子對象，在對象相關資源查詢時應如何準確地獲取相關的感知數據。

1 基于實體對象映射模型的相關信息檢索方法

在本文設計的尋址機制中，用戶使用對象標識（IDo）向檢索服務器發起實體對象相關信息檢索的請求。針對檢索服務器來說收到相應的請求之后，根據相應對象的標識信息直接執行給實體對象映射模型中的具體信息檢索的方法。整合查詢到的數據信息，一并返回給用戶。該檢索服務整體過程如圖1所示。

根據之前所述對象標識含有與該產品相關的全部對象，因此在進行檢索的過程中，需要有針對性地遍歷這些對象信息，獲取所需要的及其查詢的對象相關的全部的信息，因此存在不同的父對象的感知數據可以有效地描述子對象相關方面的特征的一些情況，而且子對象知識存在父對象某一段時間的范疇內，返回的全部的時間段父對象的感知數據是不夠合理的。因此需要有針對性地對子對象中的父對象具體的存在時間，也就是子對象在這個地理關系鏈中具體存在的時間進行控制。

為了能夠有效地解決這個問題，根據本文中提出的一些方案，實體對象的操作日志信息來直接區分實體對象在這個地理關系鏈中所存在的一定的時間的范圍。因此在進行遍歷父節點相關的屬性之前需要查詢相應的實體對象的日志屬性信息，獲取相應的日志所覆蓋的時間的范圍。本文在提出的一種基礎標識的服務的實體對象中相應的資源檢索中的業務流程如下。

（l）用戶通過掃描二維碼等相關技術手段來獲取物理實體上的對象標識信息（ID0），然后使用對象標識直接向國家的檢索平臺發送相關的查詢請求服務。

（2）相應的服務器在收到這個對象標識之后首先需要解析到具體的對象標識信息，定位到具體的資源對象中所需要查詢的節點信息ONode，在相應的對象節點中可以有效地獲取這個資源對象中的一些屬性的相關信息并且將這個檢索結果直接存儲到結果集中R；

（3）在獲取相關的產品對象所有的屬性信息之后，首先需要訪問對象中的一些日志屬性信息OI.logs，獲取這個屬性所對應的一些具體的日志取數的接口，如果發現取數的地址信息是空，那么就無法有效地確認實體對象在相應的對象中的存在的具體時間，那么就需要直接終止這個查詢，然后將R直接返回給用戶；如果取數的地址不是空集，那么發送相應的取數請求獲取全部的日志方面的數據信息，根據具體的日志數據信息來獲取這個對象在相關的對象中存在的具體的時間段的基礎信息。

（4）在相應的查詢對象存在一定的時間的情況下，根據具體的對象的標識“”循環的查詢上一個級別中相對的一些對象中的子對象的記錄信息（ Record），根據相應的ExtendProperty字段中的具體內容，來有效的獲取子對象所集成的一些屬性記錄信息，并且將這些信息（Record）直接加入到相關的屬性列表（Listp）信息中，直到最終遍歷完成全部的相應的對象，也就是上一個級別的實體對象標識變為具體的物聯網中的根對象的時候就終止。

（5）針對Listp其中的信息進行遍歷獲取全部的屬性記錄（Recordp），這其中的屬性Type代表的是一種靜態（S-property）方面的屬性信息，那么信息信息會直接記錄到Name中作為具體的key值，Info信息會作為value計入R中；如果屬性中的Type類型是一種動態的屬性信息D-property，那么就采用一種對象存在的時間段作為具體的條件，向這個記錄中Info對應的數據取數接口發送一些基本的請求。然后以最終的一些返回結果作為具體的value來記錄Name中保存的key到具體的R中。

（6）此時Rob，不僅包含查詢相關方面的一些對象的信息<>，還包括相關對象中可以表達該相關方面的一些對象特征的相關方面的一些信息。最后將相關方面的一些結果集R返回給用戶。

2 實驗及結果分析

為了檢測本文設計的檢索方案的有效性，設計分別設置兩個實驗場景對方的檢索速度以及動態可擴展性進行評測。

2.1實驗環境

在進行實驗的過程中，針對各個實體對象中的節點信息及其標識服務中的檢索服務都是采用的Java來進行實現，實現的數據維護采用的是廠商elasticsearch 2.1.1提供的一種RESTful風格的感知數據及其日志方面的數據來檢索研究。為了有效地監測系統，在進行系統處理的過程中，采用下面的測試場景，這個場景中包括兩個不同的對象節點信息，分貝維護不同的內部的對象及其屬性的一些關系方面的映射的記錄信息，然后有針對性地對多個不同的服務器作為對象的節點來感知數據以及日志方面的數據，一個檢索方面的服務器來不斷地接受用戶的查詢請求及其檢索方面的數據。在查詢的過程中對象至少包括3個關聯的對象信息。具體參數如表1所示。

2.2實驗結果

為了監測在上述環境中本檢索方案的速度，設計使用l，2，4，8個線程在模擬環境中有100萬條傳感器數據的情況下向檢索服務發起不同次數的查詢操作，觀察查詢時延的變化，如圖3所示。

通過圖3可以看出，整個業務系統的平均檢索速度是非常穩定的，多線程可以明顯降低在查詢的過程中的延時性。圖中在線程4和線程8查詢的過程中，延時比較相近，這是因為在模擬的環境中在啟動4個同時進行查詢的CPU的利用率已經達到了l00%。同時，通過計算可以看出在上述的環境中系統的平均執行一次檢索所需要的時間為0.39 ms。

如圖4所示，隨著不同的傳感器的數量在不斷地得到增加，數據的服務器數量也是在不斷地增加，網絡中的數據的規模也是在不斷地得到擴大，在啟動4個線程的過程中發起1萬次的查詢請求的過程中耗時的情況變化。

可以看出，隨著數量的不斷擴展，從100萬條擴展到2000萬條的過程中，啟動的4個線程在并發的過程中查詢是回見總體是保持在39-40 s，在執行一次檢索需要的時間是0.39ms。這個也再次驗證了由于增加數據服務取得提供者的數量導致數據的規模在不斷擴大的過程中并沒有采用查詢延時指數級別的增加，同時也驗證了采用分布式的樹狀結構管理物聯網中的對象屬性關系的過程中在物聯網的環境中具有很好的動態方面的擴展性。

3結語

本文針對現有標識服務的尋址機制無法參照實體對象間關系獲取對象相關資源數據的問題，結合本文第三章提出的標識命名方式以及資源映射模型，提出了相關資源檢索方法，實現了實體對象相關信息檢索。通過實驗測試了檢索服務的效率，驗證了本系統具有良好的可擴展性。