Bullet cache emphasises performance and flexibility in two significant cases:
The first case is obvious from the benchmark results, but using record tags deserves a special discussion.
Properly using record tags can significantly improve the application performance. This page discusses some common ways in which caching can be improved by the use of tags, specifically regarding the problem of cache coherency (or simply: cache record expiry).
When talking about record tags, the notation {tag_key, tag_value} will be used to describe a single record tag. Each cached record can have an arbitrary number of tags assigned to it. The most important thing is that record tag operations are efficient! Due to their strict structure (a pair of signed integers), and internal indexing, bulk operations on record tags are extremely fast.
Consider that a fairly typical application needs to track various pieces of information, and one of the things which connects these pieces of data are the users which created them. In such an application, there could be thousands of records related to a single user, which for performance reasons need to be cached. In such a system, all these records need to be purged from the cache (i.e. "expired") when the user information changes: the application needs to display fresh user data.
By using Bullet cache record tags, the application defines a single tag key, e.g. "1" to mean "user ID" (assuming integer user IDs), and assigns the tag {1, $user_id} to every cached record referencing data created by the user whose numeric id is $user_id. Data expiry is then performed by the simple operation which can be described in SQL as DELETE FROM CACHE WHERE tag_key=1 AND tag_value=$user_id.
A subcase of inter-object dependancy are virtual-locality-based dependancies for application objects. For example, if the application data "belongs" to a forum thread, a page, a news item or some other grouping, and for some reason the cached data needs to be expired (maybe the page title has changed, or the news item has changed, or a forum thread was moved or changed), the records can be appropriatly tagged and all the cached items can be expired with a similar operation as in the previous case. Note that records can have arbitrary number of tags, so a record might for example have these tags: {1, $user_id}, {2, $page_id}, and {3, $news_id}, allowing efficient expiry of all cached data created by certain users, or all on a certain page, or all belonging to a certain news item.
The possibilities are endless, but for reasons of efficiency, it is preferrable that the records have up to 8 tags, and that the total number of unique tag keys stored in the cache server is not larger then 128 (there are no recommended maximums on the number of unique tag values). Luckily, these recommendations cover the intended use of record tags extremely well.