I'm New to OrientDB, How should I traverse in OrientDB to find all the longest Path irrespective of direction, also find all closed paths?
Related
What is the most efficient way to store a directed graph with vertices and edges in mongodb?
I have stored it as a collection node and a collection edge where each edge has source and target both pointing at the node collection.
But is this the most efficient way to do it if I want to traverse the graph and retrieve successors and predecessors?
Edit
Each node and edge won't have much other data (maybe 2 other fields) and each node will not have many edges (between 1-5).
MongoDb is not suitable for graphs. There are better alternatives than mongoDB as graph database. You can explore Orientdb, it's open sourced. If you are looking for more professional and performance optimized graph database, then go for Neo4j.
Does anybody know how to compute the connected components of a graph with an OrientDB query?
I'm trying to replicate what was done here but I'm missing something similar to a REDUCE operator for collections.
Thanks in advance.
This query
SELECT distinct(traversedElement(0))
FROM (TRAVERSE both('ManagedBy') FROM Employee)
Returned me the right result. At the beginning I could not understand why but then I figured out that the default strategy used in TRAVERSE is DFS that's why we can rely on taking the first node of each traversal as a representative for its connected component.
how to get only the top 100 matching results in neo4j FT index queries. I am sure for common searches the index will match thousands of nodes but i would need only say the top 100 highest scored matches. What configuration settings or query context should i set to achieve this. How is this possible in REST API without cypher. Is cypher a must to get these 100 top scored full text matches. Thanks for any help!
The simplest way would probably be using Cypher's LIMIT clause. Since you explicitly asked for non cypher solutions, the only option is to write a unmanaged extension that runs the index query and does not fully consume the iterator.
I have a collection, name Events:
Each document in Events collection has source and destination in lat-long.
I would like to make a query on the Events collection and get only those events that are within some distance from source and within some distance from destination.
I read that MongoDB does not support two geospatial indexes on one collection.
I am confused as in how my data model should look like and how can I make a query to achieve my purpose?
Thanks
You'll have to work with the geo index limitation, so it leaves you with a couple of options. One is to create two collections and run two queries, and resolve the intersection at the application level. This could be expensive depending on what you're doing.
The other scenario is to work with one collection, but change your query to check $geowithin some geometry which represents the intersection area of the areas around your source and destination. Since you're querying for events that are both within some distance of your source and destination, this implies that there is an intersection area. It is up to you to calculate the intersection geometry. If possible, you can precalculate and store these intersections.
You may only have 1 geospatial index per collection, for now. While MongoDB may allow to create multiple indexes, this behavior is unsupported. Because MongoDB can only use one index to support a single query, in most cases, having multiple geo indexes will produce undesirable behavior
There are a few tickets in JIRA for this that you might want to vote on:
https://jira.mongodb.org/browse/SERVER-2331
https://jira.mongodb.org/browse/SERVER-3653
I am looking for a database implementing 2 geospatial indexes or allowing to simulate it efficiently.
Motivation: our application deals with vectors, rather than locations and we often need to locate all the records where the source is near something and the destination is near something else.
Mongodb does not have it. Is there a database, which does?
May be it could be simulated with the mongodb map reduce feature, where the database looks up all the records satisfying the source constraint and then passes it through the map-reduce to leave those, which satisfy the destination constraint as well. Did anyone do it?
Thanks.
It might be possible to fake this with MapReduce in Mongo, but this would only be suitable for use as a batch job and not likely to perform well as an application level query.
A workaround would be to store the source and destination points in separate Mongo collections. Then you could do a query on the source collection using $near to pull the closest points to the source point, then do another $near query against the destination collection, and compute the intersection in memory.
Another option - since you can use the geospatial index to index a field which contains an array of points, store both the source and destination points as elements in an array. Then issue two queries to that collection (one for the source point, one for the destination) and scan through the two result sets to calculate the final result (the queries won't distinguish between which match was the source and which was the destination, so you'd have to check that on the client side).