Какой смысл переносить проблему с больной головы на здоровую? Мы хотим снизить нагрузку с Redis и уменьшаем количество запросов с 12 до 6. А потом весело переносим все внутрь базы данных, начав использовать Lua. В итоге как у нас была нагрузка на базу данных, так она и осталась.
Может быть проще придумать более изящный способ решить эту проблему, а не делать вид, что нашли решение?
Не 36 000 рублей в год, а в 2014 году взносы ИП за себя составляют 20727,53 р. + 1% от доходов свыше 300 000 р. Если вы в теме не разбираетесь, а сказать что-то хочется, то лучше промолчать — умнее будете выглядеть!
И не про налоги речь идет, а о взносах. Будем точны с терминами в финансовой сфере.
Согласен с вами, но в статье я как раз и обращаю внимание, что кластер удобно запустить для новой базы, а для старой очень сложно мигрировать данные на новые машины в кластере.
>> Кстати решение шардировать редисы напрямую на уровне application тоже не балансирует нагрузку.
Почему не балансирует нагрузку? Если данных много, то мы можем допустить, что они равномерно распределены между базами. И следовательно количество операций чтения-записи увеличивается пропорционально количеству баз в кластере.
Смысл использования nosql-решений всегда один — справиться с большими нагрузками. Поэтому справедливо замечание tumbler о том, что не надо каждый раз открывать соединение при запросе значений. Открыли соединение и используем его.
>> При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее.
Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая — данных раздаваемых из файловой системе мало и они закешировались в оперативке. И то в этом случае скорость будет сопоставима, но не быстрее.
Поясню. Одна база редис просто не справляется с потоком данных на запись и чтение. Поэтому одно из решение распараллелить данные на несколько баз с помощью кластера. Что даст кластер из нескольких баз редис описано в статье. Так же приведена ссылка на пример простого реализованного кластера.
Использую связку 1 Nginx + 20 Thin. Версия руби 1.8.7 и вполне доволен скорость работы. Памяти используется очень мало.
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
У меня небольшой вопрос к опытным пользователям Redis. Длина названия ключа сильно влияет на размер базы?
Поясню. Скажем есть тип данных хэш для пользователя с несколькими полями: login, password, sex и т.д.
Тогда для наглядности вот один из способов получить данные
hmget user:100, login, password, sex
На сколько база будет меньше, если назвать соответствующие поля, скажем, l, p, s?
hmget user:100, l, p, s
То есть для каждой записи в базе сохраняется название поля или нет? Стоит оптимизировать названия полей в базе или нет?
Может быть проще придумать более изящный способ решить эту проблему, а не делать вид, что нашли решение?
И не про налоги речь идет, а о взносах. Будем точны с терминами в финансовой сфере.
Почему не балансирует нагрузку? Если данных много, то мы можем допустить, что они равномерно распределены между базами. И следовательно количество операций чтения-записи увеличивается пропорционально количеству баз в кластере.
>> При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее.
Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая — данных раздаваемых из файловой системе мало и они закешировались в оперативке. И то в этом случае скорость будет сопоставима, но не быстрее.
Цитирую новость с официального сайта Руби:
Unicorn устанавливал один раз. После его запуска был поражен сколько памяти он «съел» по сравнению с Thin. Автору может быть присмотреться к другим веб-серверам? Чем уж так хорош Unicorn? Или просто лень переучиваться?
Поясню. Скажем есть тип данных хэш для пользователя с несколькими полями: login, password, sex и т.д.
Тогда для наглядности вот один из способов получить данные
hmget user:100, login, password, sexНа сколько база будет меньше, если назвать соответствующие поля, скажем, l, p, s?
hmget user:100, l, p, sТо есть для каждой записи в базе сохраняется название поля или нет? Стоит оптимизировать названия полей в базе или нет?