What do you think of Berkeley DB Java Editions performance capabilities? It uses NIO [new input/output], which should have a considerable effect on performance due to the way memory is accessed. The NIO packages are new APIs that allow Java to have the power of C where IO is concerned. These APIs are new in the 1.4 JDK and make Java-based servers much more effective. Furthermore, a binding API makes mapping objects to records very intuitive while avoiding the overheads in serialization. Other implementations often leave this up to users, who often use serialization and wind up paying for it with a massive performance hit.What were you using to manipulate B-tree databases before this pure-Java play? Ive hand-rolled a couple of databases I had in an RDBMS [relational DBMS]. Some were to just play with; others I knew the schema would not change and so decided that they could be optimized using nonrelational B-tree-based storage. Some databases, like those used for LDAP servers, are unique. LDAPd, which I wrote years ago, used Berkeley DB C edition and its JNI [Java Native Interface]. It was way slower than using the C version directly due to copy overheads in JNI. So, I kind of gave up on it. Then, when JE appeared, I started planning an overhaul using JE instead. Im still at the planning phase and intend to retrofit the Eve Directory Server [LDAPd 2] with JE. In this case, the speed advantage, ironically, comes from not going through JNI. Next page: Why Berkeley DB wont compete with the big databases.
For more on binding APIs, check out Microsofts Microsoft Developer Network site.