LINUX.ORG.RU

Релиз Microcached 1.0

 microcached,


1

4

Microcached — маленький и эффективный кэш-демон.

Здравствуйте, после многих лет работы с Memcached, я подумал, что было бы неплохо иметь под рукой похожий инструмент, который был бы таким же простым и удобным, и который давал бы возможность выполнять поиск среди ключей на стороне сервера, используя регулярные выражения. Мне всегда казалось, что выполнять мультизапрос на получение всех ключей и обрабатывать огромный массив этих ключей на стороне PHP — не самый лучший способ получить нужные данные.

Целью было создать быстрый кэш сервер, простой и удобный, как молоток.

Хочу представить сообществу продукт своего труда — маленький и эффективный кэш-демон Microcached 1.0.

Среди поддерживаемых платформ на данный момент только операционные системы на базе ядра Linux.

Основные возможности демона:

  • Маленький и эффективный, написан исключительно на Си, используется механизм опроса файловых дескрипторов Linux epoll API;
  • возможность работать с кэш-записями размером до 4ГБ ОЗУ (суммарное ограничение для одной записи);
  • очень простой, такой же простой, как и Memcached;
  • позволяет выполнять запросы на фильтрацию/удаление ключей (и записей, ассоциированных с ними) за счет использования регулярных выражений PCRE;
  • предоставляет простой и понятный клиентский интерфейс, бинарный протокол общения между клиентом и сервером.

Лицензия MIT.

>>> Подробности



Проверено: Falcon-peregrinus ()
Последнее исправление: DeadEye (всего исправлений: 4)

А в memcached или redis впилить pcre выборку ключей можно? по идее перспективней

anonymous
()
Ответ на: комментарий от anonymous

В redis есть keys. А пилить Memcached я не видел перспектив. К тому же, Microcached имеет несколько иную политику инвалидации кэш-записей. Записи не удаляются в случае memory allocation failure (если в системе нет свободной памяти) при добавлении новой записи, любая запись, которая была успешно записана в хранилище, гарантированно будет существовать до TTL (при условии что сам демон работает).

excanoe
() автор топика
Ответ на: комментарий от zyoung

Это суммарное ограничение для одной записи, возможно не совсем точно выразился в тексте новости, но исправить не могу.

excanoe
() автор топика

только операционные системы на базе ядра Linux

просто эталонное «нинужно»

anonymous
()
Ответ на: комментарий от Kilte

Спасибо за ссылку, оставил там сообщение с просьбой поправить текст.

excanoe
() автор топика

создать быстрый кэш сервер, простой и удобный, как молоток.

Перед тем как мы дойдем до простоты, объясни что такое кеш-сервер в твоем случае.

Xintrea ★★★★★
()
Ответ на: комментарий от excanoe

Я может быть, непонятно написал, но повторюсь: что такое кеш-сервер в твоем случае?

Не кеш, а кеш-сервер. Не абстрактный, а в твоей реализации.

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

Я не уверен, что понимаю ваш вопрос, но в моей реализации, это однопоточный tcp/ip сервер, очень похожий по функционалу на Memcached, но с возможностью фильтрации множества ключей используя регулярные выражения.

excanoe
() автор топика
Ответ на: комментарий от stalkerhouse

Для каких? Для апача, для nginx, для встроенного в питон? Для каких БД? Через какой API? Каким методом происходит подмена данных из базы и из кеша?

Xintrea ★★★★★
()

только операционные системы на базе ядра Linux.

Лицензия MIT.

anonymous
()

А есть сравнения по производительности с Memcached/Redis?

Умеет ли держать постоянный коннект?

Для каких ЯП есть реализации клиентов и выполнены они на нативном коде или как расширения?

WARNING ★★★★
()
Ответ на: комментарий от WARNING

Я сравнивал с Redis операцию set, на своем рабочем окружении (виртуальная нода, 16 гб ОЗУ, два ядра AMD FX-8320) получал 100k операций в секунду с Redis и столько же получал используя Microcached используя 10 клиентских потоков.

Постоянное соединение частичное, соединение держится в контексте одного запроса PHP. Когда запрос PHP выполнен, сокет закрывается. Абсолютно постоянные соединения я считаю не самым лучшим решением. Со стороны сервера, все соединения персистентны.

На данный момент доступна реализация клиента на PHP, это эталонная реализация клиента, со временем более детально опишу принцип работы протокола и сам протокол. Клиент написан на PHP.

excanoe
() автор топика

Позволяет выполнять запросы на фильтрацию/удаление ключей (и записей ассоциированных с ними) благодаря библиотеке регулярных выражений PCRE.

эффективный

Не хотелось бы тебя огорчать, бро, но это взаимоисключающие параграфы. Чтобы *эффективно* выцепить из коллекции ключи, соответствующие регулярке, pcre не годится. Посмотри, как это делают дяди из гугла и прочие ботаники: https://wiki.postgresql.org/images/6/6c/Index_support_for_regular_expression_...

Во-всяком случае, пока ты не сделаешь бенчмарков против честно затюненного постгреса (чтобы он поменьше дрочил жесткий диск и журналы свои), CREATE INDEX trgm_idx + SELECT LIKE, твоя поделка выглядит крайне неубедительно.

используется механизм опроса файловых дескрипторов Linux epoll API

А почему не libevent?

Manhunt ★★★★★
()
Ответ на: комментарий от excanoe

Клиент написан на PHP

