Re: How to get large items from a table

harryxiyou <[email protected]> Thu, 3 Apr 2014 08:41:57 +0800
Newsgroups gmane.comp.db.mysql.devel
Message-ID <CAD+1EGO3k+cOJ7_8sfJ_mEH3H4W7xsm-ohfNGXduVHxSwmpvdg@mail.gmail.com>
On Wed, Apr 2, 2014 at 10:56 PM, shawn l.green <[email protected]> wrote:
> Hello Harry,

Hi Shawn,

> You appear to face the same resource dilemmas that all storage engines face:
> there will be more data stored on disk than you can possibly buffer in
> memory. There have been many strategies designed to keep only the 'most
> important' or 'most recently used' elements in memory. Please look to them
> for inspiration.
>
> To go along with trying to keep a 'warm' cache of data for faster retrieval,
> you need to decide how to manage scans of large quantities of data (such as
> your SELECT * ...  query) and if you want them to replace the warm buffer
> you have been cultivating since startup.  This may mean that you skip trying
> to buffer any scan that uses more than X percent of your table (you get to
> pick what the X is) to keep your cache nice and toasty.
>
> And you may have multiple cache types, hot, warm, cold, temporary, ...
> depending on how you want to manage them.  Again, this is a hugely broad
> topic with many different algorithms used in both commercial and open source
> products. There is no one 'correct' answer for all situations.
>
> Then you get to the subject of index management, file storage formats, row
> identification, and how to locate a row on disk.  That's an entirely
> different beast. Of course, if you store nothing on disk then those design
> questions become irrelevant.
>

Thanks very much, I would take your above suggestions into consideration.


Harry.

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals