<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Caché on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/cach%C3%A9/</link><description>Recent content in Caché on Karpoke - Just Another Blog</description><generator>Hugo -- 0.159.0</generator><language>es</language><lastBuildDate>Sat, 14 Jan 2017 14:36:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/cach%C3%A9/index.xml" rel="self" type="application/rss+xml"/><item><title>Moving persistent data out of Redis</title><link>http://karpoke.ignaciocano.com/2017/01/14/moving-persistent-data-out-of-redis/</link><pubDate>Sat, 14 Jan 2017 14:36:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2017/01/14/moving-persistent-data-out-of-redis/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Transitioning all that information transparently involved planning and
coordination. For each problem domain using persistent Redis, we considered
the volume of operations, the structure of the data, and the different access
patterns to predict the impact on our current MySQL capacity, and the need
for provisioning new hardware.&lt;/p&gt;
&lt;p&gt;For the majority of callsites, we replaced persistent Redis with GitHub::KV,
a MySQL key/value store of our own built atop InnoDB, with features like key
expiration. We were able to use GitHub::KV almost identically as we used
Redis: from trending repositories and users for the explore page, to rate
limiting to spammy user detection.&lt;/p&gt;</description></item></channel></rss>