On Tue, Apr 18, 2006 at 01:52:44PM +0100, John Buckman wrote: > >Incidentally, I know next nothing about BerkelyDB, but why are you > >using it in the first place? Are you forced to because some 3rd party
> BerkeleyDB is (one of) the underlying databases to MySQL, and is > psychotically fast, much faster than SQL is, and the web site I'm > writing (a book sharing site) needs high scalability. I also run > www.magnatune.com, which uses MySQL, and run against scalability > problems all the time. That sounds like the wrong answer. Obviously you know much more about the specific problem you're trying to solve then I do, but assuming that what you've conveyed in passing so far is representative of the whole picture (even though in reality it may not be!), I'd suggest that you revisit your design and make sure your assumptions and analysis are right. Last I heard, MySQL is known quite specifically for having relatively poor scalability. But if you want better scalability, you'd be looking at PostgreSQL, Oracle, or etc. Choosing BerkeleyDB for its *scalability* vs. MySQL seems... odd. They are very different tools. Btw, from what I hear, BerkeleyDB is an excellent implementation but it just gives you key/value lookups. Its advantage as a low-level database engine is that it supports fine-grained locking. SQLite's low-level engine is reputedly smaller, simpler, and possibly faster (I'm not sure), but its locking is much coarser. So depending on what sort of vehicle you're building, one engine or the other may be more suitable. And of course, SQLite ships with a higher-level relational database wrapped around that engine, and is primarily intended to be used that way. I've never really much used either BerkeleyDB or SQLite, but if I'm prototyping an application, rather than building the specialized low level guts of some other tool, if I can help it I'm going to go with "relational database" rather than mere "key/value pairs". In past projects, I've used solely nsv key/value pairs for things that I REALLY wanted a small in-memory RDBMS for - painful. Now that I'm aware of more powerful, higher level tools, I'd start with those instead. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
