Hi, the correct solution depends on your specific needs, but marioroy's Perl Many-Core Engine offers several options. Please see MCE::Shared, MCE::Shared::Hash, MCE::Shared::Minidb, MCE::Shared::Cache.

From what I understand from your post, you basically want a shared DB where individual keys can be handled as with a cache, but sub-keys can also be accessed. Presumably you also need to be able to search for a key or keys by the value(s) of a sub-key or sub-keys). You might like:

use strict; use warnings; use feature 'say';
use Data::Dumper;

use MCE::Shared;

my $db = MCE::Shared->minidb();

my %hash = ( problem => 'foo', technique => 'blorgle', answer => 41 );
my %junk = ( problem => 'bla', technique => 'blargle' );

$db->hset( my_key => %hash );
$db->hset( junkey => %junk ); # sorry for the bad pun

my $pid = fork;
die 'Fork failed' if not defined $pid;

if ( $pid == 0 ) { # child
    $db->happend( my_key => (problem => 'bar'));
    $db->hincr( my_key => 'answer');
    $db->hset( my_key => (technique => 'frobnicate') );
    exit;
}

# parent
wait;

my @rows = $db->select_href(':hashes', ':WHERE answer > 0');

say Dumper \@rows;

__END__
[download]

$ perl monks/1226220.pl

$VAR1 = [
          [
            'my_key',
            {
              'answer' => 42,
              'problem' => 'foobar',
              'technique' => 'frobnicate'
            }
          ]
        ];
[download]

(A note from the doc that helps explain why the unfamiliar query syntax: "Several methods take a query string for an argument. The format of the string is described below. In the context of sharing, the query mechanism is beneficial for the shared-manager process. It is able to perform the query where the data resides versus the client-process grep locally involving lots of IPC.")

Hope this helps!

all databases I've looked at would need a ramdisk, since they don't support in-memory connections from multiple processes.

Doubtless I am misunderstanding here but does the memory engine of MariaDB not satisfy your requirements? I've used it for lower-latency stores in several projects (including FCGI-based access) without problems. Could you explain where this falls short for you?

Really depends on your needs. But just to shamelessly plug my own stuff: Interprocess messaging with Net::Clacks

Net::Clacks implements real time messaging as well as a memory-only cache. Basically, if you read a file, you could just store() it in Clacks as Base64. Structures could be encoded with JSON::XS + Base64. At least, that's how i'm doing it.

If you want to handle the file loading/saving/deleting on the server side for some reason, it would be sort of trivial to implement. Just adding some flags to the OVERHEAD command handling in Net::Clacks::Server.pm should do the trick.

Cache::FastMmap: https://metacpan.org/pod/Cache::FastMmap

Though it will freeze/thaw using Storable, which might slow you down a bit.

CHI has been around a long time and although it hasn't seen much updating recently it's proven in many production environments - there's also some interest in porting it to Perl6 which I assume is a good thing.