Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1

[Chris Nolan]

Hi,

As I have said before, I'm not Heikki, but I'm such a massive geek I'm 
likely to have one or two useful bits of info for you. :-)

1. You'd have a rough time getting indexes and tables to be seperated 
out, unless you were willing to set up your various symlinks/hardlinks
by hand. Even then, you may be inviting problems. Additionally, no date 
has been announced for FULLTEXT indexing on InnoDB tables, and
Heikki considers it a low priority by the looks of things (not having a 
go at the god of multiversioned DBs, just making a possibly incorrect
observation).

2. I personally use ReiserFS for all of my stuff, most of which is based 
upon InnoDB. One thing you have to remember is that InnoDB
treats the space inside the tablespace as a Berkeley Fast 
Filesystem-style space, using the underlaying filesystem minimally. To quote
the manuals, raw partition usage can speed up IO on a number of UNIXes 
(and Windows too seemingly). Regarding backup, you'd
need to use mysqldump or InnoDB Hot Backup to backup a raw-partition 
setup. This isn't a bad thing though - I use mysqldump and
can get a consistant snapshot of a 12 GB DB without problems while the 
thing is running.

Hope this helps!

Regards,

Chris

Jon Hancock wrote:

Heikki,
I have two questions in regards to the tablespace changes:
1 - You mention being able to store indexes in a seperate tablespace.  How
far off is this for MySQL to implement?  I would like to see FULLTEXT
indexes stored in seperate tablspace (seperate RAID channel) so the two
features (InnoDB FULLTEXT) would both need to be available.
2 - Is there any value to using Journaled file systems with the InnoDB
tablespaces?  A new system I'm putting together will have seperate drives
for only InnoDB data.  Is a Journaled file system extra overhead?  If so, is
Raw significantly more efficient?  How does this choice effect backup
soultion?
thanks, Jon

 

----- Original Message ----- 
From: "Heikki Tuuri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 9:55 PM
Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1

   

Eduardo,

to make the user interface simple, I decided to take the table per file
approach. Each .ibd file is internally a 'tablespace'.
The simple approach I chose is similar to how MyISAM now works. I
     

thought
 

it
   

would be nice for current MySQL users.

In Oracle, one can store several tables into a single named tablespace,
     

and
   

can also split indexes and data of a single table to separate
     

tablespaces.
 

Nothing prevents adding those features to InnoDB, too. It just requires
     

new
   

syntax in CREATE TABLE to specify these options.

Best regards,

Heikki
Innobase Oy
http://www.innodb.com
InnoDB - transactions, row level locking, and foreign keys for MySQL
InnoDB Hot Backup - hot backup tool for InnoDB which also backs up
     

MyISAM
 

tables

..........................
From: "Eduardo D Piovesam" ([EMAIL PROTECTED])
Subject: Re: MySQL/InnoDB-4.0.16 is released + sneak peek of 4.1.1
View this article only
Newsgroups: mailing.database.myodbc
Date: 2003-10-23 14:43:28 PST
(Sorry for the last email, it's not complete).

Hello Heikki,

Sorry, but I didn't understand the concept of tablespace applied. It's
different from Oracle, right?
AFAIK, tablespace is utilized to logically group "tables" into one (or
     

more)
   

files.

And to group "indexes" into another files...

But you said that the each table (with its indexes) will be in one
     

file...
 

is there an reason? Is it better than "split" tables and indexes?

Thank you.

Eduardo

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
     

http://lists.mysql.com/[EMAIL PROTECTED]
   

     



 



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]