Re: Caching DB rows transparently and with SQL search

1nickt recommended memcached, which fits your use case. I can also recommend looking at Sphinx Search, which can be used as a fast indexed/in-memory data store. It's more effective as you add more data (talking millions - or more - of records). It's a little harder to set up than memcached, but can be federated/sharded. It also has a query language of its own that can be used like most SQL constraints. The Perl module for it, Sphinx::Search, is also quite mature and robust. Sphinx also has capabilities that allow the index to be updated incrementally as well. You may also want to checkout Redis, which while not billed as a cache (but as a shared data structure server/middleware), it can be uses quite effectively as a cache or ephemeral data store.

Comment on Re: Caching DB rows transparently and with SQL search

Replies are listed 'Best First'.
Re^2: Caching DB rows transparently and with SQL search by cavac (Prior) on Jul 07, 2020 at 06:59 UTC
I'm using Net::Clacks to cache database results, for example for my DNS Server. But take note that i am biased, since i'm the author of Net::Clacks... `perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'`	[reply] [d/l]
Re^3: Caching DB rows transparently and with SQL search by bliako (Abbot) on Jul 07, 2020 at 07:18 UTC
Thanks for the pointer cavac. I did not know anything about this Clacks protocol. If I understand right, you use Net::Clacks for caching whenever a db request is needed/fetched. And that can be for multiple clients. You broadcast it, and clacks server deals with it. And has it available for all clients. In a client/server model. Fine, but what's the key? This is my primary obstacle in using (any) cache solution. Whenever I make a DBIx::Class db search I supply `($conditions, $attributes)` which are hashes for the search, which can be undef as well. So, one part of the key is the current function, e.g. `Model::User::list()`. The other part of the key must include some kind of digest of said function parameters. Which is not that easy to calculate efficiently and beat the db call ... bw, bliako	[reply] [d/l] [select]
Re^2: Caching DB rows transparently and with SQL search by bliako (Abbot) on Jul 06, 2020 at 09:53 UTC
thanks for the suggestion. I will have it in mind although for my needs right now is OTP.	[reply]