Редис участвует почти во всем функционале сайте в большей или меньшей степени. Его основная роль: счетчики, лимиты, рейтинги, очереди, логирование, хранение сессий, статистика, кеширование и прочее. Есть функционал который использует только Редис: друзья, топы, геном (рейтинг пользователя), голоса за контент, важные обновления…
Predis более низкоуровневый клиент, который по сути реализует команды редиса как есть. В силу этого, например, он не занимается сереализацией данных, шардинг ключей по серверам ограничен для комманд, которые работают с несколькими ключами («мультигет» к примеру).
Редиска же изначально разрабатывали как более высокоуровней и удобный клиент. Поэтому в Редиски в отличии от Predis есть ООП обертки для ключей, интеграция с фреймворками, сериализация данных и т.д.
Да, Memcached хранит ключи более компактно, но плюсы которые дает Redis гораздо дороже, чем память в магазине, поэтому я не вижу никакой проблемы в этом. Серьезный проект никогда не будет жаться из-за лишней планке в сервере, не так ли? :)
Случай о котором вы говорите подходит только для snapshot-ов. Мы используем второй вариант сохранения данных — AOF (binlog).
Резюмируя ответ: нас не беспокоят лишнии байты который отъедает Redis, по сравнению с Memcached. Это незначительная плата persistent хранение данных, списки, сеты, транзакции, эвент-модель и прочие чудеса Редиса.
Я сказал, что на каждом сервере по полмиллиона ключей примерно. У нас сейчас ключи размазываются по четырем серверам.
С memcache сравнивать не имеет смысла, так как он хранит данные в энергозависимой памяти. Сравнивайте в таком случае с memcachedb… и забудьте о списках, сетах и прочих вкусностях Redis.
Redis — это не панацея. Это такой же инструмент как и MySQL и MongoDb, и у каждого инструмента есть своя область применения. Мы используем все три перечисленных базы, под свои задачи.
У проекта, о котором я говорю почти 2 миллиона просмотров в день.
Мы не единственные кто его использует. Есть товарищи гораздо крупнее, github например. Надо просто делать это с умом, об этом я и буду рассказывать в своем докладе.
Эта проблема была в ранних версиях. Сейчас у нас по пол миллиона ключей на каждом сервере. В памяти каждый процесс занимает по 3,6 гигабайт и это значение увеличивается равномерно с увеличением количества ключей, то есть никаких фатальных утечек не возникает.
Редиска же изначально разрабатывали как более высокоуровней и удобный клиент. Поэтому в Редиски в отличии от Predis есть ООП обертки для ключей, интеграция с фреймворками, сериализация данных и т.д.
Еще раз, Redis хранит не только стринги, в отличии от Memcached. У нас 45% ключей это сеты, листы и сортед-сеты.
Сделал простенький тест: загнал миллион обычных ключей в Redis и Memcached.
Redis — 202,6 Мб (187 Мб после рестарта)
Memcached — 71 Мб
Да, Memcached хранит ключи более компактно, но плюсы которые дает Redis гораздо дороже, чем память в магазине, поэтому я не вижу никакой проблемы в этом. Серьезный проект никогда не будет жаться из-за лишней планке в сервере, не так ли? :)
Случай о котором вы говорите подходит только для snapshot-ов. Мы используем второй вариант сохранения данных — AOF (binlog).
Резюмируя ответ: нас не беспокоят лишнии байты который отъедает Redis, по сравнению с Memcached. Это незначительная плата persistent хранение данных, списки, сеты, транзакции, эвент-модель и прочие чудеса Редиса.
С memcache сравнивать не имеет смысла, так как он хранит данные в энергозависимой памяти. Сравнивайте в таком случае с memcachedb… и забудьте о списках, сетах и прочих вкусностях Redis.
Redis — это не панацея. Это такой же инструмент как и MySQL и MongoDb, и у каждого инструмента есть своя область применения. Мы используем все три перечисленных базы, под свои задачи.
У проекта, о котором я говорю почти 2 миллиона просмотров в день.
Мы не единственные кто его использует. Есть товарищи гораздо крупнее, github например. Надо просто делать это с умом, об этом я и буду рассказывать в своем докладе.