On Feb 26, 2010, at 8:02 PM, Yaron Minsky wrote: On Fri, Feb 26, 2010 at 6:56 PM, Jason Harris <address@hidden> wrote:
On Fri, Feb 26, 2010 at 09:58:17PM +0000, Kim Minh Kaplan wrote:
> Jeff Johnson writes:
> > From the 3 deadlocks I've seen, I'd guess that any moderately large
> > (>500 keys) is likely to encounter a partition tree deadlock if
> > DB_INIT_LOCK is enabled.
Fortunately, I don't have these problems with pks even though mine
still uses BDB 2.x. I know Hironobu (OpenPKSD) and Jonathan (onak)
report massive speed slowdowns with SQL-everything (that they used),
but I don't recall if they tried sqlite3. I believe that BDB is a
solid DB with proper use of the API, having seen it in pks, but am
very hopeful that SKS will do quite well when converted to sqlite3.
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.
I've used both sqlite3 and Berkeley DB, ACID behavior doesn't come for free with any implementation, and its ACID which is needed for ~3M keys.
Here's one datapoint from RPM which has used both BDB and Sqlite3: sqlite3 (after tuning) was 2.4 times slower than BDB (without tuning). The straightforward implementation was 14x slower for database intensive operations.
You are correct "mediocre" compared to the rest of SKS (which is quite nicely done).
Can you write down the SQL schema currently used in SKS? Every SQL implementation starts with the schema ...
73 de Jeff
|