Berkeley DB -- anyone care?
Hello,
Some of you may remember that a while back I was working on a wrapper
for the Berkeley DB library (www.sleepycat.com). I'm still working on
it.
When I started working on it, I thought I would first make a version
that would mirror the API & functionality of EDS (since Berkeley also
stores things in key/data pairs -- it is a very similar system) and
submit it to the archive as a super high-speed, more scalable version of
EDS. I did that part almost to completion, but while I was tweaking the
error-reporting system and debugging, I also starting adding some of the
extra features that Berkeley offers that I wanted to use as part of the
personal project that motivated me to wrap it in the first place. And
then I actually starting building my own database, adding more features,
debugging, rethinking the API (I made an API on top of the native
Berkeley API, which is fairly low-level), etc.
Anyway, I've got quite an accomplished little system now, not quite
ready for prime time, but I thought maybe it was about time I finished
up the EDS clone version and at least released that. That is, if anyone
is interested.
The lite, EDS version would:
-- only work for Windows, because the Berkeley lib is a Windows .dll
(although the source is cross-platform -- if someone wants to try a
Linux version, it may be possible)
-- share the exact same functionality and API of EDS with the following
exceptions: locking is currently ignored, and there is no
"db_compress()" function. I use "bdb_" instead of "db_" in front of all
the functions. The key & data items can be absolutely any string of
bytes, as in EDS.
-- any existing .edb database could be converted to a .bdb database in
just a few minutes, and any existing EDS-based program could be
converted to a Berkeley DB-based program with a simple search and
replace "db_" -> "bdb_" and a different include file, of course.
(Unless you depend on locking on db_compress()ing -- in any case, quick
conversion.) You also have add a line to manually set a memory cache
size for your database environment -- this allows the wrapper to turn
off system buffering and gives a major performance boost.
-- would go a hell of a lot faster than EDS, except possibly for very
small db's.
-- scale much better than EDS, files hundreds of MB large will see a
slight slow down in update/insert speed (but MUCH less than EDS), and
hardly any degradation in retrieval speed.
-- have a couple of not strictly EDS-compatible options that would allow
it to go even faster, namely turning off support for logical record
numbers (just access everything by key) & turning off "Euphorian-style"
keys -- if you always use 1-dimensional character strings as your keys
then the library can use its default sorting function instead of a
Euphorian compare callback function in the wrapper.
-- the library is open-source, so anything you make publicly available
would be bound by the Berkeley license, which means your program source
must be availble. You can buy a commercial license for making
commercial programs.
So, anyone interested?
|
Not Categorized, Please Help
|
|
