Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Oracle Unveils New Open Source BerkeleyDB Release 103

Posted by ScuttleMonkey from the time-for-first-impressions dept.
Mark Brunelli writes to tell us that Oracle has released the newest version of the open source Oracle BerkeleyDB Java Edition. From the article: "The new release of the Java embeddable database is the third to come out in three years and the first new version to come out of Sleepycat Software since Oracle purchased the open source stalwart back in February. Rex Wang, Oracle's vice president of embedded systems and a former vice president of marketing at Sleepycat, said the latest release lets Java developers take advantage of a new Persistence application programming interface (API) that provides greater flexibility and new performance optimizations that enable applications to run faster."
This discussion has been archived. No new comments can be posted.

Oracle Unveils New Open Source BerkeleyDB Release More

Oracle Unveils New Open Source BerkeleyDB Release

Comments Filter:

  • Rex Wang? (Score:1, Funny)

    by Anonymous Coward
    Rex Wang? Wasn't she one of the supervillains in one of the Austin Powers movies?

  • Many using SQLite instead. (Score:5, Interesting)

    by Anonymous Coward on Wednesday May 24, 2006 @12:25PM (#15395059)
    I know that many developers, especially on embedded or hand-held systems, are starting to use SQLite [sqlite.org] these days instead of BDB. SQLite is small enough, and efficient enough, to be used suitably in such environments. It offers SQL support, which BDB does not. And its library-based architecture is a real plus in such environments. The fact that it's public domain makes it even more appealing.

    SQLite is even starting to take over from MySQL for many smaller websites. The overhead (both in terms of system resources and administration) can't be justified when using a server-based system, especially when SQLite does the job just fine.

    What we may even see is MySQL squeezed out of the market. I know many database developers who are starting to use PostgreSQL for their higher-end databases, and SQLite for the lower-end. MySQL could be considered the best contender for mid-range DBs, but SQLite and PostgreSQL keep converging, thus pushing MySQL out to a point of irrelevance. Of course, there has been a decade and more of development using MySQL, so for legacy reasons alone it will continue to be used for ages.

    • I know that many developers, especially on embedded or hand-held systems, are starting to use SQLite these days instead of BDB. SQLite is small enough, and efficient enough, to be used suitably in such environments. It offers SQL support, which BDB does not.

      You're missing the point. Putting aside for the moment that we're discussing the Java version of BDB (which would be useless on the types of embedded platforms you're talking about), BDB is a basic database engine. Which means it's the type of software you can use to build a database management system on top of rather than being a DBMS in its own right. SQLite and HSQL are complete DBMS packages that will only meet your needs if an SQL engine is what you want.

      For example, if you're looking to build an Object Storage Database, SQLite and HSQL would both be terrible choices. But BDB would fit the bill perfectly.
      • Sort of... SQLite isn't daemonized, it is more of a db library and set of apps like berkeley is. But usage-wise, it is a full SQL DBMS and therefore competes with MySQL.
        • Just an FYI, daemonization (is that even a word?) has very little to do with Database Management Systems [wikipedia.org]. Daemonizing is simply a way of providing remote database services via a client/server architecture. Prior to the rise of common networking, DBMSes were regularly compiled into the program itself. Some mainframes even went as far as to compile the byte-level database access routines into every program. Which meant that a change in database schema would require that all programs be recompiled.

          <old-fogg
      • Well, technically BDB is a DBMS. It's not an RDBMS, because it lacks relational table management features, but it is most certainly a DBMS (and far more powerful than many of the most popular commercial DBMSes of just a few decades ago).

      • The benefits of BDB, with the addition of SQL. (Score:2, Insightful)

        by Anonymous Coward
        Actually, a subset of Java is quite heavily used in many mobile devices. This isn't the 1980s any more. A typical cell phone today is just as powerful as a decent PC from 1999 or 2000. And just like many other applications, data storage is a very real requirement.

        While you are correct regarding BDB being superior for storing certain types of data (eg. objects), in the past BDB has often been used in embedded applications to store relational data. It isn't well suited to such uses, without additional layers
      • we're discussing the Java version of BDB (which would be useless on the types of embedded platforms you're talking about)

        Why? This is exactly the sort of thing Java was invented for. Don't confuse whichever head of the Hydra you are familiar with with the body of the beast.

        KFG
        • This is exactly the sort of thing Java was invented for.

          Java wasn't invented to run on systems with no JVM and lack of dynamic library support. SQLite and BDB, however, will run on those systems.
          • Java wasn't invented to run on systems with no JVM and lack of dynamic library support.

            Well, D'oh! Cars weren't invented to run without wheels either. So if you want a car, you put wheels on it.

            SQLite and BDB, however, will run on those systems.

            Why do you believe those are the systems OP was talking about? There's nothing in "handheld" that implies that.

            Bias note: You'd probably have to shoot me before you could get me to use Java in an embedable system, or any other for that matter. I'm no Java fanboy defe
            • 1. He suggests SQLite instead of BDB. Which means that the system must have native APIs exposed.

              2. He mentions that BDB's "library-based archtecture" is a problem for said platforms. This denotes that he statically compiles SQLite on systems lacking dynamic libarary support.

              3. Nowhere does he mention Java capabilities, such as the type you'd use to power an engine like HSQL [hsqldb.org]. Instead he goes off into discussions about larger native engines like MySQL.

              Argue all you want, but he was referring to non-Java platf
              • Argue all you want

                Ok. :)

                1. He suggests SQLite instead of BDB.

                That's right, as an alternative, suggesting the use of BDB as an option in the systems he's talking about.

                2. He mentions that BDB's "library-based archtecture" is a problem for said platforms.

                No, he says that SQLite's library-based architecture is a plus in such systems.

                KFG
                • No, he says that SQLite's library-based architecture is a plus in such systems.

                  Ah, sorry. I misread that part. My point still holds, however. He's talking about native code, not Java.

                  That's right, as an alternative, suggesting the use of BDB as an option in the systems he's talking about.

                  He's comparing the native version of BDB. SQLite doesn't come in a Java version. And for J2ME platforms, you don't get the option of deploying a native binary. You either deploy all-Java, or you don't deploy at all. Which m
    • that's the exact reason why Oracle and IBM have open sourced BerkeleyDB and cloudscape(derby) respectively.

      Many developers use some sort of embeded / open source databases for prototyping and for small scale projects these DBs often end up being the production databases.

      The reasoning is we have written some triggers/stored procedures etc in PostgreSQL/MySQL etc, and now it's too much of a hasel to convert every thing to Oracle or DB2.

      This leads to a lot of loss in revenue for the big guys, especially from

      • Sorry, but you're totally mistaken about BerkeleyDB. Its just a database engine. i.e. you give it a key and value pair and it stores them. You give it the key and it retrieves the value. There is support for foreign keys and its completely transactional, but there is no SQL interface and no 'datatypes' whatsoever.

        It'd take some time to figure out what exactly is Oracle trying to do with it.
    • It depends on the person I suppose. I personally like MySQL better than postgresql as I find it easier to administer. (less crap on the file system, etc) I will look again. Perhaps postgresql has better jdbc support now than the last time I looked.

      I'm glad to see oracle releasing open source products.

    • Re:Many using SQLite instead. (Score:5, Informative)

      by ralph alpha ( 956305 ) on Wednesday May 24, 2006 @12:38PM (#15395172)
      Berkeley DB and SQLite don't even come close to filling the same niches. Berkeley DB is a highly optimized, generic, low-level tree-based database that can be used for a variety of purposes -- including providing the backing store for an SQL system. SQLite is an embeddable SQL parser wand extremely simplistic backing store. Berkeley DB is like a body without a head. SQLite is like a head without a body (or at least not much of one). You might want to note that "database" does not imply "SQL."

      • Re:Many using SQLite instead. (Score:4, Insightful)

        by hey! ( 33014 ) on Wednesday May 24, 2006 @01:40PM (#15395712) Homepage Journal
        I think you hit the nail on the had here.

        If you are a database person, as opposed to a programmer who needs some kind of persistent store, database implies the prsence of certain abstractions that BDB doesn't have. It's the abstractions that matter, because they implement a kind of data reusability. This is a big aspect of databases that programmers don't always appreciate, but if you remmber the early adoption days of the relational model (as I do), the idea of abstracting data from its application was a big thing. We had methods already after all for managing storage: hash tables, b trees, record pointers. We even had models (the hierarchical model). But relational databases allow you to create a model of your data that is abstracted from what you are doing with it.

        I'd go so far as to say that absracting data for reusability is what distinguishes a true database from other kinds of collections of data. Of course people do use words in a vague way, but this property definitely separates out what is unquestionably a datbase from what is only arguably a database.

        There is no question of BDB being a database management system. Collections of data in BDB format might arguably be databases depending on the effort the programmer went through, but usually they're just indexed files.

        Things like SQLLite that implement a generaly query and data manipulation language (e.g. including but not limited to SQL) is clearly a database management system, although it may not be a very good one.

        • Collections of data in BDB format might arguably be databases depending on the effort the programmer went through, but usually they're just indexed files.
          This is of course the way that MySQL started, a collection of BDB files binded together to appear on the outside as a collection of tables.
        • Finally!!

          A topic I actually know something about.

          There are several things wrong with your statement regarding the comparison of the two database. The first is that you assume that a database has to be relational in order to promote reusability. There can be many ways of promoting reusability including OODB and even the old ISAM model. BDB offers a very unique model of reusability and there are no constructs or foreign key relationships that are not possible to implement in BDB. Case in point MySQL can u

      • Re:Many using SQLite instead. (Score:1)

        by Anonymous Coward
        Enlighten us, ralph alpha: What is so simplistic about SQLite's backing store? A storage engine that puts a complete database in a single, relatively small, byte-order independent disk file with ACID transactions seems pretty advanced to me. What other storage engine has these features? And what features does SQLite's storage engine lack that you think are important?

    • If I was already using BDB or the like, what does SQLite really give me? I didn't need SQL if I was using BDB (and many things really don't need it at all).

      Larger applications are still going to need the power of a server based DB. There are a lot of choices like MySQL, PostgreSQL, and even Oracle when you can finally afford it. But I just don't see SQLite ever breaking through the "embedded library DB" ceiling to bump out MySQL. If Larry wants to destroy MySQL, then he should release a free open sourc

    • What we may even see is MySQL squeezed out of the market. I know many database developers who are starting to use PostgreSQL for their higher-end databases, and SQLite for the lower-end.

      I can understand porting to PostgreSQL for higher end stuff since PostgreSQL is more enterprise ready. I can see small home user sites using SQLite for there database. Even small apps can store configs among other things. On the other hand, For simplistic data storage but large amounts of it. (storing blogs, BBS (in toda
    • SQLite is even starting to take over from MySQL for many smaller websites. The overhead (both in terms of system resources and administration) can't be justified when using a server-based system, especially when SQLite does the job just fine.

      SQlite is so incredibly cool (for a database, of course; databases are intrinsically limited in coolness). It's tiny, it's easy to set up, it's portable, it's faster than MySQL for most operations, and it's not just open source, it's actually in the public domain. It

    • For a long time MySQL was notorious for letting you put February 30th into a datetime column. Does sqlite still happily permit "hello there" in an integer column? To me this negates the biggest reason to use an RDBMS - to get some checking of data integrity and foreign key constraints.

  • Sweet! (Score:4, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman@gmaYEATSil.com minus poet> on Wednesday May 24, 2006 @12:27PM (#15395078) Homepage Journal
    I'll have to see if they've finally added support for partial record retrivals. It used to be that this feature was only in the native code edition of BDB. It ended up being a showstopper for the Java version last time I tried to use it.
    • In case anyone else is interested in this, the JavaDocs [sleepycat.com] appear to make no mention of the previous limitations BDB imposed on partial records. Can anyone else confirm that BDB no longer loads the entire record to read partial records? If so, I have a few multi-gigabyte uses that this would be perfect for. :-)

      • Re:Sweet! (Score:3, Informative)

        by greybird ( 103532 )
        Hello, this is Mark Hayes, I'm one of the BDB Java Edition developers.

        There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.

        In both products, when you do a partial get/put of a record, the entire record must be loaded into the BDB cache. The only advantage of a partial get/put is that it reduces the
        • Hi Mark, thanks for taking the time to respond!

          There are no restrictions on accessing partial records in BDB Java Edition -- it is the same as the BDB C Edition in this respect. However, you may have a misunderstanding about the way partial records work in both products: neither product has a BLOB capability.

          Well that's not so good. I was under the impression that BDB was able to easily handle large binary chunks up to 4GBs in size. From this page [sleepycat.com]:

          Because both keys and values can be up to four gigabytes in

          • From your reply I'm not sure whether you're asking about a single record or the entire database.

            Each record is loaded into cache separately, and records are evicted when the cache is full according to an LRU algorithm. The total size of a database can therefore exceed the size of main memory and swap.

            But for a single record, in most cases it is completely loaded into cache, even when a partial get/put is performed. Even when using memory mapping with the BDB C Edition, in most cases the complete record is
        • Please do a quick reply to me when you reply to the other guy's question, so I can read it too :)
    • Warning: the word showstopper has a double meaning, but the one from Meriam Webster says the following:

      Main Entry: showstopper
      Pronunciation: -"stä-p&r
      Function: noun
      1 : an act, song, or performer that wins applause so prolonged as to interrupt a performance
      2 : something or someone exceptionally arresting or attractive

      Now, in IT it is mostly used to mean exactly the opposite, but it seems to me that introducing that meaning as well might let things get a bit confusing...

      That is: I suppose you weren'

  • Alternate link (Score:2, Informative)

    by Nerdfest ( 867930 )
    Since TFA seems to be slashdotted, here's an alternate. I'm assuming that version 3.0 (May 17th) is the new version.

    http://www.oracle.com/corporate/press/2006_may/ber keleydb-je-ga.html/ [oracle.com]
  • I thought it was funny that the article mentions "high-performance" and "Java" in the same sentence. IMHO, it's inappropriate to be writing "high-performance" applications in an interpreted language like Java. For the same amount of keystrokes, I can do it right the first time and write it in C and not have to worry about performance issues.

    • Re:"high-performance" Java? (Score:5, Insightful)

      by JebusIsLord ( 566856 ) on Wednesday May 24, 2006 @12:51PM (#15395276)
      oh for chrissakes don't turn this into a "java is slow" argument. 1996 called, and they want their discussion back.
      • You're missing the humor in his troll:

        > For the same amount of keystrokes, I can ... write it in C...

        Too funny.

      • i don't think that java is slow; i actually think that BDB JE is slow (at least the previous version). i had to use it to build a p2p search engine for a class and in most cases, it turned out to be our bottleneck. after large numbers of records i found that its whole commit-log thing was taking quite a long time; and it's nigh impossible to find others with the same problem and a solution (i found a guy with 8 million records that never got a response to his problem). personally, this was enough to make me
        • i don't think that java is slow; i actually think that BDB JE is slow (at least the previous version).

          The previous version loaded the entire record prior to reading/writing. This was a huge performance bottleneck if you were working with records above a kilobyte or two in size. In addition, the old version didn't make use of memory mapping like the C version did.

          I'm still trying to confirm the exact design of the new version, but I get the impression that they're using memory mapping in Java to give the sam
      • funny, in those benchmarks showing the speed of java, all I see is procedural code with primative data types. Start building objects, garbage collecting, and casting and my, my what a pig.
        • funny, in those benchmarks showing the speed of java, all I see is procedural code with primative data types. Start building objects, garbage collecting, and casting and my, my what a pig.

          So when you stick to basically writing code like you would in C, it's the same speed, but when you add more complicated, time-saving, features, it slows down? Wow, that's surprising. (</sarcasm>)
      • OK Java isn't slow. But some Java programmers are terrible and write bloated and slow programs.
    • For many (most?) things, java seems to be very close to C in speed. GUI interfaces although better are still lacking, but can generally be made usable. This aside, it's quite easy to interface to a java DB engine from a java application ... you don't need to deal with JNI, as would be the other option for an 'embedded' engine.

    • -1, Wrong (Score:5, Informative)

      by Jerk City Troll ( 661616 ) on Wednesday May 24, 2006 @01:11PM (#15395450) Homepage

      Java classes get compiled to native code with machine-specific optimizations at runtime. If you had done any research on the subject [google.com], you would find that Java out-performs other languages at times. Java is fast. This argument is over, so please can it.

      • Re:-1, Wrong (Score:3, Insightful)

        by Espectr0 ( 577637 )
        Java classes get compiled to native code with machine-specific optimizations at runtime. If you had done any research on the subject, you would find that Java out-performs other languages at times. Java is fast. This argument is over, so please can it.

        Java can be almost as fast a C code, and in some weird cases even more. The problem is that java requires a jvm, and loading the jvm plus having the garbage collector running means your program will start slower, and use more ram. Also the fact that it is not

        • Your comments are all valid, except I disagree with the last one. I find myself pleasantly surprised by the performance of Eclipse and applications based on its platform (in terms such as interface responsiveness). The other point I would make in contrary to yours is that Java is, these days at least, primarily intended for server applications. Most code written on the Java platform is never touched by the end user, but rather agents acting on behalf of the user. Hence interface response is rarely a con

        • Depends. (Score:2)

          by jd ( 1658 )
          If I compile the Java code with GCJ, then I shouldn't need a JVM. If someone would get around to building a processor-in-memory hardware Java implementation, you'd have a Java Physical Machine and again would not require a virtual machine. "Need", then, is a little strong. It would be more correct to say that - as of right now - most Java applications will indeed be run in a virtual machine, and require the components within that machine, but they are only run virtually because that is how it is traditional
      • Java classes get compiled to native code with machine-specific optimizations at runtime.

        That is quite irrelevant. Java as a language is slower than C (and both are slower than Fortran) because the language imposes constraints upon expression. Java's object-heavy type system and required garbage collection impose performance penalties which are not present in C. Java's lack of native pointers imposes performance penalties in some specific circumstances - mostly those where C can use pointer arithmatic for ma

  • Transfer from Berkeley to Postgres? (Score:3, Interesting)

    by Doc Ruby ( 173196 ) on Wednesday May 24, 2006 @01:05PM (#15395401) Homepage Journal
    Is there a wrapper for Postgres that lets me install PG+wrapper instead of BerkeleyDB for supporting apps that depend on BDB? Asterisk uses BDB, OpenLDAP uses BDB, and more. I'd rather wrap my existing Postgres (on which other apps depend) than refactor and port all the other apps off BDB. Even if I later port them from the BDB wrapper, it will be easier and more productive along the way.

    If there's no such wrapper, is there a way to use this BDB source to strip out everything below the BDB interfaces, install mapping to PG interfaces, then integrate with PG?
    • Shoot, that'd be great, or even for SQLite. My biggest problem with OpenLDAP is the BDB backend, which can be slow and get wedged. I've integrated a de-wedging script into my startup so that in the event of power failure the machine will still boot normally, but I think SQLite would fit nicely. I know OpenLDAP supports multiple backends, but I've not had much success in finding out how to migrate to another backend from BDB.
      • I asked Safehaus in several emails for details of their SW they claim replaces BDB with eg. Postgres, but I've never gotten a response.

        Asterisk uses BDB for configs and MySQL for CDRs and other persistent app data, and I integrate it with apps already using Postgres. Especially when I want to join across those multiple databases, it's a real pain. None of these apps are using any DB features unique to any of those RDBMS'es, though the interface calls are often annoyingly idiomatic. DB migration tools should

  • BDB on flash drives (Score:3, Insightful)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Wednesday May 24, 2006 @01:16PM (#15395493) Homepage
    We've been using the C version of BDB (via Guy Decoux's Ruby extension) as a data store for indi [getindi.com]; it's been working pretty well. It doesn't take up much space, either, so it's easy to fit it on a flash drive.

    Of course, on the backend [blogs.com] we use PostgreSQL. Rails + PostgreSQL is good stuff.
  • I have been impressed with Apache Derby [apache.org], the open source project that grew from IBM's donation of its Cloudscape database. An embeddable pure-Java implementation of a file-backed SQL database that supports many things you'd want in a DBMS, including transactions.

    Its optimizer is not the smartest in the world, but we use Derby and if you get your indexes right, you can usually get very good performance on very large datasets.

  • Interesting! The new BDB Java release does attempt to store objects directly. That's quite an advance in comparison to the awkward API of BDB 2.x.

    However BerkeleyDB JE is still years behind db4o [db4o.com]. The querying functionality of BDB is very rudimentary. It requires manual selection of indexes to be used, not really sophisiticated in comparison to db4o's Query-By-Example and Native Query concepts.

    It would be interesting to see BerkeleyDB and db4o race head to head in the Poleposition benchmark [polepos.org].



  • My company has been using Berkeley DB for quite some time and I must say that is indeed quite a good product. Sleepycat has great support and the tool itself is very stable. The java version is fairly new and doesn't have the features of the C version but works great as object storage.

    However it is not very user friendly and also not very programmer friendly. It doesn't have any single protocol like JDBC for access because you can literally program it to do anything. Also the documentation is very
    • What it makes up in difficulty it absolutely makes up for in terms of raw speed and portability it just can't be beat and we have benchmarked it vs. HSQL and MySQL running in ISAM mode.
      Out of curiosity, have you compared it to SQlite, perfomance-wise? The latter claims to be faster than MySQL in many cases, and is closer to BDB in terms of what it is intended to be used for, so it would seem an interesting comparison to make.
      • I would assume that SQLLite and HSQL would compare similarly. HSQL was faster than MySQL as well in the pole position benchmarks and in ours too but not entirely fair since it runs in memory.

        If you know how SQLLite compares to HSQL then let me know and you will have your answer to a certain extent.

        Our evaluation phase is over so I can't justify doing any tests on SQL Lite but I may try it if I ever get some spare time as I am sure I could just use the HSQL tests against SQLLite as well
  • Rex Wang, that's the name I would pick for my own personal super hero!
  • Now we can buy ndbm from Oracle.

    That is mostly what BerkeleyDB is.

    As for handheld scaners, I put tiny tcl http://tinytcl.sourceforge.net/ [sourceforge.net] on mine. I am sure calling ndbm would be easy. execpt the handheld was a DOS_5. I don't have the time to go find all the junk like 'C' compilers for that. The next version of the scanned will run Linux and all will be well.

  • The past BDB releases suffered from being unable to read older/newer .db files sometimes. This is why various software packages (like Evolution, for example) bundle their own versions.

    If Oracle solves this problem, I'll be a very happy camper...

Slashdot Top Deals

I've noticed several design suggestions in your code.

Close