Иван Ворас (Ivan Voras), один из коммитеров FreeBSD, анонсировал (http://ivoras.sharanet.org/blog/tree/2011-10-11.bullet-cache...) новую систему для организации кэширования данных в оперативной памяти c хранением данных в формате ключ/значение - Bullet Cache (http://mdcached.sourceforge.net/). По своим возможностям и выполняемым задачам система очень близка (http://mdcached.sourceforge.net/UserGuide.html) к Memcached (http://memcached.org/) и отличается, главным образом, внутренней архитектурой, нацеленной на более активное использование многопоточности, и поддержкой тегов. Кроме того, в Bullet Cache реализовано несколько расширенных режимов для обращения к данным и определения их времени жизни в кэше, что позволяет предоставить приложению более полный контроль над содержимым кэша.
Код распространяется (http://sourceforge.net/projects/mdcached/files/mdcached/) под лицензией BSD (2-clause BSDL). Клиентские библиотеки пока доступны только для языков Си, ...URL: http://ivoras.sharanet.org/blog/tree/2011-10-11.bullet-cache...
Новость: http://www.opennet.me/opennews/art.shtml?num=32064
Очень хорошо! И то что нужно.
Библиотек теперь бы по больше!Где можно почитать про протокол? Если вдруг соберусь на написание своей библиотеки.
Миллион tps - это просто отличный результат!
Отличный от чего? В какую сторону? С чем сравнивалось?
> Отличный от чего? В какую сторону? С чем сравнивалось?Попробуйте сами сделать что-то подобное. Я такое делал, скажу вам что это challenge :)
Человек оринетируется на скорость и тащит текстовый SQL-подобный протокол? Пример Mysql его ничему не научил?
MySQL такой медленный потому что использует SQL-синтаксис? Внезапно!
Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).
> Внезапно, при выборке по первичному ключу (аналог key-value) у японцев получалось сильно поднять производительность, введя простой для разбора протокол вместо SQL (см. HandlerSocket).Что-то мне подсказывает, что производительность упиралась вовсе даже не в разбор SQL. Куда более сложный многомегабайтный PHP-код с кучей инклудов парсится (только парсится, без выполнения) быстрее в разы сотни-другой байт SQL-запроса, который при выполнении так нагружает базу.
Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.
> Тут подсказки интуиции не требуются - вся ифнормация есть в открытом виде. Идём на сайт HandlerSocket, читаем, при желании - сравниваем. Суть именно в том, что на простых быстрых запросах (по первичному ключу, например) скорость упирается в разбор SQL.А я не спорю, что MySQL может тормозить на разборе SQL, но в MySQL парсер не эталонный и пример с ним ничего не говорит о скорости работы парсера в сабже.
Не знаю, насколько он там не эталонный, но мой опыт подтверждает то, что лукап по хорошо оптимизированной струтуре данных по времени сравним с примитивным разбором строки из 10-15 байт, если блокировки не влезут.
> Не знаю, насколько он там не эталонный, но мой опыт подтверждает то,
> что лукап по хорошо оптимизированной струтуре данных по времени сравним с
> примитивным разбором строки из 10-15 байт, если блокировки не влезут.Тут речь идет о миллионе транзакций в секунду!
Если у mysql что то во что то упирается (на нагрузке на пару парядков меньше) то это его проблемы и вообще offtop!
Prepare Statement
ВНЕЗАПНО!
Может, прочтёте о чём вообще речь? А речь о том, что в шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы и там prepare реализовывать предложите?
:facepalm:Ещё раз. Распарсить много мегабайт чьего-бы то ни было синтаксиса - плёвое дело. Посмотри как быстро PHP парсит свои исходники. Ну ладно, не нравится PHP, возьми Python. Если в MySQL парсер такой кривой, то это исключительно его проблемы, а не проблемы синтаксиса. Ну замени ты SELECT UNIX_TIMESTAMP() на echo time(), по-твоему первый вариант дольше в десять раз будет парситься только потому что он в SQL-синтаксисе записан?
Плёвое дело по сравнению с чем? В запросом к диску - да сколько угодно. С генерацией страницы с кучей исполняемого кода и, возможно, теми же SQL-запросами - тем более. Но НЕ по сравнению с поиском в прилично оптимизированном хэше. Ну есть у меня этот опыт, так что знаю о чем говорю. В таких случаях надо использовать бинарные сериализованные форматы, которые парсить не надо вообще - тупо выгребать строки заранее известных размеров по заранее известным смещениям.Впрочем, если будет время - потестирую, что даёт избавление от парсинга в данном случае. Но процентов 10 скорости как минимум должно прибавиться (а скорее - около 30%).
Объясни как ты себе представляешь работу MySQL? На примере PHP я представляю примерно так:1. PHP -> 2. SQL-строка посылается в MySQL -> 3. парсинг строки в понятную MySQL команду -> 4. выполнение команды (поиск по базе) -> ...
По твоей логике 3-й пункт должен выполняться ну очень долго и являться основным тормозом. Я правильно понимаю?
Если там есть хоть какие-то сложные запросы - нет, конечно. См. японцев с HandlerSocket - проблема проявляется на простых запросах вида "SELECT name FROM table WHERE primaryKey=1" и подобных - то есть когда сам запрос выполняется мгновенно. Вот там уже парсинг SQL и обработка эскейпов чувствуется.Я вот чего не пойму: чего со мной-то спорить? Есть код, есть результаты тестирования - и не только автора кода, есть описание условий тестирования... что ещё нужно?
До тебя никак не дойдёт, что скорость поиска зависит от реализации. Неужели ты думаешь, что в эту крошечную библиотеку встроен полноценный SQL-парсер с поддержкой всех SQL-стандартов? Да тут по сути конечный автомат с максимум 10-20 состояниями, распарсить строку в 100 байт и понять, что хотят найти в кэше на нём можно за 0,000001 сек., если не меньше.Не смотрел на тестирования автора, я высказался касательно твоего утверждения, что SQL-подобные синтаксисы тормозные в принципе.
Я уже глянул в исходниках - нет там текстового синтаксиса, это дурной перевод. Есть нормальный бинарный формат и API-функции.И не надо приписывать мне то, что я не говорил.
Я НЕ ГОВОРИЛ, ЧТО SQL-ПОДОБНЫЕ СИНТАКСИСЫ ТОРМОЗНЫЕ В ПРИНЦИПЕ.
Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота.
> Я сказал, что для таких быстрых выборок, как поиск по primary key в Mysql и тем более - выборка из хеша оверхед на парсинг строки уже в 10-15 символов чувствуется очень хорошо. Потому что сам на это нарывался. А если эскейпы надо обрабатывать - так это вообще лишний memcpy, что ни в какие ворота.Ок. Но вообще говоря, лишний memcpy вполне сойдёт. Сколько их происходит при сложных выборках уже после собственно парсинга запроса... При тех же Using filesort. Капля в океане, я бы сказал.
О memcpy я речь вёл в контексте именно кэша, там вообще работы с диском нет, как и сложных запросов.
Нужно ещё понимание работы RDMS.
люди реально думают что базы данных данных настолько тупые насколько они умные )
весь мир живёт с медленным sql и не знает насколько он тормозной )а где тесты с Prepared Statements ?
ps http://www.theserverside.com/news/1365244/Why-Prepared-State...
Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache нет - именно по причине тормозности, на что и указывает автор в исходниках.
> Вопрос снят - никакого SQL и вообще текстового протокола в Bullet Cache
> нет - именно по причине тормозности, на что и указывает автор
> в исходниках.Просто в новости перевод кривой.
ну я ответил по поводу HandlerSocket
как я понял там жаловались на медленный парсинг в mysql
ну как раз для таких задач есть Prepared Statement (хотя тож есть недостатки)
и походу те парни ни слова не сказали про это (хотя я да же не читал оригинал)
http://msdn.microsoft.com/en-us/library/aa260835.aspx -- см. там раздел "The (so-called) Prepared property".
> Может, прочтёте о чём вообще речь? А речь о том, что в
> шустром кеше делать SQL-подобный синтаксис - нарываться на тормоза. Или вы
> и там prepare реализовывать предложите?Речь идёт о том что вы не умеете читать, и там нет никакого SQL.
Оставь. Нельзя (сложно) программиста php убедить в том что ассемблер суммирует быстрее, если он не знает что такое ассемблер. Большинство посетителей, как я понимаю, не сильны в реализации технологий, а видят лишь обложку. И по цвету обложки делают вывод о содержании.
Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки, и в результате получили ускорение - и получишь сотни восторженных отзывов что Debian/что-угодно лучшее, они давно сидят и рады что он лучше всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество идиотов не может ошибаться.
>> Кто-то проигнорирует, кто-то заинтересуется - народ здесь разный...
> Вряд ли. Напиши новость что в Debian/что-угодно внедрили инновацию и каждую команду
> исполняют дважды с последующим сравнением результатов чтобы исключить аппаратные ошибки,
> и в результате получили ускорение - и получишь сотни восторженных отзывов
> что Debian/что-угодно лучшее, они давно сидят и рады что он лучше
> всех. И они заклюют любого кто скажет что внедрили глупость. Сообщество
> идиотов не может ошибаться.Так на одного крикуна тысяча тех, кто молчит и читает.
Я не могу говорить конкретно за MySQL, однако, мне приходилось работать тестировщиком другой RDBMS(проприетарной). В общем, исходя из того, что я узнал, я сделал такие выводы: производительность падает не только (и, возможно, не столько) на разборе SQL, сколько при таких дальнейших операциях как загрузка метаданных(хотя они часто кэшируются), проверка существования указанных в запросе таблиц, колонок, проверка типов данных, приведение типов данных, составление плана запроса, его оптимизация, преобразование плана в специальное внутреннее представление и т.д. Собственно разбор SQL (синтаксический разбор) тоже играет роль, но явно не первую.
При этом полностью согласен с тем, что использование любого текстового протокола при работе с кэшем абсолютно бессмысленно, ибо в случае с кэшем, а не сложной RDBMS, накладные расходы на разбор текста будут относительно велики.
Прочитал я про HandlerSocket (кстати, спасибо за упоминание о нем). Стало несколько непонятно следующее: для чего в MySQL, который еще с 5ой версии поддерживает prepared statements, это нужно? Особенно учитывая то, что протокол HandlerSocket по сути текстовый (хотя и весьма компактный и простой). Может, кто-то объяснит?
А что уж сразу не британские ученые?
Тут же прямо сказано SQL подобный синтакисис! теги к ключам очень полезная штука. А те кто не хочет могут юзать свои регекспы.
Ну и откуда сие недоверие? Методика тестов, патчи, результаты - у них всё открыто. Можно проверить, что и сделала куча народу. А для этого чуда я, пожалуй, побалуюсь на досуге с аналогичным патчем - поглядим, что получится.Теги к ключам - полезная штука. А генерация SQL-подобного синтаксиса а потом его разбор - вредная. И больше шансов ошибку пропустить, которую иначе компилятор в нормальном языке поймал бы, и дурацкий код генерации запроса, и серверу работы больше, и для инъекций шансы могут появиться, если синтаксис достаточно богатый.
А не верите японцам вы зря - всё открыто и уже опробовано массой народу.
Классический пример "слышал звон, да не знаю где он" - основная нагрузка, за исключением выборки данных, приходится на query optimizer & planner, а не на разбор запроса, sql синтаксис тут совершенно не при чём.
Смеётесь? Нет там никакой нагрузки на планировщик при выборке по первичному ключу.
Тьфу, зря только ругался с неграмотными людьми. Скачал исходники, глянул - никакого 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-подобном синтаксисе.
Да Да. Только все сразу поняли о чем речь а вы нет.
Вы первоначальный текст новости не застали.
Библиотеки под Python пока нет:http://mdcached.svn.sourceforge.net/viewvc/mdcached/trunk/md...