【问题标题】:Orientdb Super Slow Query PerformanceOrientdb 超慢查询性能
【发布时间】:2018-06-09 15:43:43
【问题描述】:

我已经尝试了几件事太久了,我正在为 Orientdb Community edition 3.0.0RC2性能而苦苦挣扎。当前查询需要 60-100 秒 之间的任何时间运行,但我认为它应该需要几毫秒,因为使用索引设置扫描 只有 27k 条记录。服务器(普通服务器配置)设置在我的个人电脑上,它有 8gb 内存和 HDD

要运行的查询:select count(*) from ClassA where InitialInvestment = 2000

  • A 类(26,844 条记录):
  • 初始投资 |双
  • 杠杆ETF百分比|双
  • 市场百分比 |双
  • 总体回报 |双
  • 百分比现金 |双
  • 季度添加 |双
  • 开始日期 |日期
  • 结果 | EmbeddedList -> Class DataRecord(每个结果列表大约有 9-10k 项)

索引(都已“重建”):

  • InitialInvestment 上的 NotUnique SBTREE
  • MarketPercent 和 LeveragedEtfPercent 上的 NotUnique SBTREE
  • MarketPercent、LeveragedEtfPercent 和 StartDate 上的唯一 SBTree

Class DataRecord(奇怪的是,0 条记录显示在 Studio 的 Schema 视图中,但嵌入列表中的项目显示“DataRecord”类 - 会询问这个 之后)。这个类只有三个 DOUBLE 字段和一个 Date 字段。怀疑这个类正在影响查询,因为我没有尝试查询它。

有什么想法吗?

【问题讨论】:

    标签: orientdb


    【解决方案1】:
    1. 当 v3.0 GA 发布超过 1 个月时,不要使用候选发布版本。现在您可以获得 v3.0.2 GA 版本。
    2. 您能执行一下解释吗? explain select... 这样您就可以检查是否使用了任何索引。请通过更新您的问题发布结果。
    3. 通过嵌入 9 到 10 万个 DataRecord 对象,您的记录看起来太胖了。在主记录之外创建 DataRecord 对象并链接到它们要轻松得多。

    【讨论】:

    • 感谢Lvca的快速回复!我会试一试这些建议并报告回来。您会建议使用 LinkedList 还是使用边?
    • 如果你不需要双向边,你可以使用 LinkedList,但是一旦你有了边,你就可以在顶点之间来回走动,这很好。此外,如果您需要使用 Gremlin 或 Graph 算法,它们仅适用于边缘。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-03-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-05-18
    • 2021-09-26
    • 2015-04-11
    相关资源
    最近更新 更多