Re:How MySQL memory table saved the day
by webstartupper on Friday December 13, 2013 @10:22AM
(#6900928)
Thanks for the link. Unfortunately, since there are 30 different columns that can be searched on, there are many indexes and the index size for the domains table itself is 4GB. I run this off a 2GB linode, so unless I add a lot more RAM, Innodb is not going to match the memory table speed.
[ Parent
| on HN ]
Re:How MySQL memory table saved the day
by jeffdavis on Friday December 13, 2013 @10:55AM
(#6901126)
I'm a little confused... the InnoDB table and memory table had the same data, but the InnoDB table was larger (at least twice as large, I presume)?
Re:How MySQL memory table saved the day
by webstartupper on Friday December 13, 2013 @11:00AM
(#6901149)
The Innodb table right now has about 9 million records and is 8GB in size (4GB index size). The memory table has a subset of the same data - 1.2 million records and is 276MB in size.
Re:How MySQL memory table saved the day
by jeffdavis on Friday December 13, 2013 @11:11AM
(#6901216)
It makes me curious what an apples-to-apples comparison would look like. What it you put the same subset in a separate innodb table and tune the memory settings so it's likely to stay resident?
Re:How MySQL memory table saved the day
by webstartupper on Friday December 13, 2013 @11:44AM
(#6901427)
We had tried this before switching to the memory table. I cannot remember exact details, but the resulting innodb table was still too large - maybe around 1 GB and we did not want to add additional RAM.
Another issue with using a second Innodb table would be the load time. Every 3 hours we empty the memory table and load the subset from the innodb table (we actually use an MyIsam table in the middle.. but that's not important). Loading the table takes less than 10 seconds. If we had used an innodb table instead of a memory table, this load time would be significant.