FIWARE - Orion Context Broker偏移量參數行爲

Question

我正面臨以下有關FIWARE Orion Context Broker的問題，我希望有人對此有所瞭解。

我保存記錄FIWARE獵戶座CB，1.2.0版本，在泊塢窗實例，並在一個類型的運行，我收到張貼GET呼叫http://mywebsite.eu:1016/v2/types/MyTYPE

{ 
    "attrs": { 
     "cid": { 
      "types": [ 
       "String" 
      ] 
     }, 
     "datetime": { 
      "types": [ 
       "String" 
      ] 
     }, 
     "humidity": { 
      "types": [ 
       "Float" 
      ] 
     }, 
     "luminosity": { 
      "types": [ 
       "Integer" 
      ] 
     }, 
     "temperature": { 
      "types": [ 
       "Float" 
      ] 
     } 
    }, 
    "count": 55811 
} 

正如你可以看到後以下響應「數」是55811.但是，當我再派GET調用http://mywebsite.eu:1026/v2/entities?type=MyTYPE&offset=54908&limit=1，我收到以下內容：

[ 
    { 
     "id": ".*", 
     "type": "MyTYPE" 
    } 
] 

從這個數字偏移（54908）和最多的反應是一樣的。我已經檢查了服務器中的空間，並且有足夠的空間，所以它不是磁盤空間的問題。我已經從我的Raspberries中檢查數據是否與Orion CB一樣。所以，我的問題是，如果Orion可以存儲每種類型的記錄的上限，並且達到此限制，我應該更改類型。也許有一些我錯過了，任何建議，你可以給我會幫助我很多。

Answer 1

已經觀察到，大的偏移值，您可以得到以下效果：

• 你得到的迴應是一個問題後提到，如：

  [ 
      { 
       "id": ".*", 
       "type": "ASN" 
      } 
  ] 
  

• Orion日誌中會出現如下錯誤消息：

  Raising alarm DatabaseError: nextSafe(): { $err: "Executor error: OperationFailed Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.", code: 17144 } 
  

解決方案是在用於排序的DB字段中創建一個索引。在默認的排序的情況下（基於創建日期）的索引可以在蒙戈外殼創建如下（假設orion是您正在使用的數據庫的名稱）：

$ mongo 
> use orion 
> db.entities.createIndex({creDate: 1}) 

事實上，它使用創建描述爲in this section in the documentation的索引是一個好主意。

編輯：響應不是正確的：獵戶座應該使用500內部服務器錯誤和有關問題的描述性消息進行響應。此修補程序已準備好在主分支中着陸，並將包含在Orion 1.7.0中（將於2017年初發布）。

Answer 2

offset參數表示在返回結果之前必須跳過多少個元素。因此，offset = 0（如果偏移參數被忽略，則爲defaulf值）意味着在第一個元素中開始，offset = 1意味着在第二個元素中開始，如此。

讓我們考慮一下ASN類型，它有54879個實體（如GET /v2/types/ASN所示）。採用偏移量= 0，我們得到的第一個實體（這恰好是一個id爲1470515373636_1）：

GET /v2/entities?type=ASN&limit=1 

[ 
    { 
    "id": "1470515373636_1" 
    ... 
    } 
] 

現在，讓我們使用偏移54878（等於總數ASN實體減一）。也就是說，跳過第54878個實體只有最後一個保留（這ID恰好是1480344938807_1）：

GET /v2/entities?type=ASN&offset=54878&limit=1 

[ 
    { 
    "id": "1480344938807_1" 
    ... 
    } 
] 

需要注意的是，如果我們使用偏移等於實體的總數（或任何更大的數值），即54879，這意味着所有的實體都被跳過了。換句話說，我們正在超越極限。因而是正常的，在這種情況下，獵戶座返回實體的空列表：

GET /v2/entities?type=ASN&offset=54879&limit=1 

[] 

另一個「一致性」檢查：如果你顛倒順序（默認情況下，實體通過增加創建日期，即從舊到有序較新，但可以使用參數orderBy更改），您可以檢查前一個元素現在是最後一個，反之亦然。特別是，orderBy=!dateCreated通過減少創建日期（即從較新到較舊）來訂單結果。

因此，目前正在尋找第一個元素返回前最後一個（即1480344938807_1）

GET /v2/entities?type=ASN&limit=1&orderBy=!dateCreated 

[ 
    { 
    "id": "1480344938807_1" 
    ... 
    } 
] 

，尋找最後一個元素返回前最後一個（即1470515373636_1）

GET /v2/entities?type=ASN&offset=54878&limit=1&orderBy=!dateCreated 

[ 
    { 
    "id": "1470515373636_1" 
    ... 
    } 
] 

讓我們做另一個測試。爲了好玩，我們添加一個新的ASN實體：

POST /v2/entities?options=keyValues 

{ 
    "id": "TestingEntity", 
    "type": "ASN", 
    "A": 42 
} 

所以，現在ASN類型中的實體總數是54880。新實體是要創建的最後一個實體，因此它將以默認排序（即增加創建日期）結束。你可以用下面的查詢檢查：

GET /v2/entities?type=ASN&offset=54879&limit=1 

[ 
    { 
    "id": "TestingEntity" 
    ... 
    } 
] 

請注意查詢添加新的實體（見上文）之前返回[]。

總之，Orion上下文代理行爲似乎與偏移參數相同。你說問題是Orion不會在特定的偏移數字之後返回正確的結果，但是請注意，如果偏移超過了元素的總數，空結果是正確的結果。