Graph 如何减少Titan中两个顶点之间相同边标签的数目

Graph 如何减少Titan中两个顶点之间相同边标签的数目,graph,titan,gremlin,Graph,Titan,Gremlin,假设我们有两种类型的顶点:LOGIN\u USER(属性:USER\u id)和IP(属性:IP),它们之间的边是:LOGIN(属性:session\u id,LOGIN\u time) 该模型的问题是,一个用户和IP之间有两条多条边(可以是数千条)。 是否有办法减少两个顶点的边数,同时保留sessionId和login_time属性?我们想为一些查询过滤这两个属性。 边属性不支持基数:列出顶点属性支持的顶点 如果将所有边属性放入顶点,是否会影响获取顶点的性能? 当titan加载顶点的属性时??

假设我们有两种类型的顶点:LOGIN\u USER(属性:USER\u id)和IP(属性:IP),它们之间的边是:LOGIN(属性:session\u id,LOGIN\u time)

该模型的问题是,一个用户和IP之间有两条多条边(可以是数千条)。 是否有办法减少两个顶点的边数,同时保留sessionId和login_time属性?我们想为一些查询过滤这两个属性。 边属性不支持基数:列出顶点属性支持的顶点

如果将所有边属性放入顶点,是否会影响获取顶点的性能? 当titan加载顶点的属性时??当遍历到一个顶点时,让我们使用g.V(1).next(),Titan是否加载该顶点的所有属性?

当你说用户和IP之间有“数千”条边时,你认为它实际上可能是“数百万”或“数千万”或更多?如果不是,那么“数千”对泰坦来说就不是问题了。索引您的边属性,您应该有快速排序和遍历

当你开始深入“百万”时,你可能会遇到一些问题——对我来说,一直以来都是使用titan hadoop处理全局查询,因为顶点及其边必须保存在内存中。当你进行全球分析时,这可能会造成一些麻烦。从操作角度来看,Titan总是乐于将边写入顶点上的数百万条边,但我倾向于避免这样做。当然,我在《泰坦1.0》中有过很多这样的经历:

切割顶点意味着存储该顶点邻接的子集 在图中的每个分区上列出。换句话说,顶点和 它的邻接列表被划分,从而有效地分布了 在群集中的所有实例上加载该单个顶点 以及消除热点

当您开始将超级节点增加到数百万时,您可能会尝试使用它

我想数百万条边中的超级节点的另一个选择是围绕它建模。也许您在用户和IP之间引入了一些结构。将单个登录边转换为可能在它们之间引入时间概念的某些顶点/边,如:

用户->登录年份->登录月份->IP


因此,现在,您可以创建登录年份顶点和登录月份顶点,而不是在用户和IP之间创建一条边。

谢谢。我们正在测试DynamoDB。您现在使用的是哪种存储器??目前我们发现两个顶点之间的边太多,速度很慢。此外,当我们运行g.V('userId').out('LOGIN').in().values()时,将看到大量重复的顶点,Titan返回所有edge的inVertex,尽管大多数边路由到同一个顶点。我的经验是cassandra。我认为你的顶点复制是预期的遍历。您从用户处向外遍历
out
,然后在
中向后遍历
,并且您所遍历的原始顶点位于该路径中。你必须过滤掉那些通向起始顶点的路径。我怀疑您还想删除重复项。因此,您的遍历看起来像:
g.V('userId')。as('x')。out('LOGIN')。in()。where(neq('x'))。dedup()。values()
您体验到的数据量是多少?十亿水平?
g.V('userId').as('x').out('LOGIN').in().where(neq('x')).dedu的查询延迟如何‌​p().values()
?是-图形中总共有数十亿条边,但在单个顶点上从未超过过数百万条。我不知道你会看到我的遍历和你的遍历在速度上有多大的不同——我只是想过滤掉一些重复的遍历。如果要在遍历遇到多条边的顶点时加快遍历速度,则需要通过创建一些以顶点为中心的索引并在遍历中使用它们来更好地过滤边。这样,Titan应该将过滤器向下推到数据库,并返回更少的数据。谢谢你的建议stephen。我现在用的是卡桑德拉。我为边设置顶点分割和顶点中心索引。但我的查询速度相当慢,我不确定这是否常见。g、 V('userId').as('x').out('LOGIN').in().where(neq('x')).dedu‌​p().values()将花费数百秒。Titan可以并行查询吗?我还测试limit()来限制结果,但仍然很慢。泰坦是否先得到结果,然后再进行“限制”?如何知道泰坦的执行计划?