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不会在特定的偏移数字之后返回正确的结果，但是请注意，如果偏移超过了元素的总数，空结果是正确的结果。