Bullet Cache - высокопроизводительная система кэширования данных в памяти

Иван Ворас (Ivan Voras), один из коммитеров FreeBSD, анонсировал [2] новую систему для организации кэширования данных в оперативной памяти c хранением данных в формате ключ/значение - Bullet Cache [3]. По своим возможностям и выполняемым задачам система очень близка [4] к Memcached [5] и отличается, главным образом, внутренней архитектурой, нацеленной на более активное использование многопоточности, поддержкой тегов и бинарным протоколом взаимодействия клиента и сервера, так как, по мнению разработчика, на парсинг текстовых протоколов в memcached и sqlcached тратится слишком много времени. Кроме того, в Bullet Cache реализовано несколько расширенных режимов для обращения к данным и определения их времени жизни в кэше, что позволяет предоставить приложению более полный контроль над содержимым кэша.
Код распространяется [6] под лицензией BSD (2-clause BSDL). Клиентские библиотеки пока доступны только для языков Си, Python и PHP. Разработка Bullet Cache началась ещё в 2005 году, в нынешнем году интерес к проекту возродился и он был достаточно быстро доведен до стадии бета-версии, на которой он и находится в настоящее время. Изначально проект распространялся под кодовым именем mdcached (multi-domain cache daemon), но, в конечном счете, для избежания путаницы имя было заменено на Bullet Cache.
Bullet Cache изначально рассчитан на обработку большого объема параллельных запросов, что позволяет добиться [7] заметного выигрыша в производительности на высоконагруженных серверах с многоядерными процессорами. Дополнительно отмечается использование высоко эффективных методов организации ввода/вывода и сетевого протокола, позволяющего добиться максимальной производительности при выполнении операций "GET" без лишнего копирования данных в памяти ( без вызова malloc(), realloc() и memcpy()). Тестирование производительности показало [8], что на обычном оборудовании (CPU Xeon 3440 2.5 GHz) система способна обработать около миллиона транзакций в секунду при смешанном выполнении операций чтения и записи в типичном для нагруженных web-проектов соотношении 90% / 10%.

Для минимизации времени на "прогрев" кэша предусмотрена возможность периодического сброса состояния кэша в файл с последующей возможностью загрузки содержимого кэша из файла на этапе запуска процесса. При хранении данных возможна привязка к записям дополнительных мета-данных, задаваемых в форме тегов. Поддержка привязки тегов значительно упрощает операции группировки данных, позволяя формировать выборки, охватывающие сразу несколько записей. Условия для запросов с участием тегов могут быть множественными, на псевдо-SQL это выгядело бы, например, так: "
GET RECORDS WHERE tag_key=... AND tag_values IN (...)" или "DELETE RECORDS WHERE tag_key=... AND tag_values IN (...)". Возможна организация таких структур, как виртуальный стек тегов (FIFO) и очередь сообщений.
В качестве ключа для идентификации отдельной записи может использовать любой набор данных (не обязательно строка), размером до 64 Кб. Максимальный размер связываемой с ключом записи - 2 Гб. Для каждой записи указывается время жизни, которое может быть определено как число секунд с момента добавления, так и в форме обычной даты в эпохальном формате. Также имеется встроенная поддержка операций для добавления или удаления за один шаг больших порций данных, которые более эффективны и удобны по сравнению с перебором каждого ключа. Из дополнительных операций можно упомянуть: CMPSET для установки значения только если в записи уже определено заданное значение, FETCHADD для возвращения прошлого значения с последующим добавлением данных, READANDCLEAR для возвращения прошлого значения с последующей очисткой записи.