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

Re: simple database?



On Tue, Mar 26, 2002 at 11:25:48AM -0600, dman wrote:
> On Mon, Mar 25, 2002 at 04:26:16PM -0800, Petro wrote:
> | On Mon, Mar 25, 2002 at 02:44:25PM -0800, Tom Cook wrote:
> | > multi-user capabilities, or real scalability.  Also PostgreSQL is a
> |     What is "real" scalability? I've used Mysql on tiny machines
> |     (Tadpole laptop) to dual processor x86 boxen with 2 gig of memory,
> |     and 6 way Sun e4500s with 4 gig of memory. Database sizes from
> |     trivial to over 150G of tables on a single machine. 
> I couldn't find it recently when I googled, but a while back I read
> some articles written by someone at sourceforge.  He was describing
> the comparision he did of several RDBMSes in the deployment of
> sourceforge.  He found that for small dbs and light load that mysql
> yielded faster responses.  However (at the time at least) its locking
> was table-level.  This means that if someone is updating a row in a
> table, then no one else can read any other row in that table.
> PostgreSQL had more overhead on the small side of things, but for the
> many thousands of hits per minute SF had it performed much better.
> postgres has row-level locking.  In the scenario above the users
> can still read their rows while the other user is modifying his.  In
> an environment where web pages are generated from multiple queries
> that merge several tables the differences were very significant.  The
> article provided much more detail, but that's mainly what I remember
> from the top of my head.  Of course, as with any case study, the
> evidence is anecdotal.

    Ah. I read that one as well. 

    The thing is, it *highly* depends on your database design, and
    intended use. If your database is read more than written, this is of
    (depending on the weight) minor to non-existent concern. Also
    "clever" table design can get around this. 

-- 
Share and Enjoy. 


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: