Re: [Aurelius] License conflict between Berkeley and Titan

[Matthias Broecheler]

Hey Simon,

the Titan adapter code for BerkeleyDB is Apache2 as is the rest of Titan. But you are right regarding the "viral" effect of the Sleepycat license. My understanding is that we can distribute it since all of Titan is open source, but if somebody were to use it in a non-open source project, that would be a problem imho.

Anyhow, I would love to replace BerkeleyDB by Persistit in the near future:

http://www.akiban.com/akiban-persistit

This is licensed under EPL which is "similar" to Apache2 and business friendly. Also, it seems to be faster. If somebody has a bit of time on their hand and is looking for a weekend project, this would be a great thing to help on. Copying the BerkeleyDB titan adapter and making it work with Persistit shouldn't be too hard.

Thanks,

Matthias

On Fri, Feb 22, 2013 at 10:59 PM, Simon Brandhof <simon.b...@sonarsource.com> wrote:

Hi Aurelius team,

First of all, thanks for all the hard work. Blueprints stack and Titan rock.

The bad news is that BerkeleyDB is distributed under the Sleepycat license, which is GPL-like. It's not a business friendly license like Apache2. For this reason I'm not sure that the module titan-berkeleyje, and even worth the module titan-all, can be distributed under the Apache2 license.

I hope I'm wrong. Does someone have more details ?

Thanks

--
You received this message because you are subscribed to the Google Groups "Aurelius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraph...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Matthias Broecheler
http://www.matthiasb.com

[Blake Eggleston]

Hi Matthias,

Do you know if anyone is working on implementing the Persistit backend for Titan? If not, I'd like to do it.

Thanks,

Blake

[Marko Rodriguez]

Hi,

> Do you know if anyone is working on implementing the Persistit backend for Titan? If not, I'd like to do it.

No one is and I know that Matthias is very interested in that technology as a backend for Titan.

Marko.

[Matthias Broecheler]

Yes, I don't think anybody is working on it and it would be really cool if we had it so that I don't have to answer license questions anymore ;-)

Please ping me if you have questions / need help.

Thanks, Blake.

--
You received this message because you are subscribed to the Google Groups "Aurelius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraph...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Haddad]

The java bdb's license is here: http://www.oracle.com/technetwork/database/berkeleydb/downloads/jeoslicense-086837.html

Which I believe titan comforms to.

[Blake Eggleston]

Hi Matthias & Marko,

So I've been working on the persistit backend for Titan, and I just wanted to check with you guys that Titan handles transactions a certain way. From my use of Titan, and working with the internals, it looks like transactions can be instantiated freely, without any restrictions on transactions per thread or anything like that. There doesn't appear to be anything stopping you from creating 10 transactions, adding a vertex with each, and then committing each transaction. Is that more or less correct? Any caveats?

The reason I ask is because I've run into a potential compatibility with the way Persistit handles transactions and I want to confirm my assumptions before talking to the Persistit folks about it. With Persistit, each thread has one, and only one, transaction associated with it, which is used, and goes through a begin -> commit -> end cycle, over and over. So anytime you do anything with multiple transactions in a single thread, you're actually using a single transaction, which doesn't jive with the way Titan does things.

Thanks,

Blake

[Matthias Broecheler]

Hey Blake,

yeah, its unfortunate that persistit does not seem to have a notion of a transaction independent from the executing thread. In Titan, transaction and thread are two independent notions. While the default blueprints transactions are tied to threads, Titan's newTransaction() opens thread independent transactions.

We could consider this to be a limitation of this particular storage backend but I would have to think on whether this would actually work or how we would need to signal this behavior so Titan can act accordingly.

Thanks for looking into this,

Matthias

--

You received this message because you are subscribed to the Google Groups "Aurelius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraph...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Thornton]

Hi Guys -

LevelDB (http://en.wikipedia.org/wiki/LevelDB) and/or HyperDex might be good candidates to replace the Titan-BDB if you are concerned about BDB's GPL licensing.

LevelDB is BSD licensed (https://code.google.com/p/leveldb/) and it's "designed be useful as a building block for higher-level storage systems" (http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html).

As you may know it was written by Google's top two engineers -- Jeff Dean and Sanjay Ghemawat (http://www.wired.com/wiredenterprise/2012/08/google-as-xerox-parc/) -- and it keeps popping up as a backend for new distributed databases...

HyperDex (http://hyperdex.org/performance/) is using LevelDB as its primary backend, and today it announced HyperLevelDB:

"HyperLevelDB: A High-Performance LevelDB Fork"

http://hyperdex.org/performance/leveldb/

HN: https://news.ycombinator.com/item?id=5833414

HyperDex is BSD Licensed (https://github.com/rescrv/HyperDex/blob/master/LICENSE).

Riak provides LevelDB as a backend option (http://docs.basho.com/riak/1.2.0/tutorials/choosing-a-backend/). 

And Peter Bailis (https://twitter.com/pbailis/) uses LevelDB for the implementation of his recently announced NBTA algorithm for distributed transactions...

"You can perform non-blocking multi-object atomic reads and writes across arbitrary data partitions via some simple multi-versioning and by storing metadata regarding related items."

"Our implementation scales linearly, to over 250,000 operations per second for transactions of length 8 consisting of 50% reads and 50% writes on a deployment of 50 EC2 instances."

http://www.bailis.org/blog/non-blocking-transactional-atomicity/

HN: https://news.ycombinator.com/item?id=5781040

NBTA Pseudocode implementation: 

http://www.bailis.org/blog/post_data/2013-05-28/ta-rc-pseudocode.png

Here are some recent benchmarks comparing LevelDB to BDB and others:

* http://symas.com/mdb/microbench/

* http://symas.com/mdb/microbench/july/

- James

[Jeff Ramsdale]

I just ran across MVStore, from H2 database: http://www.h2database.com/html/mvstore.html

It has transactions and an in-memory mode among other features, so might be a good lightweight option for Titan.

-j

[Michael Klishin]

2013/6/6 James Thornton <james.t...@gmail.com>

HyperDex (http://hyperdex.org/performance/) is using LevelDB as its primary backend, and today it announced HyperLevelDB:

"HyperLevelDB: A High-Performance LevelDB Fork"

http://hyperdex.org/performance/leveldb/

Note that LevelDB is known to perform differently for different workloads, to the point various DB vendors
have to modify it to their specific needs.

There's also a pure Java implementation of LevelDB in the works, not sure how complete it is:

https://github.com/dain/leveldb

--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

[Jon Haddad]

Blake submitted a pull request for a persistit backend almost a month ago.

https://github.com/thinkaurelius/titan/pull/275