Thanks a lot for the quick response :)
We are not using MyISAM tables. All our tables are
InnoDB tables. The rational behind this decision is
that the database is expected to get hundreds of
insert queries per second, so we want the row level
locking
of InnoDB to speed this up. (I should have mentioned
this in the first mail. Sorry for that). Having one
large InnoDB table is not a good option because
it'll
throttle the performance of selects and inserts and
will be a hindrance when we want to replicate data.
The option of mysql-replication has been looked in
to.We are not relying on the mysql replication for
load balancing or data backup.These things are done
by
the application layers.
I had looked in to the mysql cluster. It does not
cover all the use cases that we have in mind and it
is
not flexible enough to give us more control over how
data is stored and restored in case of node
failures.
So it again boils down to same two questions:
1) What is a better option: (Having hundreds of
databases or having a single database with
thousands
of tables).
2) Will it give any performance improvement if we
run
multiple mysql server instances (By partitioing the
data set and having one mysql server handle one data
set). This option is only applicable if we have
multiple databases.
Thanks in advance,
-Alok.
> On Tue, 2004-11-30 at 22:38, Brent Baisley wrote:
> > If you are hitting file size limits, you probably
> want to look into
> > using the InnoDB table type. That will allow you
> to
> work around file
> > size limits and have a database of just about any
> size you need. You
> > won't end up having a 30GB file, but multiple
> smaller files which will
> > be transparent to your application. InnoDB tables
> are probably your
> > best place to look for a solution.
> >
> > If you must use MyISAM table types, perhaps look
> into the RAID option
> > for MyISAM tables. Although that will still have
> it's limits, mainly
> > because of index size limits.
> >
> > If you are worried about load, look into
> replication. One machine will
> > act as the master where all updates will occur,
> but
> then any of your
> > replication machines can handle queries. You could
> setup a round robin
> > DNS to automatically split the load or go with
> something even more
> > sophisticated. You also might see what you can
> find
> on MySQL clusters,
> > although this is a fairly new feature (this year)
> and I myself have not
> > read up on it.
> >
> >
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile
> phone.
> http://mobile.yahoo.com/maildemo
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
