I have a set of JSON-LD documents which I would like to query across and for each result return a nested JSON object for display in a user interface. For example, let's imagine I was querying an employee database to find employees with the job title "Software Developer" and for each matching Employee return the following nested structure:
I can see how I could write the filter based on the pattern matching syntax but I don't see how I could gather the data to produce the result (which in reality might be much more deeply nested.)
2. Have you benchmarked against RedisGraph?
They seem to have achieved very good performance from building atop of GraphBLAS.
In terms of framing - yes we do! Exactly like that.
TerminusDB has a document api endpoint and a special Document class - anything that inherits from this class is considered to be a complex document with internal structure - if you send a document id ("employee:bob") to the endpoint it will give you the full document for that id - and it will clip the document when you get to another document which gives you a way of supporting both document and graph views of the same data.
2. We've been keeping an eye on RedisGraph and they definitely do well when it comes to graph matrix operations - which we don't do yet, but in other areas we should be very competitive with their performance and we have more stuff going on - especially schema checking of transactions
1. We do support framing. Our documents are defined using a special superclass called "terminus:Document". Anything in the downward closed DAG up to another "terminus:Document" is considered part of that document. You can ask for some number of unfoldings of the internal documents by passing a natural number - in which case you will frame the underlying documents. We might extend this framing to allow more sophisticated approaches later if there is interest.
2. We have not performed benchmarks against RedisGraph. We intend to do benchmarks in the future but are currently focusing on collaboration features rather than raw speed.
I had just come up with some methods of using GPUs to speed up graph search when I saw the RedisGraph whitepaper and that they had already done it. I have to admit I was more than a little jealous! It's a good idea.
We'll look at the approach again in the future - our next steps are exposing CLP(fd) in our query language.
So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc.
I think it's definitely worth supporting differing depths of reference embedding along different paths. Ideally though you want want to select which properties are included as when you get to several levels of embedding the resulting document is very large and often you only need a subset of properties expanded for the embedded documents.
Additionally it can be very helpful to embed along reverse references (parent.children from the reference stored as child.parent.)
While pre-generating the deeply embedded document means fetching it is fast, as the site has grown keeping them up to date becomes challenging so I've been looking at options for embedding dynamically.
"So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc."
That's correct.
"I think it's definitely worth supporting differing depths of reference embedding along different paths."
Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.
I have a set of JSON-LD documents which I would like to query across and for each result return a nested JSON object for display in a user interface. For example, let's imagine I was querying an employee database to find employees with the job title "Software Developer" and for each matching Employee return the following nested structure:
I can see how I could write the filter based on the pattern matching syntax but I don't see how I could gather the data to produce the result (which in reality might be much more deeply nested.)2. Have you benchmarked against RedisGraph?
They seem to have achieved very good performance from building atop of GraphBLAS.