Date: Fri, 10 Jul 1998 17:12:41 -0400 From: Steven Yang <syang@directhit.com> To: "'Andras Tudos - Computronic, C3'" <andras.tudos@computronic.hu> Cc: "'freebsd-database@freebsd.org'" <freebsd-database@FreeBSD.ORG> Subject: RE: Highly reliable database package Message-ID: <839A86AB6CE4D111A52200104B938D435B7F@MOE>
next in thread | raw e-mail | index | archive | help
Hi, my company has been evaluating both GDBM and db. Both are freely available. So how many records will you have in your database? 65,000? millions? If you have 65,000 records (1 per user), and you need to update them frequently, I'd say try GDBM. If you have more than 100,000 records, I'd say try db. The reason is that insertions and updates for GDBM are decently fast for relatively small numbers of records, but the performance degrades rapidly once you go beyond 100,000 records. db achieves consistent performance for large numbers of records, but for small numbers, GDBM happens to be faster. Here's a quick summary of pros and cons that we have discovered: GDBM: Pros - index is relatively inexpensive, definitely good for updates or appends for ~50,000 records or less. We did our tests where the size of the records were 5K, and also when they were a few bytes. Either way, the insertion speed was the same. The bottleneck appears to be its indexing ability. It is very fast for read requests. Cons - if your keys are too similar, you might get a fatal error for large numbers of records (like > 112000). If your keys are pretty different, don't worry. db: Pros - seems to scale better than GDBM if you use btrees (definitely don't do db hash tables). Insertion speed seems constant even when you have more than 100,000 records. So for large indexes, db is MUCH BETTER than GDBM. db is also really fast for read requests. Cons - insertion speed for small numbers of records is significantly slower than GDBM. /////// NOTE///////// These database packages do not use SQL. They are simply lookup tables. If you need a relational database or must use SQL for some reason, try mysql. I've never used mysql, so I actually don't know anything specific about it. > -----Original Message----- > From: Andras Tudos - Computronic, C3 > [SMTP:andras.tudos@computronic.hu] > Sent: Friday, July 10, 1998 8:42 AM > To: freebsd-isp@FreeBSD.ORG; freebsd-database@FreeBSD.ORG > Subject: Highly reliable database package > > Hi, > > we need recommendations of a highly reliable database package having a > FreeBSD client library (preferably running on FreeBSD) , which can > serve a > simple database with *a lot of concurrent queries* without crashing > every > day. We are using Postgres at the moment, but can't stay with it any > more. > Even the developers acknowledge this being a problem. > > The application: user database of a large mail server (currently > ~65000 > users). > > Andras Tudos > C3, Budapest > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-database" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-database" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?839A86AB6CE4D111A52200104B938D435B7F>