I continue to be a big user of Perl, and for many of my sites I avoid
the use of MySQL which means that I largely store data in flat files,
SQLite databases, or in memory via Redis.
One of my servers was recently struggling with RAM, and the suprising
cause was "too much data" in Redis. (Surprising because I'd not been
paying attention and seen how popular it was, and also because ASCII text
compresses pretty well).
Read/Write speed isn't a real concern, so I figured I'd move the data into an
SQLite database, but that would require rewriting the application.
The client library for Perl is pretty awesome, and simple usage looks like this:
# Connect to localhost.
my $r = Redis->new()
# simple storage
$r->set( "key", "value" );
# Work with sets
$r->sadd( "fruits", "orange" );
$r->sadd( "fruits", "apple" );
$r->sadd( "fruits", "blueberry" );
$r->sadd( "fruits", "banannanananananarama" );
# Show the set-count
print "There are " . $r->scard( "fruits" ) . " known fruits";
# Pick a random one
print "Here is a random one " . $r->srandmember( "fruits" ) . "\n";
I figured, if I ignored the Lua support and the other more complex operations,
creating a compatible API implementation wouldn't be too hard. So rather
than porting my application to using SQLite directly I could juse use a
In short I change this:
my $r = Redis->new();
my $r = Redis::SQLite->new();
And everything continues to work. I've implemented all the set-related
functions except one, and a random smattering of the other simple operations.
The appropriate test-cases in the Redis client library (i.e. removing all
references to things I didn't implement) pass, and my own new tests also
make me confident.
It's obviously not a hard job, but it was a quick solution to a real problem
and might be useful to others.
My image hosting site, and my markdown sharing site now both use this wrapper and seem to be performing well - but with more free RAM.
No doubt I'll add more of the simple primitives as time goes on, but so far I've done enough to be useful.