跳至内容

高级模式

本页介绍了JanusGraph提供的一些高级模式定义选项。有关JanusGraph模式及其定义的一般信息，请参阅Schema and Data Modeling。

静态顶点

顶点标签可以被定义为静态，这意味着带有该标签的顶点在创建它们的事务之外不能被修改。 

mgmt = graph.openManagement()
tweet = mgmt.makeVertexLabel('tweet').setStatic().make()
mgmt.commit()

静态顶点标签是一种控制数据生命周期的方法，在将不应在创建后修改的数据加载到图中时非常有用。

边和顶点TTL

边和顶点标签可以配置生存时间（TTL）。 具有此类标签的边和顶点将在初始创建后经过配置的TTL时间后自动从图中移除。 TTL配置在将大量仅临时使用的数据加载到图中时非常有用。定义TTL无需手动清理，并能非常高效地处理移除操作。 例如，对于用户页面访问等事件边，当这些数据在一定时间后被汇总或不再需要用于分析或操作查询处理时，设置TTL是合理的。

以下存储后端支持边和顶点的TTL。

  • CQL兼容存储后端
  • HBase
  • BerkeleyDB - 仅支持小时离散的TTL，因此最小TTL为一小时。

边生存时间

边TTL是基于每个边标签定义的，意味着该标签的所有边具有相同的生存时间。请注意，后端必须支持单元格级别的TTL。目前只有CQL、HBase和BerkeleyDB支持此功能。 

mgmt = graph.openManagement()
visits = mgmt.makeEdgeLabel('visits').make()
mgmt.setTTL(visits, Duration.ofDays(7))
mgmt.commit()

请注意，修改边会重置该边的TTL。同时请注意， 边标签的TTL可以被修改，但此更改可能需要一些 时间才能传播到所有正在运行的JanusGraph实例， 这意味着同一标签可能会暂时使用两种不同的TTL。

属性生存时间

属性TTL与边TTL非常相似，并在每个属性键的基础上定义，这意味着该键的所有属性都具有相同的生存时间。请注意，后端必须支持单元格级别的TTL。目前只有CQL、HBase和BerkeleyDB支持此功能。 

mgmt = graph.openManagement()
sensor = mgmt.makePropertyKey('sensor').cardinality(Cardinality.LIST).dataType(Double.class).make()
mgmt.setTTL(sensor, Duration.ofDays(21))
mgmt.commit()

与边TTL类似，修改现有属性会重置该属性的TTL，并且修改属性键的TTL可能不会立即生效。

顶点生存时间

顶点TTL是基于每个顶点标签定义的，意味着该标签的所有顶点具有相同的生存时间。配置的TTL适用于顶点、其属性以及所有关联边，以确保整个顶点从图中被移除。因此，顶点标签必须定义为静态，然后才能设置TTL，以排除任何会使顶点TTL失效的修改。顶点TTL仅适用于静态顶点标签。请注意，后端必须支持存储级别的TTL。目前只有CQL、HBase和BerkeleyDB支持此功能。 

mgmt = graph.openManagement()
tweet = mgmt.makeVertexLabel('tweet').setStatic().make()
mgmt.setTTL(tweet, Duration.ofHours(36))
mgmt.commit()

注意，顶点标签的TTL可以被修改，但此更改可能需要一些时间才能传播到所有正在运行的JanusGraph实例，这意味着同一标签可能会暂时使用两种不同的TTL。

Multi-Properties

如Schema and Data Modeling中所述，JanusGraph支持具有SET和LIST基数的属性键。因此，JanusGraph支持在单个顶点上具有相同键的多个属性。此外，JanusGraph将属性与边类似处理，允许在属性上使用单值属性注解，如下例所示。 

mgmt = graph.openManagement()
mgmt.makePropertyKey('name').dataType(String.class).cardinality(Cardinality.LIST).make()
mgmt.commit()
v = graph.addVertex()
p1 = v.property('name', 'Dan LaRocque')
p1.property('source', 'web')
p2 = v.property('name', 'dalaro')
p2.property('source', 'github')
graph.tx().commit()
v.properties('name')
==> Iterable over all name properties
这些特性在许多应用中非常有用，例如那些需要将来源信息（例如谁添加了属性、何时以及从何处？）附加到属性的场景。支持更高基数的属性以及属性上的属性注解，在高并发、横向扩展的设计模式中也很有用，如Eventually-Consistent Storage Backends中所述。

对于属性，支持以顶点为中心的索引和全局图索引，其方式与对边的支持相同。有关为边定义这些索引的信息，请参考Indexing for Better Performance，并使用相应的API方法为属性定义相同的索引。

Unidirected Edges

单向边是指只能沿出方向遍历的边。单向边具有较低的存储占用，但在支持的遍历类型上有限制。单向边在概念上类似于万维网中的超链接，即出顶点可以穿过该边，但入顶点并不知道它的存在。 

mgmt = graph.openManagement()
mgmt.makeEdgeLabel('author').unidirected().make()
mgmt.commit()

注意，当入顶点被删除时，单向边不会自动删除。用户必须确保此类不一致性不会出现，或在查询时通过显式检查事务中的顶点存在性来解决它们。更多信息请参阅Ghost Vertices中的讨论。