Комментарии 31
линк на оригинал можно?
Это же перевод — щёлкаете на имя автора: Courtney Couch и переходите на moot.it/blog/technology/redis-as-primary-datastore-wtf.html
Я бы посоветовал перечитать статью пару раз перед тем, как ее публиковать — очень много косноязычных фраз вроде «ужас грядущего счёта». Про запятые вообще молчу.
На своём проекте мы тоже используем redis как основное хранилище.
Проблемы сохранности данных решаем репликацией, кластер пока не используем так как не храним большие тексты, а только данные приложений и короткие строки. Храним в памяти только ключи и часто используемые данные, данные которые не использовались давно записываются на диск и не хранятся в памяти.
Единственная проблема с которой мы пока столкнулись — это поиск данных по критериям (возможно скрипты на lua решат эту проблему, но драйвер для node.js пока криво с ними работает и вообще работает криво, сидим на версии 0.7.2 как наиболее не глючной).
Проблемы сохранности данных решаем репликацией, кластер пока не используем так как не храним большие тексты, а только данные приложений и короткие строки. Храним в памяти только ключи и часто используемые данные, данные которые не использовались давно записываются на диск и не хранятся в памяти.
Единственная проблема с которой мы пока столкнулись — это поиск данных по критериям (возможно скрипты на lua решат эту проблему, но драйвер для node.js пока криво с ними работает и вообще работает криво, сидим на версии 0.7.2 как наиболее не глючной).
Должны решить, их применение снимет большинство накладных расходов. К сожалению автор ещё не написал про их работу с Lua.
Lua скрипты блокируют работу redis (при выполнении одного скрипта другие команды в redis или другие скрипты не будут выполнены, пока он не закончить) для атомарности. Поэтому много интересной логики туда не напишеш.
www.lua.org/pil/26.html — запускаешь процесс с нужной логикой из новой функции, которую напишешь на Си, передашь в него что нужно, а скрипт благополучно сведётся к одной недорогой команде, после чего завершится. Потом можно периодически опрашивать процесс через сообщения например или пайпы.
Для проблемы поиска мы думали сделать скрипт, который принимает номер объекта и критерии которым объект должен удовлетворять. Этот скрипт мы вызывали бы в цикле из основного процесса увеличивая номер пока бы не перебрали все объекты, каждый раз когда скрипт отрабатывал бы, мы бы обновляли результаты поиска.
Таким образом процесс редис блокировался бы только на время простой операции получения одного объекта и сравнения его с критериями, а асинхронный перебор ложился бы на плечи ноды. Теоретически это должно работать в несколько раз быстрее чем чистое сравнение на ноде.
На практике пока сливаем часть редиса раз в сутки в мускл и ищем в нем, но в будущем хотелось бы отказаться от этого.
Таким образом процесс редис блокировался бы только на время простой операции получения одного объекта и сравнения его с критериями, а асинхронный перебор ложился бы на плечи ноды. Теоретически это должно работать в несколько раз быстрее чем чистое сравнение на ноде.
На практике пока сливаем часть редиса раз в сутки в мускл и ищем в нем, но в будущем хотелось бы отказаться от этого.
Почему-то после прочтения этой статьи у меня в голове сразу всплыла фраза о преждевременной оптимизации. Хотя, конечно, с технологической точки зрения опыт весьма полезный.
По статье как раз наоборот, если использовать Redis как основное хранилище — необходимо сразу думать и разделении данных — потом будет очень проблематично.
Это понятно, я имел в виду, что для начала им запросто хватило бы и MySQL.
«У нас была изначальная цель, чтобы все вызовы API обрабатывались менее чем за 10мс даже под высокой нагрузкой»
И вряд ли они собирались в последствии переписывать свою систему.
И вряд ли они собирались в последствии переписывать свою систему.
API не видел, но никаких проблем добиться тех же результатов с MySQL, просто тот же memcached подключить агрессивно.
Они, судя по статье, сразу рассчитывали на очень высокие нагрузки, т.е. что проект сразу станет мега-популярным. Вопрос — стал ли? Я, конечно, не мерило, но об этом сервисе прочитал только тут в первый раз. Кстати, их конкурент, Disqus, вполне себе работает на Postgres, и ничего, всё шевелится.
Они, судя по статье, сразу рассчитывали на очень высокие нагрузки, т.е. что проект сразу станет мега-популярным. Вопрос — стал ли? Я, конечно, не мерило, но об этом сервисе прочитал только тут в первый раз. Кстати, их конкурент, Disqus, вполне себе работает на Postgres, и ничего, всё шевелится.
По моему они просто взяли с разу заложили возможность для расширения, и это правильно, и к оптимизации не относиться.
Там ещё ограничения и по цене. Да и в начале он сразу написал «Прежде всего, я хотел бы подчеркнуть что большинство приложений вовсе не должны обращать внимания на костыли использованные, что бы пойти таким путём. Это было важно для нашего сценария использования, но мы можем быть граничным случаем.»
Ну они и запустились-то совсем недавно.
На самом деле, если отбросить нагрузки, то делать сразу на NoSql банально проще, разработка идет быстрее. Говорю по своему опыту использования Redis. Просто с NoSql надо четко понимать, КАК используются данные.
C SQL мы сваливаем все в одну кучу и только потом начинаем думать, что с этим делать, отсюда проблемы не только с нагрузкой, но и с миграциями и прочим.
C SQL мы сваливаем все в одну кучу и только потом начинаем думать, что с этим делать, отсюда проблемы не только с нагрузкой, но и с миграциями и прочим.
дошел до вашего комментария и улыбнулся — я не одинок :)
но это всего лишь моё ощущение и не больше.
но это всего лишь моё ощущение и не больше.
изначальное разделение данных очень правильных подход.
На самом деле redis хорош. Очень хорош.
Ознакомившись с Маленькой Книгой (http://cloud.github.com/downloads/kondratovich/the-little-redis-book/redis-ru.pdf) можно сделать выводы о целесообразности использования его у себя.
Цитата:
Redis использует множество способов облегчить наше взаимодействие с данными. Эта система убирает большую часть сложности и абстракции, присущих другим системам. Во многих случаях это делает Redis неудачным выбором. Но в других случаях может показаться, что Redis был написан для решения именно вашей проблемы.
Redis прост в освоении. Когда вокруг так много новых технологий, не просто понять, на изучение какой стоит потратить время. Когда вы увидите реальные преимущества, которые Redis может предложить, я уверен, что у вас не останется вопросов о том, уделять ли время на изучение Redis.
Ознакомившись с Маленькой Книгой (http://cloud.github.com/downloads/kondratovich/the-little-redis-book/redis-ru.pdf) можно сделать выводы о целесообразности использования его у себя.
Цитата:
Redis использует множество способов облегчить наше взаимодействие с данными. Эта система убирает большую часть сложности и абстракции, присущих другим системам. Во многих случаях это делает Redis неудачным выбором. Но в других случаях может показаться, что Redis был написан для решения именно вашей проблемы.
Redis прост в освоении. Когда вокруг так много новых технологий, не просто понять, на изучение какой стоит потратить время. Когда вы увидите реальные преимущества, которые Redis может предложить, я уверен, что у вас не останется вопросов о том, уделять ли время на изучение Redis.
Я не понимаю, почему во всех статьях про Redis пишут, что это отличная замена Memcached и он хорош в качестве основного хранилища данных?
Во втором случае Redis ведь при исчерпании памяти свопится на диск, что ведет к тормозам. А если докупать сервера, то сравним объем HDD и RAM, из-за чего Redis потребует больше серверов для хранения.
В первом случае у Memcached есть неоспоримое преимущество: при исчерпании памяти для кэша автоматически удаляются самые старые кэши. Redis же в этот момент опять свопится на диск.
Во втором случае Redis ведь при исчерпании памяти свопится на диск, что ведет к тормозам. А если докупать сервера, то сравним объем HDD и RAM, из-за чего Redis потребует больше серверов для хранения.
В первом случае у Memcached есть неоспоримое преимущество: при исчерпании памяти для кэша автоматически удаляются самые старые кэши. Redis же в этот момент опять свопится на диск.
Вы ошибаетесь, никакого свопа на диск не происходит. Redis ведет только синхронизацию памяти и диска, которая гибко настраивается параметром
Вот стандартный конфиг.
Диск может притормаживать, но есть два очень важных преимущества перед Memcached. При падении/перезапуске не надо прогревать кеш заново. И клевые структуры конечно.
save в конфиге. Политика обработки переполнения памяти описана в параметре maxmemory-policy, почитайте.Вот стандартный конфиг.
Диск может притормаживать, но есть два очень важных преимущества перед Memcached. При падении/перезапуске не надо прогревать кеш заново. И клевые структуры конечно.
Здорово. Как-то я при чтении доки упустил этот момент.
Правда есть одна непонятная вещь: разработчики рекомендуют разделять сервера, в которых хранится постоянная информация и те, что используются в качестве кэша (чтобы не убивать нужную информацию). Но там есть такая опция «volatile-lru» — удаляет по алгоритму LRU только ключи с TTL, поэтому можно в принципе кэш писать с TTL, и не разделять логически с постоянной информацией?
Правда есть одна непонятная вещь: разработчики рекомендуют разделять сервера, в которых хранится постоянная информация и те, что используются в качестве кэша (чтобы не убивать нужную информацию). Но там есть такая опция «volatile-lru» — удаляет по алгоритму LRU только ключи с TTL, поэтому можно в принципе кэш писать с TTL, и не разделять логически с постоянной информацией?
Буквально вчера думал, что в своём велосипеде попробовать redis в связке с mysql. Много данных есть, которые не требуют постоянной связки с другими данными. Можно, конечно, сохранять в обычном текстовом файле, но, скорее всего, проще будет нужные данные извлекать по необходимости по ключу. В частности, у меня есть логи действий пользователей. Ни к чему там реляционная база данных.
Мне кажется, или Moot слишком уж бесплатным получился, учитывая проделанную работу?..
Я вот подумываю использовать Redis как базу данных для десктопного приложения. В основном там будут хранится логи самого приложения, плюс некая достаточно однородная информация, которая поступает примерно раз в секунду. То есть час работы приложения съест в районе 10-20 мегов.
Приложение не для общего пользования, поэтому никто не будет запускать его на машине с 512 мегами оперативки, но сомнения у меня всё-таки есть. Из плюсов можно отметить удобство работы с хранилищем и, действительно, высокую скорость выборки. Так же удобно то, что ничего не надо устанавливать при деплойменте, достаточно запустить процесс сервера.
Если у кого есть опыт подобного применения, пожалуйста отпишитесь.
Приложение не для общего пользования, поэтому никто не будет запускать его на машине с 512 мегами оперативки, но сомнения у меня всё-таки есть. Из плюсов можно отметить удобство работы с хранилищем и, действительно, высокую скорость выборки. Так же удобно то, что ничего не надо устанавливать при деплойменте, достаточно запустить процесс сервера.
Если у кого есть опыт подобного применения, пожалуйста отпишитесь.
Было бы интересно узнать, как у них со всеми валидациями и генерацией JSON получилось 2 миллисекунды в среднем на ответ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Redis — главное хранилище? Что за хрень?!