时间和地理位置数据的数据库设计

时间:2015-12-25 23:15:46

标签: orientdb graph-databases

我已成功实施了文档中显示的Time Series Use case。由最小时间单位指向的数据(事件类)使用lucene空间索引编制索引。

我有两种类型的事件:私人或公共事件。

我应该如何为我的用例设计数据库和群集?

使用Edge或链接列表制作从Min到Event的链接会更好吗?

我担心我的lucene空间指数将来会变得太大。

通过阅读文档,看起来地理定位数据的clusters似乎是一个很好的策略。

可以仅在子查询上使用索引:

select 
from 
  (select 
     expand(month["12"].day["25"].hour["17"].min["07"].events)
   from 
     Year 
   where 
     year = 2015)
where
   [lat,lng,$spatial] 
NEAR 
   [66,66,{"maxDistance":1}]

索引文档告诉我可以使用indexes on an edge properties。不好的一面是它需要更多的存储空间然后链接列表我测试它并且它可以工作:

select 
  expand(inV())
from 
  (select 
      expand(month["12"].day["25"].hour["17"].min["07"].outE('MinPublicEvent'))
   from 
     Year 
   where 
     year = 2015)
where
   [lat,lng,$spatial] 
NEAR 
   [66,66,{"maxDistance":1}]

1 个答案:

答案 0 :(得分:1)

关于边缘与链接,取自OrientDB doc: lightweight edges,第一个区别是边可以存储属性而链接不能。

  

这些是轻量级边缘与常规边缘的PROS和CONS:

     

优点:

     

创建和遍历速度更快,因为不需要额外的   文档以保持2个顶点之间的关系

     

CONS:

     

无法存储使用轻量级边缘的属性   SQL,因为边缘下没有常规文档

由于您已经提到在边缘使用属性,这对我来说很有意义,因为您可以在边缘使用这些属性来横向图形,这意味着您无法使用链接来存储该关系。

如果你想在事件顶点上嵌入这些属性,那也没关系,你就可以使用链接,从而失去了使用边缘属性来横向图形的有利条件,有利于改进性能

边缘方法更具表现力,但是当性能真正重要且存在瓶颈风险时,您应该监控指标和性能,并在出现性能问题时重构嵌入+链接方法。

<强>更新

群集基本上是一种在OrientDB (Clusters tutorial)中分割数据的机制,它适用于边缘和顶点。

  

您可能还发现定位不同的群集是有益的   不同的服务器,物理上分隔存储记录的位置   你的数据库。这样做的好处包括:

     
      
  • 优化:根据您的需要,针对群集执行查询的速度更快   只需搜索一个类中的集群子集。
  •   
  • 索引:通过良好的分区,您可以减少或删除使用&gt;索引。
  •   
  • 并行查询:对数据进行查询时,可以并行运行查询   多个磁盘。
  •   
  • 分片:您可以​​分割大型数据集   多个实例。
  •   

除非您能够清楚地识别出对数据进行分区的好方法,并且可以在不同服务器之间分发数据库,​​我建议您从默认开始,因为OrientDB已经为模式中的每个类创建了1个集群,并添加了更多集群随着数据库的增长。

何时添加更多群集?指标,指标和指标。跟踪应用程序访问数据库的方式,查询类型,查询量等。