Open Source for mission-critical systems (slightly OT)

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Fri Jun 3 12:54:50 UTC 2005


On Thu, Jun 02, 2005 at 05:23:07PM -0400, Andrew Hammond wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lennart Sorensen wrote:
> > On Thu, Jun 02, 2005 at 02:15:40PM -0400, Andrew Hammond wrote:
> > 
> >>That requires synchronous replication. Oracle RAC for example. Unless
> >>you're willing to allow for committed transactions to be lost on
> >>failover. To do RAC properly, you better forget running it on some pissy
> >>little quad Xeon box.
> > 
> > As far as I recall the database server that futurephoto moved to
> > eventually (shortly after I left the company that build the site), was a
> > pair of fridge size sun's.  I think they might have been ultra450's or
> 
> The 450's are about the size of a beer fridge on it's back. But they
> weigh more. 4500's were actually a little bit smaller boxes. Or at least
> the look smaller. I always thought that was kind of strange.
> 
> > something like that.  And yes they were running Oracle with synchornous
> > replication.  Porting our SQL was fairly trivial since we did all the
> > logic at the application level and only used the database for storage and
> > searching.  Perfectly standard SQL.
> 
> This is the kind of crap design that comes from junior developers who
> actually believe that database independance is a good thing. It's as
> moronic as driving a car in only first gear all the time, so you can
> avoid the learning curve of a new clutch when you change cars. And then
> being proud of it while complaining that your car won't go fast enough
> and tends to burn out it's engine.

In many cases all you need a database to do is store data in a way that
makes it fast to find again when you need it.  Automatic triggers and
functions and data manipulation are not always required.  Setting up the
right indexes and trying to create your queries in the right order for
your database to make things go fast does help a lot too.  I am sure the
stuff we did would not have run on MySQL at the time since we were using
a lot of the more advanced SQL queries that it didn't support (at least
at the time).  Some of them were even fairly new in postgres.  Sometimes
treating a database as a very clever filesystem and nothing more is a
good idea.  Sometimes you do something more advanced where you want to
enforce table relations and data integrity, in which case you have to
start using more features, and portability takes a hit.  We wanted to be
portable to another database at the time, and had no real need to put
the logic in the database so we avoided it.

I do know futureshop's prior provider of photo storage died because they
couldn't scale past a few thousand users, and they had put all the logic
into a MS SQL server.  They were running on an 8 cpu intel server before
they finally died out just trying to get the database to handle the
requests fast enough.  It is much easier to put the logic into the
scripts of the web server and let the database just handle queries if
you want to be able to scale to a lot of users without using a database
that can in fact run multiple servers at a time sharing the load. If
postgres could have done that at the time, we would probably have used
it that way for some things.

As for the junior developer thing, well I think you are wrong.  I think
designing things for one database when you don't have to is like making
tires that only work on one brand of car.  Might save you a little time
in some cases and work slightly better, but you sure limit your
potential users in many cases.

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list