The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

18.10.2011 11:45

Иван Ворас (Ivan Voras), один из коммитеров FreeBSD, анонсировал новую систему для организации кэширования данных в оперативной памяти c хранением данных в формате ключ/значение - Bullet Cache. По своим возможностям и выполняемым задачам система очень близка к Memcached и отличается, главным образом, внутренней архитектурой, нацеленной на более активное использование многопоточности, поддержкой тегов и бинарным протоколом взаимодействия клиента и сервера, так как, по мнению разработчика, на парсинг текстовых протоколов в memcached и sqlcached тратится слишком много времени. Кроме того, в Bullet Cache реализовано несколько расширенных режимов для обращения к данным и определения их времени жизни в кэше, что позволяет предоставить приложению более полный контроль над содержимым кэша.

Код распространяется под лицензией BSD (2-clause BSDL). Клиентские библиотеки пока доступны только для языков Си, Python и PHP. Разработка Bullet Cache началась ещё в 2005 году, в нынешнем году интерес к проекту возродился и он был достаточно быстро доведен до стадии бета-версии, на которой он и находится в настоящее время. Изначально проект распространялся под кодовым именем mdcached (multi-domain cache daemon), но, в конечном счете, для избежания путаницы имя было заменено на Bullet Cache.

Bullet Cache изначально рассчитан на обработку большого объема параллельных запросов, что позволяет добиться заметного выигрыша в производительности на высоконагруженных серверах с многоядерными процессорами. Дополнительно отмечается использование высоко эффективных методов организации ввода/вывода и сетевого протокола, позволяющего добиться максимальной производительности при выполнении операций "GET" без лишнего копирования данных в памяти ( без вызова malloc(), realloc() и memcpy()). Тестирование производительности показало, что на обычном оборудовании (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 для возвращения прошлого значения с последующей очисткой записи.

  1. Главная ссылка к новости (http://ivoras.sharanet.org/blo...)
  2. OpenNews: Создатели CouchDB и SQLite представили UnQL, аналог SQL для систем NoSQL
  3. OpenNews: Релиз Apache БД Cassandra 0.8.0
  4. OpenNews: Первый стабильный релиз СУБД Membase Server
  5. OpenNews: Mycached - дополнение для организации обращения к MySQL по протоколу memcached
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/32064-memcached
Ключевые слова: memcached, cache, bulletcache, mdcached
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (42) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 13:08, 18/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень хорошо! И то что нужно.
    Библиотек теперь бы по больше!

    Где можно почитать про протокол? Если вдруг соберусь на написание своей библиотеки.

     
  • 1.2, Erley (ok), 13:13, 18/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Миллион tps - это просто отличный результат!
     
     
  • 2.6, Аноним (-), 13:21, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Отличный от чего? В какую сторону? С чем сравнивалось?
     
     
  • 3.7, Erley (ok), 13:39, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Отличный от чего? В какую сторону? С чем сравнивалось?

    Попробуйте сами сделать что-то подобное. Я такое делал, скажу вам что это challenge :)

     

  • 1.3, Crazy Alex (ok), 13:13, 18/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Человек оринетируется на скорость и тащит текстовый SQL-подобный протокол? Пример Mysql его ничему не научил?
     
     
  • 2.4, Аноним (-), 13:15, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    MySQL такой медленный потому что использует SQL-синтаксис? Внезапно!
     
     
  • 3.5, Crazy Alex (ok), 13:19, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).
     
     
  • 4.8, Аноним (-), 13:40, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).

    Что-то мне подсказывает, что производительность упиралась вовсе даже не в разбор SQL. Куда более сложный многомегабайтный PHP-код с кучей инклудов парсится (только парсится, без выполнения) быстрее в разы сотни-другой байт SQL-запроса, который при выполнении так нагружает базу.

     
     
  • 5.10, Crazy Alex (??), 14:11, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.
     
     
  • 6.11, Аноним (-), 14:17, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.

    А я не спорю, что MySQL может тормозить на разборе SQL, но в MySQL парсер не эталонный и пример с ним ничего не говорит о скорости работы парсера в сабже.

     
     
  • 7.15, Crazy Alex (ok), 14:47, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, насколько он там не эталонный, но мой опыт подтверждает то, что лукап по хорошо оптимизированной струтуре данных по времени сравним с примитивным разбором строки из 10-15 байт, если блокировки не влезут.
     
     
  • 8.19, Аноним (-), 15:10, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тут речь идет о миллионе транзакций в секунду Если у mysql что то во что то упи... текст свёрнут, показать
     
  • 6.12, опроро (?), 14:34, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Prepare Statement
    ВНЕЗАПНО!
     
     
  • 7.13, Crazy Alex (ok), 14:43, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Может, прочтёте о чём вообще речь? А речь о том, что в шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы и там prepare реализовывать предложите?
     
     
  • 8.20, Аноним (-), 15:30, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    facepalm Ещё раз Распарсить много мегабайт чьего-бы то ни было синтаксиса - п... текст свёрнут, показать
     
     
  • 9.24, Crazy Alex (??), 15:52, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Плёвое дело по сравнению с чем В запросом к диску - да сколько угодно С генера... текст свёрнут, показать
     
     
  • 10.26, Аноним (-), 16:12, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Объясни как ты себе представляешь работу MySQL На примере PHP я представляю при... текст свёрнут, показать
     
     
  • 11.29, Crazy Alex (??), 16:16, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если там есть хоть какие-то сложные запросы - нет, конечно См японцев с Handle... текст свёрнут, показать
     
     
  • 12.30, Аноним (-), 16:30, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    До тебя никак не дойдёт, что скорость поиска зависит от реализации Неужели ты д... текст свёрнут, показать
     
     
  • 13.33, Crazy Alex (ok), 17:11, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я уже глянул в исходниках - нет там текстового синтаксиса, это дурной перевод Е... текст свёрнут, показать
     
     
  • 14.35, Аноним (-), 17:28, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ок Но вообще говоря, лишний memcpy вполне сойдёт Сколько их происходит при сло... текст свёрнут, показать
     
     
  • 15.36, Crazy Alex (ok), 17:47, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    О memcpy я речь вёл в контексте именно кэша, там вообще работы с диском нет, как... текст свёрнут, показать
     
  • 12.32, Грустный Анон (?), 16:54, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нужно ещё понимание работы RDMS ... текст свёрнут, показать
     
  • 8.21, опроро (?), 15:31, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    люди реально думают что базы данных данных настолько тупые насколько они умные ... текст свёрнут, показать
     
     
  • 9.27, Crazy Alex (??), 16:12, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache нет - им... текст свёрнут, показать
     
     
  • 10.28, Crazy Alex (??), 16:13, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Просто в новости перевод кривой ... текст свёрнут, показать
     
     
  • 11.39, опроро (?), 20:11, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ну я ответил по поводу HandlerSocket как я понял там жаловались на медленный пар... текст свёрнут, показать
     
  • 9.37, Аноним (-), 20:04, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    http msdn microsoft com en-us library aa260835 aspx -- см там раздел The so... текст свёрнут, показать
     
  • 8.42, Аноним (-), 22:57, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Речь идёт о том что вы не умеете читать, и там нет никакого SQL ... текст свёрнут, показать
     
  • 6.14, Аноним (-), 14:44, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Оставь. Нельзя (сложно) программиста php убедить в том что ассемблер суммирует быстрее, если он не знает что такое ассемблер. Большинство посетителей, как я понимаю, не сильны в реализации технологий, а видят лишь обложку. И по цвету обложки делают вывод о содержании.
     
     
  • 7.16, Crazy Alex (ok), 14:49, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
     
     
  • 8.17, Аноним (-), 14:52, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд ли Напиши новость что в Debian что-угодно внедрили инновацию и каждую кома... текст свёрнут, показать
     
     
  • 9.23, Crazy Alex (??), 15:43, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так на одного крикуна тысяча тех, кто молчит и читает ... текст свёрнут, показать
     
  • 6.40, Школьник (ok), 22:16, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я не могу говорить конкретно за MySQL, однако, мне приходилось работать тестировщиком другой RDBMS(проприетарной). В общем, исходя из того, что я узнал, я сделал такие выводы: производительность падает не только (и, возможно, не столько) на разборе SQL, сколько при таких дальнейших операциях как загрузка метаданных(хотя они часто кэшируются), проверка существования указанных в запросе таблиц, колонок, проверка типов данных, приведение типов данных, составление плана запроса, его оптимизация, преобразование плана в специальное внутреннее представление и т.д. Собственно разбор SQL (синтаксический разбор) тоже играет роль, но явно не первую.
    При этом полностью согласен с тем, что использование любого текстового протокола при работе с кэшем абсолютно бессмысленно, ибо в случае с кэшем, а не сложной RDBMS,  накладные расходы на разбор текста будут относительно велики.
    Прочитал я про HandlerSocket (кстати, спасибо за упоминание о нем). Стало несколько непонятно следующее: для чего в MySQL, который еще с 5ой версии поддерживает prepared statements, это нужно? Особенно учитывая то, что протокол HandlerSocket по сути текстовый (хотя и весьма компактный и простой). Может, кто-то объяснит?
     
  • 4.18, Аноним (-), 15:07, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А что уж сразу не британские ученые?
    Тут же прямо сказано SQL подобный синтакисис! теги к ключам очень полезная штука. А те кто не хочет могут юзать свои регекспы.
     
     
  • 5.22, Crazy Alex (??), 15:42, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и откуда сие недоверие? Методика тестов, патчи, результаты - у них всё открыто. Можно проверить, что и сделала куча народу. А для этого чуда я, пожалуй, побалуюсь на досуге с аналогичным патчем - поглядим, что получится.

    Теги к ключам - полезная штука. А генерация SQL-подобного синтаксиса а потом его разбор - вредная. И больше шансов ошибку пропустить, которую иначе компилятор в нормальном языке поймал бы, и дурацкий код генерации запроса, и серверу работы больше, и для инъекций шансы могут появиться, если синтаксис достаточно богатый.

    А не верите японцам вы зря - всё открыто и уже опробовано массой народу.

     
  • 4.31, Грустный Анон (?), 16:48, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Классический пример "слышал звон, да не знаю где он" - основная нагрузка, за исключением выборки данных, приходится на query optimizer & planner, а не на разбор запроса, sql синтаксис тут совершенно не при чём.
     
     
  • 5.34, Crazy Alex (ok), 17:13, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Смеётесь? Нет там никакой нагрузки на планировщик при выборке по первичному ключу.
     

  • 1.25, Crazy Alex (??), 16:03, 18/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Тьфу, зря только ругался с неграмотными людьми. Скачал исходники, глянул - никакого SQL-like syntex там нет, а есть набор API-функций и бинарный протокол, как и должно быть. Больше того - вот что пишет разработчик: "The network protocol will be binary. Empirically, too much time is spent in parsing text protocols in memcached and sqlcached."

    Чушь об SQL-подобном виде взята вот отсюда:
    Among others, Bullet cache implements the following multiple-data instructions which act on the record tags (described semantically in a SQL-like way):

    GET RECORDS WHERE tag_key=... AND tag_values IN (...)
    DELETE RECORDS WHERE tag_key=... AND tag_values IN (...)

    Другими словами, разработчик не стал приводить свои функции API, а показал иллюстрацию в SQL-подобном синтаксисе.

     
     
  • 2.38, Аноним (-), 20:10, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Да Да. Только все сразу поняли о чем речь а вы нет.
     
     
  • 3.43, Crazy Alex (ok), 01:48, 20/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вы первоначальный текст новости не застали.
     

  • 1.44, Аноним (-), 23:06, 20/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Библиотеки под Python пока нет:

    http://mdcached.svn.sourceforge.net/viewvc/mdcached/trunk/mdcached/client_py/

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру