В рамках проекта Mycached (http://coderepos.org/share/browser/platform/mysql/mycached/) реализована (http://developer.cybozu.co.jp/kazuho/2009/08/mycached-memcac...) поддержка протокола memcached для обращения к MySQL базам, т.е. дает возможность обратиться к существующей MySQL базе не через SQL запрос, а через протокол memcached. Проект выступает своего рода противоположностью memcached хранилища к MySQL, позволяющему обращаться к внешнему mymcached серверу через стандартные SQL команды.
По задумке авторов Mycached, прямой запрос ключей из хранилища, позволит оптимизировать скорость выполнения запросов, благодаря пропуску шагов по парсингу SQL и планированию выполнения запроса. При предварительном тестировании, в простейших запросах, обращение по протоколу memcached оказалось в два раза быстрее, чем выполнение стандартных SQL запросов, обеспечив при этом значительное опережение в плане организации параллельных запросов к базе. Mycached позволяет комбинировать гибкост...URL: http://developer.cybozu.co.jp/kazuho/2009/08/mycached-memcac...
Новость: http://www.opennet.me/opennews/art.shtml?num=23186
Идея интересна, но все же сомневаюсь что сейчас даст производительность лучше самого мемкэша. К тому же, идея доставлять любое количество серверов под кэш, - легкая масштабируемость оригинального мемкэш - это очень удобно. Как здесь с этим?
это примочка для доступа в *существующую* базу, а не замена мемкешубазой можно управлять по прежнему, а вот чтение данных - выполняется напрямую, минуя всякие прослойки
эээ, а prepaired statements не решит проблему парсинга?
>эээ, а prepaired statements не решит проблему парсинга?а планирование запроса?
>Mycached позволяет комбинировать гибкость MySQL
>с высокой производительностью решений подобных MemcacheDB
>(модифицированная версия memcached с сохранением кэша на диск
>в Berkeley DB базе)."гибкость" говорите :)
В общем "не то - ни сё", вроде бы как пуля, но чего то дурно пахнет :)
Гибкость она в SQL, а его потеряли, скорость - она в Berkeley DB, а тут мыскыл ... Вобщем снова "... слона и трепетную лань" :)
PS: Чет зацепило :) Прикиньте бизнес логику на протоколе memcaсhed _вместо_ SQL ... %-/ Не-не чур меня! Кэшу - кэшево, базе - базово!
>[оверквотинг удален]
>В общем "не то - ни сё", вроде бы как пуля, но
>чего то дурно пахнет :)
>Гибкость она в SQL, а его потеряли, скорость - она в Berkeley
>DB, а тут мыскыл ... Вобщем снова "... слона и трепетную
>лань" :)
>
>
>PS: Чет зацепило :) Прикиньте бизнес логику на протоколе memcaсhed _вместо_ SQL
>... %-/ Не-не чур меня! Кэшу - кэшево, базе - базово!
>это решение одной узкой задачи - выборка значений по ключу
нужны сложные выборки - юзайте параллельно обычный SQL со всеми наворотами. одно другого не исключает, как я понимаю
интереснее узнать какое тут преимущество по сравнению с доступом через handler ?
Если лично для Вас данная возможность не нужна/не понятна, это не означает что она не нужна никому.У меня есть один сервис использующий в основном memcacheQ/mecacheDB, но периодически подключающийся к MySQL базе. Благодаря данному проекту появилась возможность убрать лишний код и при этом получить двукратный выигрыш по скорости.
Спасибо, разработчикам. Минус в карму недальновидным критикам.
Спасибо за пример