MySQL Forums
Forum List  »  InnoDB

Re: InnoDB compression - in-page modification log
Posted by: Marko Mäkelä
Date: September 10, 2014 07:38AM

Yes, InnoDB ROW_FORMAT=COMPRESSED compression is too complex. I implemented it between 2005 and 2008. The high-level design is by Heikki Tuuri, the original author of InnoDB.

The problem that we tried to solve was fragmentation. If we allowed dynamic sizing of the compressed pages, the storage could get fragmented. So, we made the compressed page size fixed, specified at table(space) creation time. The extra space within a compressed page was reserved for the in-page modification log, so that costly calls to the compression code would be avoided.

In retrospect, it would be simpler to only keep uncompressed data in the buffer pool, and to only compress or decompress when actually doing the page I/O. The size problem still needs to be solved, though. If a 16k page compresses to 1k, what to do with the remaining 15k? On some systems, FALLOC_FL_PUNCH_HOLE could be the answer. A portable solution that also works on HDDs would probably take some more thought.

I think that it is a good idea to do compression (and for that matter, encryption) in the client. It will save resources on the network and on the server. The only drawback with that approach is that you will be unable to index the compressed (or encrypted) data.

Best regards,

Marko Mäkelä

Options: ReplyQuote


Subject
Views
Written By
Posted
Re: InnoDB compression - in-page modification log
1001
September 10, 2014 07:38AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.