[development] One-to-one tables considered harmful

Larry Garfield larry at garfieldtech.com
Sun Jun 3 22:47:14 UTC 2007


On Sunday 03 June 2007, David Strauss wrote:
> == What's bad about the current approach ==

*snip*

> First, I'd like to adopt a development philosophy on the Drupal project:
> screw scalability if the database running Drupal doesn't support
> row-level locking. Sites using only table-level locks are doomed to
> scale poorly anyway because of the over-aggressive locking. We won't be
> able to prevent that disaster with the tiny improvements in lock
> granularity afforded by splitting tables into one-to-one table pairs.

*snip*

> If we rely on the query cache, we're also being hypocrites with our
> stance on the first reason because many low-end hosts don't run the
> query cache. Either we care about scalability on low-end configurations
> or we don't. I'm suggesting "don't," but if people truly do want to care
> about low-end scalability, we can't use the query cache argument.

Scalability on "low-end" hosts is very important for a number of reasons.  

1) Most sites run on them.  How many web sites run on a shared host vs. a 
dedicated farm?  I'd venture to say most sites, Drupal or otherwise, run on a 
shared host.  That means we can't ignore that use case.

2) That's where people start.  If Drupal is slow and crappy unless you're 
using InnoDB, a dedicated server, and an opcode cache, then no one is going 
to give it a second thought.  Most people new to Drupal will try it out first 
in a shared host, or a private dev box that no one bothered to optimize.  If 
Drupal sucks in that case, then those people will never bother installing it 
on high-end servers with carefully-tuned databases.

True story: When I was first looking for a framework or CMS, I tried Typo3 
before I tried Drupal.  I never actually got it installed because at the time 
just running the installer died on my system (a stock Debian Sid PHP 
configuration with no customization, at least at the time) because it hit the 
default PHP memory limit.  Not knowing then what I do now about PHP 
configuration and optimization, my response was "wtf?  What a memory hog, it 
can't even install on a default setup!  Screw this, I'm trying Drupal."  

Now, I can certainly accept the argument that we shouldn't try to bend over 
backward to get every last bit of performance out of MyISAM.  There comes a 
point where a site really does need to have a dedicated box with hand-tuned 
databases.  But that doesn't mean "don't care" about smaller hosts.  The 
longer those small hosts hold out, the less expensive it is to run Drupal and 
the more people use it.  (The menu handler split / split-mode-redux stuff I'm 
doing is aimed primarily at shared hosts, but will have an impact on larger 
sites, too.)

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list