Comments on: Real-Life Use Case for “Barracuda” InnoDB File Format

By: Bernhard

Bernhard — Wed, 28 May 2008 17:51:51 +0000

It seems to depend very much on the data. I tested some simple queries on a forum with ~150′000 posts. While 5.1 with a compressed ‘posts’ table had about the same performance as a normal InnoDB table in 5.0, a combined query with the ’search_table’ revealed that the 5.1 ‘Barracuda’ was more than 65% slower than 5.0. It’s not the 5.0 because the 5.1 performs the same in the ‘old’ InnoDB format.

By: Ken Jacobs

Ken Jacobs — Thu, 24 Apr 2008 16:52:43 +0000

As you probably know, Alexsky, using fast index create to create the secondary index on word_document_id AFTER you cop the data could have benefits in terms of your total “conversion time”, and the resulting index would also be more dense, making it more efficient for that 50% of your queries on the secondary key. If you happen to try it, let us know what you find out!

By: Alexey Kovyrin

Alexey Kovyrin — Thu, 24 Apr 2008 15:48:40 +0000

2Steve: Yes, as you can see there is one more index and selects on this table are distributed like: 50% by PK and 50% by secondary key.

By: Alexey Kovyrin

Alexey Kovyrin — Thu, 24 Apr 2008 15:46:18 +0000

Actually, this is not the same data we’ve compressed – this is “backup” copy of the same table so table structure and stats should be really close to our case.

By: Alexey Kovyrin

Alexey Kovyrin — Thu, 24 Apr 2008 15:45:00 +0000

2Ken and Shane: Conversion has been performed by simple ALTER TABLE.

Some table-related info:
[sql]
CREATE TABLE `document_queries` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`word_document_id` int(11) DEFAULT NULL,
`html` mediumtext,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
`query_count` int(11) DEFAULT ‘0′,
`short_html` text,
PRIMARY KEY (`id`),
KEY `index_document_queries_on_word_document_id` (`word_document_id`)
) ENGINE=InnoDB
[/sql]

[sql]
mysql> show table status like ‘document_queries’\G
*************************** 1. row ***************************
Name: document_queries
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 10027623
Avg_row_length: 4266
Data_length: 42783473664
Max_data_length: 0
Index_length: 43614208
Data_free: 0
Auto_increment: 3442149
Create_time: 2008-04-21 19:25:22
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment: InnoDB free: 120832 kB
1 row in set (0.24 sec)
[/sql]

By: Shane Duffy

Shane Duffy — Thu, 24 Apr 2008 14:31:10 +0000

to echo Ken Jacobs:

Would love to know how you preformed the conversion aswell, Dump the data out and reload or doing inplace Alter of the table?

Thanks

By: Ken Jacobs

Ken Jacobs — Thu, 24 Apr 2008 08:16:51 +0000

By the way, Alexy, we at Innobase are very pleased to see these test results. Thank you for doing these tests and posting. We would love to see more details on the specific schema, data and workload. How many columns? Average length of each column and each row?

And, how did you do the conversion? Did you simply ALTER TABLE from MyISAM to InnoDB? LOAD DATA? Did you create the secondary indexes AFTER loading the table (to take advantage of “fast index create”?

The more you can share, the more we’ll all know about the potential of the InnoDB Plugin to address varying requirements.

Thanks

By: Ken Jacobs

Ken Jacobs — Thu, 24 Apr 2008 08:05:45 +0000

Petya, as you note, the InnoDB Plugin is at this stage an “early adopter release”. It’s for you to test and decide if you want to be an early adopter! As time goes by, more people will use it, and you can be an “adopter”. And, if you wait too long, you’ll be a “late adopter”.

Innobase has tested the code well. But there are operational considerations as documented in the manual. And some of the very earliest adopters are finding bugs (though nothing too bad so far!), while others are finding excellent performance. It is “early days” in the history of the InnoDB Plugin.

I suggest you watch this space and the messages posted at http://forums.innodb.com/ to get a sense of what other people are seeing. You are undoubtedly the best judge of whether the software is “production capable”, based on your own application requirements, your tolerance for risk, and your understanding of the actual issues encountered, documented and resolved. It is all too easy for someone to declare software “production”, but that label doesn’t really mean as much as you will learn by doing your own testing and evaluation.

Best wishes!

By: Petya

Petya — Thu, 24 Apr 2008 05:11:15 +0000

Sounds great. But is it production capable?
“Early Adopter release” as written on innodb.com

By: Steve

Steve — Thu, 24 Apr 2008 03:45:05 +0000

I’m very glad this worked out for your client. I want to thank you for your entry into this blog showing some real life performance numbers.

You mentioned that you had indexes including the Primary index. Were they used often as in a index which was used along with the primary index the majority of the time? I am asking this because the phpBB search in phpBB 3.0.1 has two fields in a table which correspond to a word_id and a post_id, both fields are indexed together and are used as often as search is used. I’m trying to estimate gains based on your findings the improvements that can be gained for phpBB’s search in terms of DB performance.