Блин, я конечно понимаю, что первые релиз, всё такое, но если хочешь чтоб использовалось хоть кем-то - пили libmicroclient.so

anonymous
()
Ответ на: комментарий от Wizard_

Изначально я разрабатывал версию с использованием sqlite, там есть теги, но ввиду меньшей скорости (порядка 25k запросов в секунду против 100k) я пока поставил на паузу, если людям будет интересно, реализую отдельную версию с sqlite и тегами. И там не греп, а глоб.

excanoe
() автор топика

Зачем, если есть редис?
Шардинга нет, репликации нет, скорость та же. Так в чем смысл?

iSage ★★★★
()
Ответ на: комментарий от Manhunt

Фильтрацию/удаление ключей и «эффективный» я не ставил в одном предложении, мне известно о скорости PCRE.

excanoe
() автор топика
Ответ на: комментарий от anonymous

Обязательно подумаю над этим, благодарю за конструктив.

excanoe
() автор топика
Ответ на: комментарий от excanoe

Так ведь единственное преимущество твоей поделки перед конкурентами — это поддержка регулярок. Если при этом регулярки у тебя работают не слишком эффективно, то зачем вообще все это нужно?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Я не считаю и не позиционирую свой маленький проект как конкурент другим серверам, я создал инструмент, который в первую очередь удобен лично мне, что очевидно, а дальше лишь время покажет.

Поделиться с сообществом своими наработками, я считаю это всегда хорошо.

excanoe
() автор топика
Ответ на: комментарий от excanoe

Поделиться с сообществом своими наработками, я считаю это всегда хорошо.

Ну, хуже от этого точно не станет :)

Желаю тебе удачи в развитии microcached, много энтузиазма и терпения

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Еще бы добавил, что лично я считаю Redis и Memcached замечательными инструментами, мой демон, для тех, кому нужен простой инструмент. Для тех кому нужно что-то большее, можно сказать что есть Redis.

Я позиционирую Microcached не против других, а вместе с другими.

excanoe
() автор топика
Ответ на: комментарий от anonymous

Из описания я так понял, что из linux-only там в основном завязка на epoll. Я бы советовал автору не страдать ерундой, взять libev, или libuv и получить кросс-платформенное решение.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

нинужно

Здравствуйте!

Это слово пишется так: «Давай, давай!».

anonymous
()

https://bitbucket.org/excanoe/microcached/src/3604644b1e079685b6c9905ddb75bc6... - лучше бы тут подправить форматирование, ну чтобы без этих }}. И вот этот момент int nn; int mm = 1 << (ctx->level - page->level); for (nn = 0; nn < mm; nn++) { с for-ом на одной строчке с объявлением переменной, не очень хорошо. И еще сдвиг единицы... Надеюсь есть гарантия, что ctx->level - page->level не будет отрицательным

SZT ★★★★★
()
Ответ на: комментарий от DELIRIUM

Из описания я так понял, что из linux-only там в основном завязка на epoll. Я бы советовал автору не страдать ерундой, взять libev, или libuv и получить кросс-платформенное решение.

Так кроме epoll нет ничего больше кроме kqueue. Проще написать парочку ifdef-ов и добавить поддержку kqueue, чем юзать целую либо для этого, не?

Вспоминается болезнь «кроссплатформенного» аудио, когда разрабы вместо поддержки alsa библиотеки юзают какие-то костыли типа portaudio

reprimand ★★★★★
()

А библиотечку libev/libuv/<что угодно другое> не использовал по какой причине?

anonymous
()
Ответ на: комментарий от reprimand

Так кроме epoll нет ничего больше кроме kqueue

Но Solaris /dev/poll есть. На винде что-то своё (не помню, что, но libuv/ev на винде работают).

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от excanoe

Абсолютно постоянные соединения я считаю не самым лучшим решением.

Из личного опыта. При запросе в мемкэш, стоящий на другом сервере, но в одной локальной сети, больше половины времени выполнения запроса уходит на открытие соединения.

Про .so уже сказали ниже. Без этого просто никак.

WARNING ★★★★
()
Ответ на: комментарий от anonymous

Я предпочитаю избегать абстракций, если могу решить задачу напрямую.

Задача была простая - написать linux демон. Поддержка других операционных систем не планировалась, но в будущем все может измениться.

Главное чтобы было здоровье :)

excanoe
() автор топика
Ответ на: комментарий от WARNING

Благодарю за информацию, я учту конструктивные замечания. Проблема персистентных соединений мне не одну ночь испортила.

excanoe
() автор топика
Ответ на: комментарий от excanoe

Я сравнивал с Redis операцию set,

вообще, связка редис + селери почему-то создает проблемы
при достижении некоторого количества ключей в редисе селери начинает сильно напрягаться

kto_tama ★★★★★
()
Ответ на: комментарий от excanoe

Задача была простая - написать linux демон. Поддержка других операционных систем не планировалась, но в будущем все может измениться.

да и не надо других операционных систем

kto_tama ★★★★★
()
Ответ на: Psy от Camel

А как же!

excanoe
() автор топика
Ответ на: комментарий от DELIRIUM

Solaris

Емнип solaris сейчас разве что под БД и ZFS хранилища используют. Не слышал чтобы ее юзали как веб сервер (с php на борту, лол)

reprimand ★★★★★
()
Ответ на: комментарий от excanoe

эээ, так это у тебя не кэш, а немножко БД получилась, LRU - это же главная фишка кэша, позволяющая «всплывать» более часто используемым записям и «тонуть» менее нужным

vitalif ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.