|
I've procrastinated for some time over the continued support and I've decided that I'm going to fully and permanently deprecate it after the upcoming 0.7.x release series. This decision is open to being changed (see note at end of post) but I personally am not going to continue maintaining this feature myself
So before the few users who actually use this explode let's look at the reasoning for this:
- The performance is bad compared even to our in-memory store which scales to around 1 million or so triples on a system with 2-4GB of RAM. In benchmarking we typically see an order of magnitude difference. Bottom line if your data is small then you should just keep it in memory (and persist to disk as needed) and if it is big then you shouldn't be using our SPARQL engine anyway
- We support a variety of both open source and commercial triple stores which have a range of scaling and performance characteristics as my recent Practical SPARQL Benchmarking talk demonstrated. There should be something that meets everyone's performance, scaling and licensing needs and all our exposed via our standard storage API
- Support what people actually use - I only know of one or two users who use this support. Most people are using proper other triple stores with our API and why support and compete on our own backend when we can focus on the things we already do well - building a solid general purpose RDF and SPARQL API
As with anything open source this is open to discussion, so if people want this to continue and want to make it better it is up to you to make the arguments for that and take over support for this feature either within the project or outside of the project. 07/06/2012 19:42:51 by Rob Vesse in English
237496 Views
There are currently no Tags for this Content!
|