List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:April 22 1999 1:35am
Subject:Too many databases
View as plain text  
Hi!

>>>>> "Scott" == Scott Hassan <hassan@stripped> writes:

Scott> Hi there.  At eGroups.com, we are using Mysql pretty heavily.  Awesome 
Scott> stuff!  We have a couple problems:

Scott> Problem 0:

Scott>   When isamchk-ing a table that the ISM and ISD files are on separate
Scott>   disks and are symlinked together in the database directory, isamchk
Scott>   screws up when writing the final ISM file.  Does isamchk understand 
Scott>   symlinks?

Yes and no; isamchk understands symbolic links, but it also assumes
that the .ISM and .ISD are on the same disk.  (sorry, this is an old
legacy that I should fix sometime).

Scott> Problem 1:

Scott>   We have an application using mysql that needs tens of
Scott>   thousands of separate databases.  We would like a simple way for Mysql 
Scott>   to *not* place all of the databases in the top level directory.
Scott>   Preferably, in a 256 directory hashing scheme based on the database
Scott>   name.  Has anyone done this or has a better idea?

I haven't encountered this problem before.

To change the directory entires to a hashing schema, you 
must probably patch MySQL at 5-10 places.

Starting with:

sql/dfunc.c, function openfrm()
sql/dfunc.c, function create_frm()
sql/dfunc.c, function fix_frm_ref()
sql/sql_table.c, function: mysql_rename_table()
sql/sql_table.c, function: mysql_alter_table()


Scott> Problem 2:
 
Scott>   Support for tables greater than 2G on a Linux box.

The new ISAM (which is now in the final testing phase) will have an
internal limit of 63 bits.  The new ISAM still requires that the file
system must support big files.  To use files bigger than 2G on
Intel-Linux you have to use one of the new experimental file systems
that supports this!

Scott> Problem 3:

Scott>   Separate update_logs per database?  per table?

On the TODO, but not yet done.

Scott> Problem 4:

Scott>   We need delayed updates.  It seems if we are doing updates of the
Scott>   form:
    
Scott> 	update table set x=x+2 where y=foobar

Scott>   That it could be potentially delayed until there is a period of
Scott>   inactively. 

If your client can wait, You can do this with UPDATE LOW_PRIORITY ...
If not, the other options is to create a small user process with two threads;
One receives data and the other updates the MySQL server with 'LOW_
prioriy'

Regards,
Monty
Thread
Too many databasesScott Hassan21 Apr
  • Re: Too many databasesFred Read21 Apr
    • Re: Too many databasesScott Hassan21 Apr
  • Too many databasesMichael Widenius22 Apr