The sqlite poeple should move to gdbm
On Oct 11, 6:21 am, Stef Mientki <stef.mien...@gmail.com> wrote: > On 11-10-2010 04:38, mdipierro wrote:> This all happened in less than 2 > months: > > >http://blogs.computerworld.com/16741/oracle_dumps_opensolaris > >http://www.techeye.net/business/creator-of-zfs-to-leave-oracle > >http://openquery.com/blog/ken-jacobs-leaves-oracle > >http://www.theregister.co.uk/2010/10/07/mysql_veteran_leaves_sunoracle/ > >http://www.theregister.co.uk/2010/09/28/openoffice_independence_from_... > >http://arstechnica.com/tech-policy/news/2010/08/oracle-sues-google-ov... > > >http://globalspecials.sun.com/store/mysql/ContentTheme/pbPage.categor... > > > The last link affects us more directly. If you have to choose use > > postgresql, not mysql. > > > Massimo > > and how will that affect SQLite ? this was on the SQLite group 21 july 2010: > > Hello, > > My name is Greg, I'm one of the product managers within Oracle working on the > Berkeley DB products. I joined Oracle when Sleepycat was acquired but I've > been working on BDB for nearly nine years now. I was the one who pushed hard > to integrate SQLite and BDB, I think the two products go well together > without damaging either one. I am also the guy responsible for most of the > messaging on the Oracle.com website (with a lot of editing oversight and > marketing input), so if you want to question something there please just > email me. > > We here in the Berkeley DB team within Oracle's Embedded Database group are > thrilled to have Oracle join the SQLite Consortium. Today and in the past > our goal with open source collaborations has been to work closely together, > help each other out, keep things informal-yet-formal, and give credit where > credit is due. The SQLite product is excellent, we don't want or need to > fork it. The SQLite3 ANSI C API is like the BDB ANSI C key/value API, > de-facto standards in their respective spaces. From our view this > combination is like chocolate and peanut butter, two great products that go > well together. Some will like this combo and find value in it, others won't. > That's okay, in fact it's the way it should be. We are thrilled to be > joining this community, we're not the enemy or the competition. > > Clearly there are going to be many questions, I'm here to help answer them as > best I can. > > License: Oracle Berkeley DB is not licensed under the GPL. Berkeley DB is > released under the terms of the Sleepycat License. The Sleepycat License is > significantly different from the GPL, take a look. > http://en.wikipedia.org/wiki/Sleepycat_License > > Compatibility: "... [the] application-level behavior of the two products is > identical..." Okay, this is a bit of an overstatement at this point and I > freely admit that. This is our long-term goal, so I think it's fair to put > have it on our site. Basically we're telling people that we'd like to be as > close to 100% drop-in compatible as possible while still providing the unique > value of Berkeley DB as a btree storage engine. For our first release, I > think you'll have to admit that we are very close to the mark. We're already > nearing a patch release and it is even closer. This will evolve, both SQLite > and BDB's SQL will benefit along the way. > > Comparison: "... improved performance, concurrency, scalability, and > reliability." Fundamentally, we are faster because we don't lock the entire > database on writes as SQLite's btree does. BDB is designed for concurrent > multi-process/thread access, this gives us a speed advantage when there is > any concurrency in the system. Single-threaded performance is a more > apples-to-apples comparison and this is more evenly matched. The product is > evolving fast, we're constantly finding ways to use advanced features in BDB > for special cases in SQLite. Again, we're only just in release 1 of the > combined product and we're already in very good shape to be faster in general. > > MVCC: We're going to add in support for MVCC (snapshot isolation), it's not > there in the first release. This will continue to help speed up concurrent > access and prevent deadlocks. > > HA: Clearly we're going to integrate (in a SQLite-friendly way) support for > HA/replication. It's not there in this release. If you have ideas for how > to properly make this fit into the product let us know! Should it be a > PRAGMA? Should it be C-functions? Something else? Speak up now. > > Compaction: We punted on compaction in the first release because we wanted to > do it using BDB's built-in compaction code (which can compact the database > and optimize the btree while it's being used, it can even do this a little > bit at a time so as not to be overly disruptive). We didn't get this into > the code line in time for the first release, it's coming very soon. > > Compression: BDB has support for compression of things stored in the > database, this is something we hope to integrate into the SQL API very soon. > > Encryption: Again, we are hard at work on this. BDB already supports > encrypted databases, so it won't be hard to do. > > We are also working on a comparison paper with Mike Owens (of "The Definitive > Guide to SQLite" fame). We hope to get this finished very soon and make it > available for comment. Mike is doing a great job of really providing a > critical view of our combined product, which is exactly what we want. > > There is a lot more we're working on, we're focused on a number of > improvements in BDB itself and in our adaptor layer between BDB and SQLite. > What's great about this is that for fifteen years we had avoided SQL and just > focused on being the best transactional storage engine around and I'd say we > did a pretty good job of that. Now we can happily join forces with a great > community focused on the SQL piece. SQLite does an amazing job of providing > the features of a relational database and SQL92 in a stunningly small > package, we hope to add our world-class btree storage layer and experience to > that package. > > We believe that this is good news for everyone, I hope you feel that way too. > > -greg
