title: Creating an in-memory cache that persists between executions
body: <p>I'm developing a Python command line utility that potentially involves rather large queries against a set of files.  It's a reasonably finite list of queries (think indexed DB columns)  To improve performance in-process I can generated sorted/structured lists, maps and <em>trees</em> once, and hit those repeatedly, rather than hit the file system each time.</p>
  
  <p>However, these caches are lost when the process ends, and need to be rebuilt every time the script runs, which dramatically increases the runtime of my program.  I'd like to identify the best way to share this data between multiple executions of my command, which may be concurrent, one after another, or with significant delays between executions.</p>
  
  <p>Requirements:</p>
  
  <ul>
  <li>Must be fast - any sort of per-execution processing should be minimized, this includes disk IO and object construction.</li>
  <li>Must be OS agnostic (or at least be able to hook into similar underlying behaviors on Unix/Windows, which is more likely).</li>
  <li>Must allow reasonably complex querying / filtering - I don't think a key/value map will be good enough</li>
  <li>Does <strong>not</strong> need to be up-to-date - (briefly) stale data is perfectly fine, this is just a cache, the actual data is being written to disk separately.</li>
  <li>Can't use a heavyweight daemon process, like MySQL or MemCached - I want to minimize installation costs, and asking each user to install these services is too much.</li>
  </ul>
  
  <p>Preferences:</p>
  
  <ul>
  <li>I'd like to avoid any sort long running daemon process at all, if possible.</li>
  <li>While I'd like to be able to update the cache quickly, rebuilding the whole cache on update isn't the end of the world, fast reads are much more important than fast writes.</li>
  </ul>
  
  <p>In my ideal fantasy world, I'd be able to directly keep Python objects around between executions, sort of like Java threads (like Tomcat requests) sharing singleton data store objects, but I realize that may not be possible.  The closer I can get to that though, the better.</p>
  
  <p><strong>Candidates:</strong></p>
  
  <ul>
  <li><p>SQLite in memory</p>
  
  <p>SQLite on it's own doesn't seem fast enough for my use case, since it's backed by disk and therefore will have to read from the file on every execution.  Perhaps this isn't as bad as it seems, but it seems necessary to persistently store the database in memory.  SQLite allows for DBs to <a href="http://www.sqlite.org/inmemorydb.html" rel="nofollow noreferrer">use memory as storage</a> but these DBs are destroyed upon program exit, and cannot be shared between instances.</p></li>
  <li><p>Flat file database loaded into memory with <a href="http://docs.python.org/library/mmap" rel="nofollow noreferrer">mmap</a></p>
  
  <p>On the opposite end of the spectrum, I could write the caches to disk, then load them into memory with mmap, can share the same memory space between separate executions.  It's not clear to me what happens to the mmap if all processes exit however.  It's ok if the mmap is eventually flushed from memory, but I'd want it to stick around for a little bit (30 seconds?  a few minutes?) so a user can run commands one after another, and the cache can be reused.  <a href="http://blog.schmichael.com/2011/05/15/sharing-python-data-between-processes-using-mmap/" rel="nofollow noreferrer">This example</a> seems to imply that there needs to be an open mmap handle, but I haven't found any exact description of when memory mapped files get dropped from memory and need to be reloaded from disk.</p>
  
  <p>I think I could implement this, if mmap objects do stick around after exit, but it feels very low level, and I imagine someone's already got a more elegant solution implemented.  I'd hate to start building this only to realize I've been rebuilding SQLite.  On the other hand, it feels like it would be very fast, and I could make optimizations given my specific use case.</p></li>
  <li><p>Share Python objects between processes using Processing</p>
  
  <p>The Processing package indicates "<a href="http://pypi.python.org/pypi/processing" rel="nofollow noreferrer">Objects can be shared between processes using ... shared memory</a>".  Looking through the rest of the docs, I didn't see any further mention of this behavior, but that sounds <em>very</em> promising.  Can anyone direct me to more information?</p></li>
  <li><p>Store data on a RAM disk</p>
  
  <p>My concern here is OS-specific capabilities, but I could <a href="http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/" rel="nofollow noreferrer">create a RAM disk</a> and then simply read/write to it as I please (SQLite?).  The <a href="https://stackoverflow.com/questions/4351048/how-can-i-create-a-ramdisk-in-python">fs.memoryfs</a> package seems like a promising alternative to work with multiple OSs, but the comments imply a fair number of limitations.</p></li>
  </ul>
  
  <p>I know <a href="http://docs.python.org/library/pickle.html" rel="nofollow noreferrer">pickle</a> is an efficient way to store Python objects, so it might have speed advantages over any sort of manual data storage.  Can I hook pickle into any of the above options?  Would that be better than flat files or SQLite?</p>
  
  <p>I know there's a lot of questions related to this, but I did a fair bit of digging and couldn't find anything directly addressing my question with regards to multiple command line executions.</p>
  
  <p><strong>I fully admit, I may be way overthinking this.  I'm just trying to get a feel for my options, and if they're worthwhile or not.</strong></p>
  
  <p>Thank you so much for your help!</p>