On Mon, May 22, 2000 at 03:46:39PM +0800, Michael Robinson wrote:
>
> MySQL is extremely well suited for it: the data is essentially "read-only"
> so transactions, locking, etc., are not an issue, the per-row overhead is
> extremely small (important when you have hundreds of millions of short
> records), and the speed, especially with prudent indexing and datatype
> selection, is scorching fast.
People keep claiming that applications that are essentially "read-only"
don't need transactions. I'll agree in the limit, that truly read only
databases don't, but I think a lot of people might be surprised at how
little writing you need before you get into trouble.
Case in point: Mozilla uses a MySQL db to back up their Bugzilla
bugtracking system. Very popular site, _lots_ of people reading, not
a lot writing (from a developer's point of view, never enough...) The
problem they've seen is that if a reader someone fires off a "stupid"
query, like one that returns essentially every bug in the system, and
a developer then tries to update the status of a bug, every single
concurrent access to the system has to wait for the stupid query to
finish. Why? Because the writer attempts to aquire an exclusive lock,
and blocks, waiting for the stupid query. Everyone else blocks, waiting
for the writer's lock.
How many writer's does it take for this to happen? One. I'd call that
an "essentially read-only" system. A note, this is not a made up,
theoretical example. We're talking real world here.
Ross
P.S. here's the entry in bugzilla about this problem:
http://bugzilla.mozilla.org/show_bug.cgi?id=27146
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
