 |
 |
Hey Ravi, I actually learned about TinkerPop from a posting on this list from Brian Tingle and I started playing with it and eventually started working with it for the digital repository we're building. I actually began with the Sail extension, but scaled back to non-RDF model on that after realizing it wasn't really a requirement that our users were asking for...simply using it as a graph db makes things go a lot quicker. Of course, we're planning on revisiting implementing the RDF-based model in "the future". In TinkerPop/Neo4j, there's ACID transaction support and there a bulk loading utility. However, there is not transaction support in the bulk loader...also, I think Sail has kinda different/weird transaction support, but I think you can override that in Tinkerpop somehow... b,chris. On Wed, May 30, 2012 at 2:29 AM, Simon Spero <[log in to unmask]> wrote: > 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 >>