sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)


From: Jeff Johnson
Subject: Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)
Date: Sat, 27 Feb 2010 13:08:53 -0500


On Feb 27, 2010, at 1:01 PM, Jeff Johnson wrote:


On Feb 27, 2010, at 5:20 AM, Marco Nenciarini wrote:

Yaron Minsky ha scritto:

I'm a big fan of sqlite, and Markus Mottl has written an excellent
binding for the library --- far better than the mediocre binding I wrote
for bdb.  I think porting sks to use sqlite instead of bdb would be
great, although I would think some thinking about migration would be in
order.


Maybe it worth to take a look to Tokyo Cabinet
http://1978th.net/tokyocabinet/


Tokyo Cabinet is certainly well marketed.

There are several other non-databases around that
could be used as well:

        1) BTRFS (or ZFS but lets not go there) snapshots
                The COW snapshot with a "last known good"
                timestamp identifier has a certain KISSy appeal.

                One would hope that a loopback mount of
                a BTRFS file system, possibly with BTRFS
                in userland, would be feasible.

        2) Stasis (http://www.cs.berkeley.edu/~sears/stasis/)
                I came very close (in RPM) to dumping Berkeley DB
                and using Stasis instead because of the performance.

                OTOH, Berkeley DB is a "conservative" choice and
                also has all the tools needed to achieve ACID.

                With Stasis, there would be additional tool
                and documentation work, likely not impossibly
                hard with the extremely simple schema needed
                by SKS key servers.


3) sqlite3 with virtual tables (http://www.sqlite.org/cvstrac/wiki?p=VirtualTables )

        If one wanted to just leap to sqlite3 development wedged
        on top of existing Berkeley DB (or other) implementaions,
        then writing a virtual table modules is likely a weekend's
        work.

73 de Jeff
        




reply via email to

[Prev in Thread] Current Thread [Next in Thread]