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
并发查询时 /gremlin接口返回的结果与预期不符合 #2486
Comments
你好,@fantengfeiNana!很高兴再次看到你的问题,希望这次我们也能一起找到解决方案。 根据您的描述,我理解您在使用HugeGraph 1.2.0版本时,通过/gremlin接口并发执行g.V().count()和.g.E().limit(9999)时,返回的数据与预期不一致。这可能是由于HugeGraph的设计和配置,以及图数据库并发操作的特性导致的。以下是可能的原因和解决策略:
解决策略:
关于/gremlin接口的行为,根据提供的代码,该接口的请求处理方式(同步或异步)是由底层服务器框架(例如Servlet,Netty)和HugeGraph服务器的配置决定的,而不是在提供的代码片段中明确定义的。然而, 在提供的代码中, 关于HugeGraph如何在并发场景中确保缓存一致性,HugeGraph通过组合缓存失效,清除和事件监听机制来确保缓存一致性。具体来说, 在接收到特定事件后,系统会使缓存项失效或清除。例如,当一个顶点或边被更新或删除时,相应的缓存项会被使失效,以确保后续的读取从后端存储中获取更新的数据。这是在 系统根据某些条件决定是否缓存查询的结果,例如结果集的大小和查询的类型。对于顶点,它检查顶点是否有低于某个阈值的属性数量( 在变更提交到后端存储后,缓存会相应地更新。如果顶点被更新或删除,它们的缓存项要么被更新(如果它们仍然满足缓存条件),要么被使失效。如果任何顶点或边发生变化,边缓存会被清除,以确保边查询获取最新的数据。这是在 系统使用事件中心( 总的来说,HugeGraph通过事件驱动的缓存失效和清除,基于查询特性的条件缓存,以及后端变更后的主动缓存更新的复杂机制,确保了并发场景中的缓存一致性。这种方法有助于保持缓存数据与底层数据存储的一致性,即使在并发读写操作的情况下也是如此。 关于您提到的异常,我在HugeGraph的issue中找到了一个类似的问题[Bug] Incorrect return value of the same query,这个问题在2022年11月6日的最后一次更新中仍然是开放的。建议的解决方案是减少数据集到3条边,问题仍然存在。这可能与您遇到的问题有关,您可以参考这个issue的讨论。 希望这些信息对您有所帮助。如果您有任何其他问题或需要进一步的澄清,请随时提问。 Sources
|
Could u provide a MVP way to reproduce the problem? And also could refer #2187 (comment) to use |
Bug Type (问题类型)
gremlin (结果不合预期)
Before submit
Environment (环境信息)
Expected & Actual behavior (期望与实际表现)
我们现在使用hugegraph1.2.0版本作为底层应用,当我们 使用一个线程池并发执行g.V().count()【获取顶点个数】和.g.E().limit(9999)【获取所有的边集合】时,发现接口返回的数据与请求的预期不一致,导致进一步解析时无法正确解析,请问/gremlin接口是异步么,还是需要控制访问方式?直接现象就是g.E().limit(9999) 返回的结果是 g.V().count()执行的结果
当我使用自动化测试时,并发执行时,hugegraph也是偶现异常
请问我该如何解决此类问题?
Vertex/Edge example (问题点 / 边数据举例)
No response
Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)
No response
The text was updated successfully, but these errors were encountered: