[PLUG] Database layout vs. performance

Brian Horan bhoran at hexdev.com
Fri May 17 22:28:12 UTC 2002


Interesting. It seems to me that instead of depending upon (as you said) 'el 
cheapo' RAID Controllers you may want to go with using the disks themselves...
(a box is only as strong as the weakest joint)  If you are to do this, I 
would definitely recommend using EXT3, I have never used ReiserFS knowingly 
but I have become a definite believer in EXT3's Journaling stuff...

>From the InnoDB documentation, its good to see that MySQL is using 
transactions, and has better dump capabilities and recoverability.  This with 
the goodies from EXT3 will definitely be a help.

With a small RAID0 array, I don't think you'll get the performance 
improvement/reliability you're looking for.

As far as backups, logs, etc...Depending on what kind of space you need for 
pertinent data, you might want to consider the following:

scenario #1::
first 2 disks: database devices MIRRORED (active/online/whatever you want to 
call them)
third disk: DB dump archive disk (cron-jobbie-job dump and possibly gzip)
fourth disk: add'l db disk for testing/recovering dumps....

scenario #2::
[if data is super-important -- kinda wasteful]
software raid 5 (you need 3 of the disks -- fourth for dumps, etc)

un-scenario #3::
Have you considered Sybase?
(not trying to start a flame war, but I'm personally a Sybase junkie...and it 
works VERY well on linux.

Also, if response time via a web server is an issue, rather than FCGI, (which 
I have seen get sick many times onder a heavy load) have you considered PHP?
similar to perl, no additional process creation, and it's buzzword 
compliant....syntax is also similar to perl in some regards.


On Friday 17 May 2002 05:42 pm, you wrote:
> Hello Brian,
> Thanks for your response.
> This MySQL with InnoDB tables database is intended for collecting real
> time test/process data from the running equipment log files and
> providing raw data for data analysis software to display results over
> the FCGI web interface. Web server, data analysis software and
> database should be residing on the same box to reduce network traffic.
>
> We have two el'cheapo SideBus soft Raid0 EIDE controllers and four
> ATA100 EIDE 40GB hard drives. Sorry we can't afford SCSI. Budget is
> tight.
>
> There are two possible solutions:
> We can set up two Raid0 arrays and mirror one another simultaneously
> or syncronizing them once a day.
> Or we can just leave these hard drives where they are and spread data
> directories across all four of them.
>
> My major question is which method is better for best performance and
> what FS (EXT2, EXT3, ReiserFS, JFS) is better to use for this task.
>
> Thank you in advance for any thoughts or sources of information.
> Alex
>
>
>
>
> -------------------
>
> > RAID 1 might be good, but if it is at all possible, you should try a
>
> RAID 5
>
> > (If you have at least a third disk).  RAID 0 has no real fault
>
> tolerance.
>
> > Which database is this for? can you use some sort of LVM? or will
>
> you be
>
> > using segments? ALSO...You are putting your logs on separate disk
>
> devices,
>
> > right?
> >
> > Alot of the decision making for this is also decided upon by what
>
> the
>
> > database's main use is going to be.  OLTP? Generic Data Storage?
> >
> > With small Sybase installs, a long chain of single disks is very
>
> fast, with
>
> > the backup server using DIFFERENT disk devices....for pete's sake..
> >
> > what kind of uptime/IO/other requirements does this proposed
>
> database need?
>
> > On Friday 17 May 2002 05:01 pm, you wrote:
> > > Hello Linux folkz,
> > > I need your advise on SQL DB layout.
> > > What is better in terms of performance and speed to install
>
> database
>
> > > on a single RAID0-1 array or split data directories between
>
> separate
>
> > > single hard drives?
> > > Thank you in advance for any ideas or recommendations.
> > > Alex
> > >
> > > _______________________________________________
> > > PLUG mailing list
> > > PLUG at lists.pdxlinux.org
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
> > --
> > Brian Horan
> > bhoran at hexdev.com
> >
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug

-- 
Brian Horan
bhoran at hexdev.com




More information about the PLUG mailing list