|
|
| |
Cache::BDB(3) |
User Contributed Perl Documentation |
Cache::BDB(3) |
Cache::BDB - An object caching wrapper around BerkeleyDB
use Cache::BDB;
my %options = (
cache_root => "/tmp/caches",
namespace => "Some::Namespace",
default_expires_in => 300, # seconds
);
my $cache = Cache::BDB->new(%options);
#
# [myshellprompt:~]$ find /tmp/caches
# /tmp/caches/Some::Namespace/
# /tmp/caches/Some::Namespace/Some::Namespace.db
# /tmp/caches/Some::Namespace/__db.001
# /tmp/caches/Some::Namespace/__db.002
# /tmp/caches/Some::Namespace/__db.003
#
$cache->namespace(); # returns "Some::Namespace", read only
$cache->default_expires_in(); # returns 300
$cache->default_expires_in(600); # change it to 600
$cache->set(1, \%some_hash);
$cache->set('foo', 'bar');
$cache->set(20, $obj, 10);
$cache->add(21, 'whatever'); # works, nothing with the key '21' set yet.
$cache->add(21, 'coffeepot'); # fails, can only add() something that hasn't
# yet been set
$cache->replace(21, 'shoelace'); # replaces the data 'whatever' with
# 'shoelace'
$cache->replace(7, 'tattoo'); # fails key/value pair was never set() or
# add()ed previously
my $h = $cache->get(1); # $h and \%some_hash contain the same data
my $bar = $cache->get('foo'); # $bar eq 'bar';
my $obj = $cache->get(20); # returns the blessed object
$cache->count() == 3;
# assuming 10 seconds has passed ...
$cache->is_expired(20); # returns true ..
$cache->purge();
$cache->get(20); # returns undef
$cache->count() == 2;
my $hr = $cache->get_bulk();
# $hr = {1 => {contents_of => '%some_hash'},
# 21 => 'shoelace' };
$cache->close(); # close the cache object
This module implements a caching layer around BerkeleyDB for object persistence.
It implements the basic methods necessary to add, retrieve, and remove
objects. The main advantage over other caching modules is performance. I've
attempted to stick with a Cache::Cache-like interface as much as
possible, though it may differ here and there.
I've been developing using a very recent version of Berkeley DB (v4.4.20) and
BerkeleyDB (v0.27). I'm pretty sure that most of the functionality the module
relies on is available in Berkeley DB version 3 and higher, but so far I have
not tested with older versions. I'm open to making version specific
concessions if necessary. If at all possible, I would advise you to upgrade
both Berkeley DB and BerkeleyDB to their latest respective versions.
Cache::BDB currently serializes everything it stores with
Storable.
The intent of this module is to supply great performance with a reasonably
feature rich API. There is no way this module can compete with, say, using
BerkeleyDB directly, and if you don't need any kind of expiration, automatic
purging, etc, that will more than likely be much faster. If you'd like to
compare the speed of some other caching modules, have a look at
http://cpan.robm.fastmail.fm/cache_perf.html. I've included a patch
which adds Cache::BDB to the benchmark.
All Cache::BDB environments are opened with the DB_INIT_CDB flag. This enables
multiple-reader/single-writer locking handled entirely by the Berkeley DB
internals at either the database or environment level. See
http://www.sleepycat.com/docs/ref/cam/intro.html for more information on what
this means for locking.
Important: it is a bad idea to share a single Cache::BDB object
across multiple processes or threads. Doing so is bound to cause you pain.
Instead, have your thread/process instantiate its own Cache::BDB object. It
is safe to have them all pointing at the same cache file.
For every new Cache::BDB object, a Berkeley DB Environment is created (or
reused if it already exists). This means that even for a single cache object,
at least 4 files need to be created, three for the environment and at least
one for the actual data in the cache. Its possible for mutliple cache database
files to share a single environment, and its also possible for multiple cache
databases to share a single database file. See the SYNOPSIS above for a quick
view of what you are likeley to find on the filesystem for a cache. Cache::BDB
uses BerkeleyDB exclusively with regard to files, so if you have questions
about whats in those files, you might familiarize yourself further with
Berkeley DB.
- new(%options)
- * cache_root
- Specify the top level directory to store cache and related files in. This
parameter is required. Keep in mind that Cache::BDB uses a
BerkeleyDB environment object so more than one file will be written
for each cache.
- * cache_file
- If you want to tell Cache::BDB exactly which file to use for your
cache, specify it here. This paramater is required if you plan to use the
env_lock option and/or if you want to have multiple logical databases
(namespaces) in a single physical file. If unspecified, Cach::BDB
will create its database file using the namespace.
cache_file should be relative to your cache_root, not
fully-qualified, i.e.
my %options = ( cache_root => '/some/location/for/caching/',
cache_file => 'whatever.db',
namespace => 'MyObjects');
This gives you, among other files,
/some/location/for/caching/whatever.db. Your logical database inside of
'whatever.db' will be named with 'MyObject'. If you were to then
instantiate another Cache::BDB with the following:
my %options = ( cache_root => '/some/location/for/caching/',
cache_file => 'whatever.db',
namespace => 'MyOtherObjects');
You would now have two logical caches in one physical file,
which is ok, but see namespace below for a better idea.
- * namespace
- Your namespace tells Cache::BDB where to store cache data
under the cache_root if no cache_file is specified or what
to call the database in the multi-database file if cache_file is
specified. It is a required parameter. For clarity, it might be best to
instantiate Cache::BDB objects like so:
my $namespace = 'MyObjects';
my %options = ( cache_root => "/some/location/for/caching/$namespace",
namespace => $namespace );
Unlike the examples given above under cache_file, this allows
you to locate a single cache type in its own directory, which gives you
more flexibility to nuke it wholesale or move things around a
little.
- * type
- Cache::BDB allows you to select the type of Berkeley DB storage mechanism
to use. Your choices are Hash, Btree, and Recno. Queue isn't supported. I
haven't tested the three supported types extensively. The default, if
unspecified, is Btree, and this is probably good enough for most
applications. Note that if a cache is created as one type it must remain
that type. If you instantiate a Cache::BDB object with one type (or use
the default), and then attempt to connect to the same cache with a newly
instantiated object that uses a different type, you will get a warning,
and Cache::BDB will be nice and connect you to the cache with its original
type.
Important: up until Berkeley DB 4.4.x, it has not been
possible to shrink the physical size of a database file, which means
that, technically, your cache files will never get smaller even if you
delete everything from them. HOWEVER, with 4.4.x this functionality is
now possiblye but it will only work with the Btree type. As soon as this
is available in the BerkeleyDB.pm wrapper (soon I'm told), I'll be
releasing a version with some options to allow this. Point being, this
may be a good reason to stick with Btree.
For more info, see
http://www.sleepycat.com/docs/ref/am_conf/intro.html.
- * env_lock
- If multiple databases (same or different files) are opened using the same
Berkeley DB environment, its possible to turn on environment level locking
rather than file level locking. This may be advantageous if you have two
separate but related caches. By passing in the env_lock parameter with any
true value, the environment will be created in such a way that any
databases created under its control will all lock whenever Berkeley DB
attempts a read/write lock. This flag must be specified for every database
opened under this environment. Note: this is very untested in Cache::BDB,
and I don't know how necessary it is.
- * default_expires_in
- Time (in seconds) that cached objects should live. If set to 0, objects
never expire. See set to enable a per-object value.
- * auto_purge_interval
- Time (in seconds) that the cached objects will be purged by one or both of
the auto_purge types (get/set). If set to 0, auto purge is
disabled. Note, of course, that objects won't actually be purged until
some event actually takes place that will call purge (set or get), so if
this is set to 300 but no gets or sets are called for more than 300
seconds, the items haven't actually been purged yet.
- * auto_purge_on_set
- If this item is true and auto_purge_interval is greater than 0,
calling the set method will first purge any expired records from
the cache.
- * auto_purge_on_get
- If this item is true and auto_purge_interval is greater than 0,
calling the get method will first purge any expired records from
the cache.
- * purge_on_init
- If set to a true value, purge will be called before the constructor
returns.
- * purge_on_destroy
- If set to a true value, purge will be called before the object goes out of
scope.
- * clear_on_init
- If set to a true value, clear will be called before the constructor
returns.
- * clear_on_destroy
- If set to a true value, clear will be called before the object goes out of
scope.
- * disable_compact
- Disable database compactions for clear, purge, delete and remove methods.
See DATABASE SIZE below for more information on database
compaction.
- * disable_auto_purge
- As a courtesy, Cache::BDB will automatically remove() any expired
cache item you get() before returning undef. This is handy if you
don't feel the need to do a lot of explicit cache purging, but if you only
want purge, remove, delete or clear to actually delete cache items, you
can disable this functionality by passing in disable_auto_purge with any
true value.
- close()
- Explicitly close the connection to the cache. A good idea. Essentially the
same as undef'ing the object (explicitly calls DESTROY).
- namespace()
- This read only method returns the namespace that the cache object is
currently associated with.
- auto_purge_interval($seconds)
- Set/get the length of time (in seconds) that the cache object will wait
before calling one or both of the auto_purge methodss. If set to 0,
automatic purging is disabled.
- auto_purge_on_set(1/0)
- Enable/disable auto purge when set is called.
- auto_purge_on_get(1/0)
- Enable/disable auto purge when get is called.
- set($key, $value, [$seconds])
- Store an item ($value) with the associated $key.
Time to live (in seconds) can be optionally set with a third argument.
Returns true on success.
- add($key, $value, [$seconds])
- Only set in the cache if the key doesn't already exist.
- replace($key, $value, [$seconds])
- Only set in the cache if the key does exist.
- get($key)
- Locate and return the data associated with $key.
Returns the object associated with $key or undef
if the data doesn't exist. If auto_purge_on_get is enabled, the
cache will be purged before attempting to locate the item.
- get_bulk()
- Returns a hash reference containing every unexpired item from the cache
key'ed on their cache id. This can be useful if your keys aren't always
available or if you just want to use the cache as a convenient way to dump
data in chunks.
The result looks something like this:
my $h = $cache->get_bulk();
# $h = { 123 => "bird and bee",
# 456 => "monkeys with sticks",
# 789 => "take whats mine",
# };
- remove($key)
- Removes the cache element specified by $key if it
exists. Returns true for success.
- delete($key)
- Same as remove()
- clear()
- Completely clear out the cache and compact the underlying database.
Returns the number of cached items removed.
- count()
- Returns the number of items in the cache.
- size()
- Return the size (in bytes) of all the cached items. This call relies on
the availability of Devel::Size. If its not found, you'll get a
warning and size() will simply return 0. Currently the size is
calculated every time this is called by using
Devel::Size::total_size, so it may be expensive for large caches.
In the future size-aware options and functionality may be available, but
for now you'll need to implement this outside of Cache::BDB if you need
it.
- purge()
- Purge expired items from the cache. Returns the number of items
purged.
- is_expired($key)
- Returns true if the data pointed to by $key is
expired based on its stored expiration time. Returns false if the data
isn't expired *or* if the data doesn't exist.
(See http://www.sleepycat.com/docs/ref/am_misc/diskspace.html)
Before Berkeley DB release 4.4 it was not possible to return freed
space in a database file. This means that no matter how many items you
delete, your file will still retain its size, and continue to grow as you
add more items. The only way to get the file size back down was to dump the
database to a file and reload it into a new database file. This may or may
not be a problem for your application, but keep in mind that your cache will
continue to get bigger and, for example, your operating system may have a
maximum file size limit.
In 4.4, Sleepycat introduced the ability to free unused space.
BerkeleyDB 0.29 exposes this functionality in the perl wrapper. If you are
using these versions or better and have chosen the Btree database type (the
default for Cache::BDB), your caches will automatically be compacted when
items are purged, removed/deleted, or if clear is called. You can disable
the automatic compaction of cache files by initializing your Cache::BDB
object with the disable_compact parameter set to any true value. In my tests
so far, however, database compaction does not appear to affect performance
significantly, and may save you from a headache down the road.
Josh Rotenberg, "<joshrotenberg at
gmail.com>"
* Make data storage scheme configurable (Storable, YAML, Data::Dumper,
or callback based)
* Split storage between meta and data for faster operations on
meta data.
* Add some size/count aware features.
* Create some examples.
* Fix fork()'ing tests.
Please report any bugs or feature requests to
"bug-cache-bdb at
rt.cpan.org", or through the web interface at
<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Cache-BDB>. I will be
notified, and then you'll automatically be notified of progress on your bug as
I make changes.
You can find documentation for this module with the perldoc command.
perldoc Cache::BDB
You can also look for information at:
- AnnoCPAN: Annotated CPAN documentation
<http://annocpan.org/dist/Cache-BDB>
- CPAN Ratings
<http://cpanratings.perl.org/d/Cache-BDB>
- RT: CPAN's request tracker
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Cache-BDB>
- Search CPAN
<http://search.cpan.org/dist/Cache-BDB>
Baldur Kristinsson Sandy Jensen
Copyright 2006 Josh Rotenberg, all rights reserved.
This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
Hey! The above document had some coding errors, which are explained
below:
- Around line 126:
- Expected text after =item, not a bullet
- Around line 133:
- Expected text after =item, not a bullet
- Around line 158:
- Expected text after =item, not a bullet
- Around line 174:
- Expected text after =item, not a bullet
- Around line 198:
- Expected text after =item, not a bullet
- Around line 211:
- Expected text after =item, not a bullet
- Around line 216:
- Expected text after =item, not a bullet
- Around line 225:
- Expected text after =item, not a bullet
- Around line 231:
- Expected text after =item, not a bullet
- Around line 237:
- Expected text after =item, not a bullet
- Around line 241:
- Expected text after =item, not a bullet
- Around line 246:
- Expected text after =item, not a bullet
- Around line 250:
- Expected text after =item, not a bullet
- Around line 255:
- Expected text after =item, not a bullet
- Around line 261:
- Expected text after =item, not a bullet
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |