FYI: There is a Jena data storage implementation on Cassandra ( https://github.com/Claudenw/jena-on-cassandra) that is still in development. It should horizontally scale as Cassandra does. It does not have any custom ARQ code so it is not fully tuned yet.
Claude On Sat, Jan 21, 2017 at 1:38 AM, De Gyves <[email protected]> wrote: > I'd like to participate on the storage portion of Jena, maybe TDB. As I > have worked many years developing with RBDMS I like to explore new > horizonts of persistence and graph based ones seem very promising to my > next projects, so i'd like to use SPARQL and RDF with Jena/TDB and see how > far I can go. > > So I've spent the last two days exploring subjects of the mail archives > from august 2015 to january of this year the of jena-dev and found some > interesting threads, as the development of TDB2, the tests of 100m of BSBM > data, a question of horizontal scaling, and that anything that implements > DatasetGraph can be used for a triples store. Some readings of jena doc > include: SPARQL, The RDF API, Txn and TDB transactions. > > What I am looking for is to get a clear perspective of some requirements > which are taken for granted on a traditional RDBMS. These are: > > 1. Atomicity, consistency, isolation and durability of a transaction on a > single tdb database: Apart from the limitations on the documentation of TDB > Transactions and Txn, there are current issues? edge cases detected and > not yet covered? > 2. Are there currently available strategies to achieve a horizontal-scaled > tdb database? > 3. What do you think of try to implement a horizontal scalability with > DatasetGraph or something else with, let's say, cockroachdb, voltdb, > postgresql, etc? > 4. If there are some stress tests available, e.g. I read about a 100M of > BSBM test, is it included in the src? or may I have a copy of it? I'd like > to see what the limits are of the current TDB, and maybe of TDB2: maximum > size on disk of a dataset, max number of nodes on a dataset, of models or > graphs on a dataset, the limiting behavior of a typical read/write > transaction vs. the number of nodes, datasets, etcetera. Or, some > guidelines, so I can start to create this stress code. Will it be useful to > you also? > > -- > Víctor-Polo de Gyvés Montero. > +52 (55) 4926 9478 (Cellphone in Mexico city) > Address: Daniel Delgadillo 7 6A, Agricultura neighborhood, Miguel Hidalgo > burough > ZIP: 11360, México City. > > http://degyves.googlepages.com > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
