The latest version of Jena TDB adds atomic transactions (version 0.9.0+)
See http://jena.apache.org/documentation/tdb/tdb_transactions.html for
documentation:
The following limitations are listed:
- Bulk loads: the TDB bulk loader is not transactional
- Nested transactions are not supported.
- Some active transaction state is held exclusively in-memory, limiting
scalability.
- Long-running transactions. Read-transactions cause a build-up of
pending changes;
- If a single read transaction runs for a long time when there are many
updates, the system will consume a lot of temporary resources.
On Tue, May 29, 2012 at 7:00 PM, Fleming, Declan <[log in to unmask]> wrote:
> Hi Ravi - I'll let some of my more technical folks chime in, but we do a
> bunch with RDF and have found every triplestore we've tried very limited in
> handling transactions. Reading and writing at the same time causes a
> deadlock that's a mess to keep clean. So, we went back where we started
> and created a triplestore using SQL with big tables of triples. We cheat a
> little bit with a fourth column for ID and a fifth that helps speed up
> blank node searching. This has helped us avoid these transactional
> problems we were having, and the performance is quite good for ingest.
>
> Most of our searching is done by stuffing the triples into solr in a JSON
> format, so we don't rely on the backend data store for that much. We also
> sync the SQL triples to Allegrograph in case we need deeper SPARQL things,
> but we're thinking of shedding this from our architecture.
>
> Declan
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Ravi Shankar
> Sent: Tuesday, May 29, 2012 12:12 AM
> To: [log in to unmask]
> Subject: [CODE4LIB] triple stores ???
>
> We (DLSS at Stanford Libraries) are planning to use a triple store for
> storing and retrieving annotations (in RDF) on digital objects. We are
> currently looking at open-source triple stores such as 4store, Virtuoso,
> Jena SDB and Mulgara. Are you currently using a triple store or
> contemplating on using one? How would you evaluate 'your' triple store
> along the lines of 1) ease of setup, 2) scalability, 3) query performance,
> 3) bulk load performance, 4) access api, 5) documentation and 6) community
> support?
>
> Highly appreciate your thoughts, ideas and suggestions.
>
> Thanks,
> Ravi Shankar
>
|