Slashdot Mirror


Oracle Unveils New Open Source BerkeleyDB Release

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

8 of 103 comments (clear)

  1. Re:"high-performance" Java? by JebusIsLord · · Score: 5, Insightful

    oh for chrissakes don't turn this into a "java is slow" argument. 1996 called, and they want their discussion back.

    --
    Jeremy
  2. The benefits of BDB, with the addition of SQL. by Anonymous Coward · · Score: 2, Insightful

    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 on top, as you mention.

    However, SQLite offers the small footprint of BDB, along with the efficient single-file persistence, with the additional SQL support. Those who have been using BDB for a rather bastardized method of storing relational data can now instead use a fairly full-featured SQL implementation. Best of all, their overhead is barely increased, if not outright decreased.

    BDB has its role, there's no doubt about that. But its necessity is being eaten away rapidly by competitors (eg. SQLite) and vastly improved embedded/mobile hardware.

  3. BDB on flash drives by tcopeland · · Score: 2, Insightful

    We've been using the C version of BDB (via Guy Decoux's Ruby extension) as a data store for indi; 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 we use PostgreSQL. Rails + PostgreSQL is good stuff.

  4. Re:Many using SQLite instead. by mritunjai · · Score: 2, Insightful

    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.

    --
    - mritunjai
  5. Re:-1, Wrong by Espectr0 · · Score: 2, Insightful

    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 easy to write a good UI while keeping threading under consideration makes your program look even slower.

    Java may be "fast enough" but your typical java app needs bigger system requirements than it would need in other languages.

    So in theory, java is as fast as C, but in practice it is probably slower, especially for desktop applications.

  6. Re:Many using SQLite instead. by hey! · · Score: 3, Insightful

    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.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  7. Re:"high-performance" Java? by geoff+lane · · Score: 2, Insightful

    OK Java isn't slow. But some Java programmers are terrible and write bloated and slow programs.

  8. Re:"high-performance" Java? by csnydermvpsoft · · Score: 2, Insightful

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