l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2003 Apr 23 23:56

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Need your help in recovering database.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Need your help in recovering database.



On Wed, 23 Apr 2003, Tim Riley wrote:

> 
> 
> Jeff Newmiller wrote:

[...]

> > You don't seem to be familiar with InnoDB tables, Tim... they offer some
> > useful features, but they aren't structured like normal MySQL files on
> > disk. OTOH, my only experience with them has been setting them up a couple
> > of times... I haven't used them for large databases, and am just barely
> > aware of their configuration options.
> 
> You're right--I dunno about InnoDB. I hope Mysql doesn't fall into the feature
> trap.

They haven't lost their old data storage formats... just added some new
ones.

> The robustness and speed of version 3.22 is due to it's simplicity. (I have
> a client running a database with over 50 tables. The largest table has over 40
> million records, and its datafile size is over 4G, and the index file is over 2G.)

You clearly have enabled large file support in your kernel and an
appropriately compiled mysqld.  The filesize limitation I mentioned is
from the OS... not InnoDB.

> Mysql's simplicity is due to having 3 files per table--definition, data, and index--
> and letting the operating system do the operating system stuff.

I don't see why 3 files is magic... one per table could be "simpler" to
administer, and one file per index could be simpler to program (and less
likely to have bugs).

I do think I see where the KISS principle has merit, but there are also
valid reasons for taking the "data lump" approach (OS independence being
one).  I happen to like the "per database" file architecture, since you
can allocate tables to files individually or in groups, which makes
offline archiving easier.

> On the other hand, Oracle was written when operating system resources were
> limited, and therefore Oracle does a lot of operating system stuff. Oracle can be very
> stable if its memory and disk resources are monitored
> and extended as needed. However, this feature-rich database engine is bloated,
> slower, and accident prone.
> 
> (Just food for thought.)

Yep.  Some people need Corvettes, and other people need Cadillacs.  If
MySQL wants to have something for everyone I won't complain.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.