On Tue, 2006-01-10 at 18:48 +0800, Orlando Andico wrote: > On 1/10/06, Dean Michael C. Berris <[EMAIL PROTECTED]> wrote: > So in this case, I'm not surprised if BerkeleyDB conked out on > any > application. I've been burned before, and now I'm, moving away > from > BerkeleyDB -- far far away. > > funny that sleepycat touts BDB as in use inside the iron of big > companies like lucent and cisco. > also remember that mysql uses BDB for one of its table types. >
Yeah, they use it. And I use it too. I just don't like how it works -- but much like how I don't like MS Windows, I just can't ignore it. > > "it ain't libdb, it's what's between the keyboard and the chair" :) > Actually, it's a problem inherent with BDB itself -- you don't have reliable key-based indexing, and other stuff you would need from a modern (albeit embedded) persistence solution. These things that need to be there aren't so you spend more time building code around it to make it happen. I know it, you know it, and even the BDB developers know it. Of course, anybody who's used BDB would know this, but if you have at least 3 processes accessing (read: reading and modifying) the database backend, then you run into a performance problem -- if there should be only 1 process actually reading to and writing to the file-backed BDB database, then how about the N other processes waiting? Then you have to wait for context switches (which are heavy on any platform) and the unnecessary overhead you encounter doesn't allow you to scale or use it in a "heavy transaction" setting. That said, then you need the right tool for the right job -- and in this case, if you're planning on using BDB in a high transaction environment/solution, then you might be looking at the wrong tool. Better go PostGreSQL or MySQL. > that said, cross-process locking IS tricky business: these guys > (lucent, cisco, mysql..) are happy with BDB because they know how to > handle this. it could be something as simple as a simple flock() file > so that only one of your processes is writing to the BDB file at a > time. Sometimes this "simple flock()" isn't portable, isn't reliable, and isn't usually enough to ensure that your mission critical app will work right. Of course, you're being bound by BDB in itself, which means if you find yourself doing an flock() on a lot of processes, then you might be thinking to yourself "there must be a better way.". > > but life is short.. better to use MySQL. It might be the right way to go, but MySQL is too big even for the simple "object persistence" and "Inter-Process Communication" or "Message Passing" needs. If you just want to be able to make your communications between two processes persistent, using MySQL is like using a Jumbo jet to deliver a page from one office to another -- in the same building. BerkeleyDB looks like a good measure for it, but then if you consider the headaches that come with object serialization between two processes and the headache that resource locking and inter-process synchronization are to implement "from scratch", then it just becomes a little harder than usual. But then if I were to do it over again, I'd design the application/solution so that almost everything resides in one address space (threading instead of multi-process invocations) -- and then just export the DbEnv to the global address space and be done with it (and feel a wee bit more secure with the integrity of the backing store in this setting). But still, the question begs to be asked -- if there is more than one instance of the application accessing that same backing store (BDB in this case) ? Then you still need to put extra measure to make sure that you use flock() and friends when synchronizing, and stuff like that you wanted to avoid. So yeah, life is short -- stay away from BDB if you think you might encounter the problems just cited here. Otherwise, for the usual persistence solution, BerkeleyDB should suffice. That is, aside from PEBKAC there's always YMMV. Just my $0.02 again. -- Dean Michael C. Berris Mobile +639287291459 URL http://mikhailberis.blogspot.com YMID: mikhailberis _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
