Why would this be a deal breaker?

If you have an app that uses that MyISAM feature porting it to InnoDB can be a major headache.

Example:

#############################################
# MyISAM

CREATE TABLE MyISAM_animals (grp ENUM(’fish’,'mammal’,'bird’) NOT NULL, id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (grp,id))ENGINE=MyISAM;

INSERT INTO MyISAM_animals (grp,name) VALUES (’mammal’,'dog’),(’mammal’,'cat’),(’bird’,'penguin’),(’fish’,'lax’),(’mammal’,'whale’),(’bird’,'ostrich’);

SELECT * FROM MyISAM_animals ORDER BY grp,id;
+——–+—-+———+
| grp | id | name |
+——–+—-+———+
| fish | 1 | lax |
| mammal | 1 | dog |
| mammal | 2 | cat |
| mammal | 3 | whale |
| bird | 1 | penguin |
| bird | 2 | ostrich |
+——–+—-+———+

#############################################
# InnoDB

CREATE TABLE InnoDB_animals (grp ENUM(’fish’,'mammal’,'bird’) NOT NULL, id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (grp,id))ENGINE=InnoDB;
### ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key

CREATE TABLE InnoDB_animals (grp ENUM(’fish’,'mammal’,'bird’) NOT NULL, id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (id,grp))ENGINE=InnoDB;

INSERT INTO InnoDB_animals (grp,name) VALUES (’mammal’,'dog’),(’mammal’,'cat’),(’bird’,'penguin’),(’fish’,'lax’),(’mammal’,'whale’),(’bird’,'ostrich’);

SELECT * FROM InnoDB_animals ORDER BY grp,id;

+——–+—-+———+
| grp | id | name |
+——–+—-+———+
| fish | 4 | lax |
| mammal | 1 | dog |
| mammal | 2 | cat |
| mammal | 5 | whale |
| bird | 3 | penguin |
| bird | 6 | ostrich |
+——–+—-+———+

#############################################

I’ve translated it to russian: http://greenmice.info/ru/node/106

HTH to any of my russian colleagues.

First I should note MySQL optimizer is often weak when handling complex queries which can be the problem unrelated to storage engines.

Second – It is wrong to Assume MyISAM will be always faster for read only – there are many cases when it does not, in particular because it only can cache “row” data in OS cache, while Innodb can do this in the buffer pool. So in reality I would do the benchmark and decide…

Regarding XtraDB – we’re not getting into the Product basics – we do XtraDB because we have a lot of customers with Innodb which are having issues with it and XtraDB is our effort to help them. As Maria, Falcon, PBXT will mature we will be helping customers with them and blogging about them actively too.

MyISAM does not get too many posts because it is simple

Uff, ok, good. I was surprised to hear that InnoDB is almost always better choice than MyISAM. Because I’m that guy who develops OLAP system. My DBs are very small compared to the mentioned above cases – mysqldump of the largest DB is only 550M. But queries upon data can run for seconds and even tens seconds (I even had one which ran 3 mins before optimization), as each query joins several tables, often 5-6-7 ones. And when the number of rows in the two biggest tables (which participate in almost every query) reached 300K and 50K, performance issues are visible. Data updates are performed once a day, and can be re-done if in the case of a crash entire DB has to be restored from a daily backup, so I almost perfectly live without InnoDB. So I think I should stick to MyISAM.
I can guess that now, when you started developing XtraDB based on InnoDB, you will be almost entirely focused on InnoDB issues. It would be really great if you find some time to continue covering MyISAM as well.

I understand benefits of partitioning. I’m just warning you about performance penalties of dealing with 1024 of underlying partitions. The compression does have considerable overhead on heavy insert no surprises here.

cheers

This one has a 0.999 probability of being the solution to your 1GB problem:
Install a 64bit linux.

I suspect you have a 32bit installation, which is why the storage engine would not accept more than 1GB: it’s out of address space. In total, you may squeeze some 1.5G from all MySQL components together…

On a 4GB machine, setting innodb_buffer_pool_size to 2.5G (assuming only InnoDB is used, machine is solely MySQL) is probably a reasonable value, which leaves you much enough space for complicated queries and many connections.

I suspect that moving from 1GB to 2.5GB will increase you InnoDB performance a lot, based on the fact you only have 15GB of data.

Regards