[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Sub-contexts

I talked a little more about the backend question with Mike today.

For 4. the only XDI native store I know of is Markus's. It has a context provider higgins.idas.cp.xdi but Mike was not sure if this was finished and working. From the XDI folks perspective, of course using an XDI store would be ideal. Markus, do you think it is ready?

For 3. (or 2.) writing a context provider could be a joint effort among Azigo, the 3rd party DB vendor, and others like me. On the other hand, to do performance testing of Higgins with a new DB, there should be a benchmark or stress testing app, and Azigo would be best placed to specify and write the benchmark, which I'm guessing would not be hard.

Mike said that we would not expect performance problems for another year or so when bigger deployments are expected. Putting a small amount of work into evaluating databases now might save much more pain later. Perhaps this could even be presented as a distinct project - for example I heard Marc Davis asking if there has been performance testing. The DB vendors might be persuaded to help with the integration work, and then would have the next year to work on any performance problems themselves. Mike said that our current challenge right now is defining API to support adding metadata to sub-contexts, not performance, so having someone else do performance work would be an advantage.

I asked Mike what features we should specify as necessary or desirable in a graph database. He suggested we need to be able to attach arbitrary attributes to sub-contexts (subset of attributes from a context) but that I post to the list as Paul, Sergey and Vitaliy could respond.

Some of the graph databases offer features like multiple traversal that may be higher level than can be expressed by the Context Provider API. If we want to make use of any of these features, of course the sooner we know about them, the better. Also some of the graph databases claim to provide distributed storage and to try to optimize access across that distributed storage; this could also be very useful for large scale deployment, but needs to be tested in practice.

On May 27, 2010, at 7:17 AM, Paul Trevithick wrote:

> Thanks for the pointers Joe.
> On May 26, 2010, at 8:37 PM, Joseph Boyle wrote:
>> I continue to hear of more graph databases - just saw http://www.infinitegraph.com/ today. I also know of http://www.kobrix.com/hgdb.jsp and http://www.dekorte.com/projects/opensource/vertexdb/ .
>> There's also a list at http://en.wikipedia.org/wiki/Graph_database
>> On May 25, 2010, at 4:02 PM, Paul Trevithick wrote:
>>> Options:
>>> 	1. Get on the NG4Jena mailing list and ask for advice [We should do this no matter what]
>>> 	2. See if there are alternative open source quad stores with better performance/scalability
>>> 	3. Explore non-relational open source graph data bases (e.g. Infogrid, Neo4j, etc.)
>>> 	4. Use an XDI native store
>> _______________________________________________
>> higgins-dev mailing list
>> higgins-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev