Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HugeGraph的id策略疑问 #1349

Closed
NorthShip opened this issue Jan 27, 2021 · 4 comments
Closed

HugeGraph的id策略疑问 #1349

NorthShip opened this issue Jan 27, 2021 · 4 comments

Comments

@NorthShip
Copy link

我在设置id策略为PRIMARY_KEY以后,查看点的id仍然为系统生成的id,形式如:10:11 。
我在建立边的时候,希望通过主键来进行关联,但是API中需要使用id。id对我来说是未知的值,导致每次加载边都需要先查出来id,然后再进行关联。有没有办法可以让id直接和主键相等,从而解决这个问题?

@imbajin
Copy link
Member

imbajin commented Jan 29, 2021

首先得明白选择主键模式的原因, 这得从自己业务需求数据来看:

  1. 不同 label 的点 id 之间是否可能重复冲突? (比如 tom 既可以是人(Person)的名字, 也可以是猫 (Cat) 的名字)
    • 如果直接使用自定义id, 那么你需要从业务层面维护两个tom对应不同id
    • 如果使用主键模式, 则它通过不同的 label 前缀就帮你避开了这个问题, 从而 1:tom2:tom 可以共存
  2. 是否需要一个前缀标识当前点的类型?
  3. 另外就是在前缀没有加hash/盐的存储结构下, 比如 mysql 中, 有 labelId 作为前缀应该可以更高效的做 hasLabel() 的scan查询

如果你并不存在以上场景需要, 选择自定义主键就可以了. (此时你需要自己维护vid唯一, 参考文档)

如果你需要主键模式的益处, 再回到你说的问题:

  1. 边id本身就由点id构成, 不知道什么场景下会不知道点id要去查某条边呢? (除了随机取样)
  2. 然后你说的前缀的问题, 因为存在唯一映射, 在业务层存一个map<name, labelD>自己拼接一下1:2: 传入就可以了.

@NorthShip
Copy link
Author

感谢大佬回复!
尚有一事不明,为什么我的策略为PRIMARY_KEY的时候,生成的id不是VertexLabel+PrimaryKeyValues的形式,而是VertexLabel+f(PrimaryKeyValues)的形式。
例如:同一label下PK为64、65、93的点,生成的id分别为10:210,10:211,10:21T。
这样我就没法发通过label前缀+PK来定位一个点了,我的主要疑问就在这里。
label和冒号前的数字10之间的map<name, labelD>可以理解,没有疑问。

@imbajin
Copy link
Member

imbajin commented Feb 1, 2021

你应该用的v0.11 版本的 Server 吧, 因为主键模式下数值类型会做统一编码/压缩, 你也有两个方式:

  1. 可以使用最新版的代码, 在PR中增加了一个不编码的开关, 这样就不会出现你说的问题了
  2. 数值编码印象里也是一个工具类, 你也可以把它搬出来, 上层自己做一次转换

方法1可以优先考虑.

@NorthShip
Copy link
Author

明白了,再次感谢大佬!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants