https://github.com/orientechnologies/orientdb/issues/4105#issuecomment-101072462
I'm bringing up this issue, even though I've solved the primary problems,
because it raised other questions that I think need to be answered or
otherwise documented, specifically:
Lessons Learned / Further Questions
1. Lightweight edges are not statistically faster with OrientDB 2.0.X
and can't be indexed -- don't use them unless you're only using at most a
handful of edges for any given node.
2. Groovy 2.4.3 is either significantly faster, or as fast as Groovy
1.8.9, depending upon the use case.
- *Are there any known reasons why we shouldn't use Groovy 2.4.X for
our Gremlin queries instead of Groovy 1.8.9?*
3. OrientBaseGraph::createIndex() is both awkward to use and
under-documented.
- *How do you use createIndex() to create an index with a composite
key?*
- *There's almost no useful documentation of the Parameter class.*
- *What's the difference in performance / implementation of UNIQUE
and UNIQUE_HASH_INDEX indexes?*
4. Vertex::getEdges() checks for useful indexes, but doesn't make use of
the edge index I defined.
- *Why not?*
- *What indexes would be used by getEdges()?*
- *How would I define them?*
5. Am I correct in surmising that edge data (eg: edge @rid
<https://github.com/rid>) is stored on the source and target node
records, in addition to on the edge record?
- How do we tune this?
- Is this more helpful for Gremlin or SQL queries?
- What are the practical limits to scalability, for both SQL and
Gremlin?
6. *What types of indexes could be defined to improve the performance of
Gremlin queries when working with (or through) super-nodes?*
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
