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
>>
|
