Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
достойная замена memcached, спасибо
Нормальные бенчмарки в сравнении с оттюненным memcached увидеть.
Тогда и можно о достойной замене говорить.
Пока таких не видел.
Тогда и можно о достойной замене говорить.
Пока таких не видел.
Можно было бы тупо послать матчасть учить, да ладно не буду :-)
«Memcached хранит в памяти только ключ -> значение.
Смысл же Redis хранить ключ -> (значение1; значение2;…; значениеN). В основном, конечно.»
Memcached предназначен для кеширования, а редис для персистент хранения. Они вообще то этим отличаются. В основном :-)
И это принципиально разные продукты и использовать их нужно каждый для своих задач.
«Что вы тут предлагаете сравнивать? Сколько каждый тратит на выборку из памяти? Наверное, одинаково, если память одинаковая. „
Здесь не сдержусь — матчасть подучите. В части конкурентного доступа из разных тредов, что и когда лочится, как обеспечивается атомарность операций и вообще кто и чего делает. Где ботленек у кого. Что делает мемкешед я знаю, что делает редис — нет. Вот только редис в любом случае делает больше…
“По-моему, делать бенчмарк довольно глупо в том смысле, что вы будете сравнивать молоток с циркулярной пилой. Это немного разные инструменты по своей природе. Хотя циркулярной пилой можно попробовать забивать гвозди, а молотком попробовать пилить доски.»
Если бы вы были хотя бы немного внимательны, то наверняка заметили бы одну деталь. Мой пост был ответом на утверждение:
«достойная замена memcached, спасибо»
Под заменой заменой я понимаю продукт который умеет все, что умеет заменяемый как минимум не хуже и дополнительные возможности. В данном случае это не так. Нет данных по производительности и отсутствует LRU, который вообще то в редисе как бы и не к чему :-)
Вот только если редис вместо memcached использовать, то LRU руками городить нужно, а это я вам скажу дело не очень благодарное. Но нужное, особенно в свете известной проблемы редиса со свапом.
Если бы вы адресовали утверждение
«Это немного разные инструменты по своей природе. Хотя циркулярной пилой можно попробовать забивать гвозди, а молотком попробовать пилить доски.»
первому посту, это было бы абсолютно логично, а так, если выражаться политкорректно — это глупость.
«Кстати, и наверное количество плюсов на вашей комментарии, естественно незаслуженное, как раз отражает реальность того, что люди не видят дальше своего носа. Вот он хвалит мемкеш, а я его знаю. Плюс ему. Это так, философское :) „
Философ из вас тоже не очень. Найти в моем посте то что мне нравится или не нравится. Воображение у вас однако :-)
Мне к примеру в мемкешед тоже кое что не нравится. Могли бы к примеру при set'е cas отдавать. Причем реализовать это не так уж и сложно. Все примочки с тегированием нафиг бы были не нужны. Вот только не делают почему то :-(
Ну а про плюсы и нравится
У кого чего болит
:-)
«Memcached хранит в памяти только ключ -> значение.
Смысл же Redis хранить ключ -> (значение1; значение2;…; значениеN). В основном, конечно.»
Memcached предназначен для кеширования, а редис для персистент хранения. Они вообще то этим отличаются. В основном :-)
И это принципиально разные продукты и использовать их нужно каждый для своих задач.
«Что вы тут предлагаете сравнивать? Сколько каждый тратит на выборку из памяти? Наверное, одинаково, если память одинаковая. „
Здесь не сдержусь — матчасть подучите. В части конкурентного доступа из разных тредов, что и когда лочится, как обеспечивается атомарность операций и вообще кто и чего делает. Где ботленек у кого. Что делает мемкешед я знаю, что делает редис — нет. Вот только редис в любом случае делает больше…
“По-моему, делать бенчмарк довольно глупо в том смысле, что вы будете сравнивать молоток с циркулярной пилой. Это немного разные инструменты по своей природе. Хотя циркулярной пилой можно попробовать забивать гвозди, а молотком попробовать пилить доски.»
Если бы вы были хотя бы немного внимательны, то наверняка заметили бы одну деталь. Мой пост был ответом на утверждение:
«достойная замена memcached, спасибо»
Под заменой заменой я понимаю продукт который умеет все, что умеет заменяемый как минимум не хуже и дополнительные возможности. В данном случае это не так. Нет данных по производительности и отсутствует LRU, который вообще то в редисе как бы и не к чему :-)
Вот только если редис вместо memcached использовать, то LRU руками городить нужно, а это я вам скажу дело не очень благодарное. Но нужное, особенно в свете известной проблемы редиса со свапом.
Если бы вы адресовали утверждение
«Это немного разные инструменты по своей природе. Хотя циркулярной пилой можно попробовать забивать гвозди, а молотком попробовать пилить доски.»
первому посту, это было бы абсолютно логично, а так, если выражаться политкорректно — это глупость.
«Кстати, и наверное количество плюсов на вашей комментарии, естественно незаслуженное, как раз отражает реальность того, что люди не видят дальше своего носа. Вот он хвалит мемкеш, а я его знаю. Плюс ему. Это так, философское :) „
Философ из вас тоже не очень. Найти в моем посте то что мне нравится или не нравится. Воображение у вас однако :-)
Мне к примеру в мемкешед тоже кое что не нравится. Могли бы к примеру при set'е cas отдавать. Причем реализовать это не так уж и сложно. Все примочки с тегированием нафиг бы были не нужны. Вот только не делают почему то :-(
Ну а про плюсы и нравится
У кого чего болит
:-)
Есть ли возможность группировать ключи, а затем очищать всю группу?
Можно привести пример, как в редиске звучик аналог «select * from table»?
Редиска, Кохана!..
:)
:)
Append Only File нормально работает?
У него принцип — после снапшопа накапливать бинлоги, потом полный снапшот и по кругу, или апдейтит снапшоп на основе бинлогов параллельным тредом?
Как выглядит %id во время создания/апдейта снапшота?
У него принцип — после снапшопа накапливать бинлоги, потом полный снапшот и по кругу, или апдейтит снапшоп на основе бинлогов параллельным тредом?
Как выглядит %id во время создания/апдейта снапшота?
Мы пока используем старый вариант («снапшоты») и Append Only File еще не тестировали.
Схема следующая: ведется бинлог изменений, и при старте редиса изменения из него подсасываются в базу. Подробнее об этом можно почитать в вики проекта.
Плюсы этой схемы — при падении редиса при обычной схеме вы теряли данные которые были добавлены в промежуток снапшота. В данном случае вы не теряете данные.
Минусы — размер бин лога растет, и сейчас у редиса нету встроенных средств ротации, для этого используется комманда BGREWRITEAOF.
Мне кажется что был бы очень полезен гибридный вариант и автоматическая ротация лога с настройками в конфиге.
Схема следующая: ведется бинлог изменений, и при старте редиса изменения из него подсасываются в базу. Подробнее об этом можно почитать в вики проекта.
Плюсы этой схемы — при падении редиса при обычной схеме вы теряли данные которые были добавлены в промежуток снапшота. В данном случае вы не теряете данные.
Минусы — размер бин лога растет, и сейчас у редиса нету встроенных средств ротации, для этого используется комманда BGREWRITEAOF.
Мне кажется что был бы очень полезен гибридный вариант и автоматическая ротация лога с настройками в конфиге.
имел ввиду если размер базы 10 гиг, то при подсасывании бинлогов объемом 20 мегабайт в базу, на диск будет запись 10 гигов или 20 мбайт?
Затрудняюсь вам ответить. Советую читать тут: code.google.com/p/redis/wiki/AppendOnlyFileHowto
Таки хотелось бы узнать, в каких реальных проектах используется Redis, как при этом выглядит реальный код, и как лучше проектировать для такого типа БД (а то все привыкли к реляционным)?
Спасибо и успехов.
Спасибо и успехов.
написано на сайте.
Код выглядит в зависимости от используемого класса/языка/библиотеки/как напишите.
Код выглядит в зависимости от используемого класса/языка/библиотеки/как напишите.
Ну я же не об этом спросил.
Победные заявления на сайте и реальный опыт хабровчан — разные вещи.
А вот меня и интересует реальный код на любой платформе. Пример из жизни.
Чем логика взаимодействия отличается от релационных БД? Каковы неочевидные особенности?
Победные заявления на сайте и реальный опыт хабровчан — разные вещи.
А вот меня и интересует реальный код на любой платформе. Пример из жизни.
Чем логика взаимодействия отличается от релационных БД? Каковы неочевидные особенности?
Вы можете посмотреть пример разработки упрощенного Твитера на сайте Редиса.
переписал часть своего сервиса под редис — не могу нарадоваться :) Долго не мог привыкнуть к нерелеационному мышлению :) но в итоге теперь думаю нафиг этот монстр МуСКуЛ надо вообще!?
Пример «SELECT * FROM table»:
Пример «SELECT * FROM table»:
упс, рано
function getAllItems() {
$items = array();
$dbconn = redis_pool::getConn();
$iids = $dbconn->get_members('items.set');
foreach($iids as $iid) {
$item = $dbconn->get('items.'.$iid);
if (!empty($item)) {
$items[] = $item;
}
}
return $items;
}
где в ключе «items.ID» сериализированный масив полей айтема.
function getAllItems() {
$items = array();
$dbconn = redis_pool::getConn();
$iids = $dbconn->get_members('items.set');
foreach($iids as $iid) {
$item = $dbconn->get('items.'.$iid);
if (!empty($item)) {
$items[] = $item;
}
}
return $items;
}
где в ключе «items.ID» сериализированный масив полей айтема.
В чём выгода перед, допустим, PDO+SQLite?
Объём кода и логика приведённого кода будут такими же.
Redis быстрее? Логичнее? Вкуснее? :-)
Объём кода и логика приведённого кода будут такими же.
Redis быстрее? Логичнее? Вкуснее? :-)
Подскажите, а есть ли у редиса memcached-совместимый интерфейс, или обязательно придется переделать софт, чтобы попробовать redis?
Добрый день, я абсолютный новичок в использовании Redis. Поставил его впервые и более менее познакомился с ним после прочтения этой статьи.
Простое подключение к серверу и получение значения строкового скалярного значения ключа занимает 8-10 мс.
Это довольно много. Например, самодельная система хранения сериализованных значений в файлах делает это примерно в 100 раз быстрее.
Подскажите, пожалуйста, это нормальная ситуация для redis? И можно ли как-то ускорить? Буду благодарен за советы и ссылки.
Простое подключение к серверу и получение значения строкового скалярного значения ключа занимает 8-10 мс.
Это довольно много. Например, самодельная система хранения сериализованных значений в файлах делает это примерно в 100 раз быстрее.
Подскажите, пожалуйста, это нормальная ситуация для redis? И можно ли как-то ускорить? Буду благодарен за советы и ссылки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обновились Redis 1.2.1 и PHP клиент Rediska 0.3.0