Re: Berkeley DB -- anyone care?
On 4 Jan 2003, at 15:20, Andy Serpa wrote:
>
> 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.
I remember!
> 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.
Color me "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.
Does that mean the Berkley db will store strings in Eu form, with 32bits per
ascii character?
> 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.
Can it still store nested sequences as data?
> -- 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?
Me.
Kat
|
Not Categorized, Please Help
|
|
