Коллеги,
Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем?
Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
G>Коллеги, G>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
Да кагбы понятно, если не как база данных то бесплатно это:
Message Queue
Cache
Sql Server в те времена был слишком платным, а развернуть MMQ был еще тот квест (по слухам).
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Gattaka, Вы писали:
G>>Коллеги, G>>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
D>Да кагбы понятно, если не как база данных то бесплатно это: D>Message Queue
— реббит, кафка
D>Cache
? зачем? оперативка приложения.
D>Sql Server в те времена был слишком платным, а развернуть MMQ был еще тот квест (по слухам).
Что это такое?
G>>Коллеги, G>>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
САД>Распределённый кэш.
Окей, простой вопрос на который вам не составит труда ответить. Зачем нужен распределенный кеш при наличии БД?
GarryIV моментально влепил минус. Без аргументов, без ответа. Это успех. В священных войнах это успех.
Вполне возможно, что одним только своим вопросом я отправил опонента в больницу. Он успел только поставить минус и схватился за сердце... "Ааа.... мой редис, редис... сердце!" И упал со стула.
Успех! Хорошо! Как же я силен в этих самых войнах священных.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
Здравствуйте, A_l_e_x_e_y, Вы писали:
A__>Здравствуйте, Gattaka, Вы писали:
G>>Коллеги, G>>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
A__>Sorted Sets.
Что sorted sets? Это алгоритм такой, для использования которого не нужно ставить себе Redis. Между прочим.
Кролик крайне плохо работает в cross-dc окружении (особенно когда начинаются проблемы с сетью — проще сказать, что он не работает). Кафка — это Java, ZooKeeper, кровь, кишки, сожрало память, завалило трейсами.
Сами по себе инструменты неплохие, если правильно их готовить, но нишу Redis как простого тупого надежного решения не закрывают.
G> D>Cache G> ? зачем? оперативка приложения.
Тут, вероятно, имелся ввиду distributed cache. Но даже в рамках одного хоста далеко не всегда есть возможность или целесообразность делать кэш в памяти приложения (например для prefork модели или микросервисов).
Здравствуйте, Gattaka, Вы писали:
A__>>Sorted Sets. G>Что sorted sets? Это алгоритм такой, для использования которого не нужно ставить себе Redis. Между прочим.
В редисе есть его качественная реализация что позволяет не реализовывать его самому. На сколько мне известно(конечно я могу ошибаться) в распространённых SQL-базах такой функционал отсутствует.
САД>>Распределённый кэш. G>Окей, простой вопрос на который вам не составит труда ответить. Зачем нужен распределенный кеш при наличии БД?
это может быть необходимо при микросервисной архитектуре.
но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов.
Здравствуйте, A_l_e_x_e_y, Вы писали:
A__>В редисе есть его качественная реализация что позволяет не реализовывать его самому. На сколько мне известно(конечно я могу ошибаться) в распространённых SQL-базах такой функционал отсутствует.
Распространенные базы данных позволяют тебе не думать об алгоритмах. Ты говоришь что тебе нужно, а они уже сами подбирают алгоритм. И уже сами решают как это сделать.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Gattaka, Вы писали:
G>> D>Message Queue G>> — реббит, кафка
AB>Кролик крайне плохо работает в cross-dc окружении (особенно когда начинаются проблемы с сетью — проще сказать, что он не работает). Кафка — это Java, ZooKeeper, кровь, кишки, сожрало память, завалило трейсами.
AB>Сами по себе инструменты неплохие, если правильно их готовить, но нишу Redis как простого тупого надежного решения не закрывают.
G>> D>Cache G>> ? зачем? оперативка приложения.
AB>Тут, вероятно, имелся ввиду distributed cache. Но даже в рамках одного хоста далеко не всегда есть возможность или целесообразность делать кэш в памяти приложения (например для prefork модели или микросервисов).
Вот зачем давать такие многозначительные ответы, чтобы люди потом гадали что имелось в виду? Да чтобы казаться умнее. Потому как если много скажешь — сразу станет понятно, что аргументов то и нет.
И чем же он так хорош как ditributed cache? Как у него с отказоустойчивостью. Если значение попало на одну ноду редиса, то как скоро оно доберется до другой ноды?
В обще зачем нужен distributed cache? Можно конкретный пример?
САД>>>Распределённый кэш. G>>Окей, простой вопрос на который вам не составит труда ответить. Зачем нужен распределенный кеш при наличии БД?
САД>это может быть необходимо при микросервисной архитектуре.
Микросервисная архитектура тут не имеет каких-либо особенностей, отличающей с этой точки зрения от другой архитектуры.
Ничего такого микросервисная архитектура не привносит, чтобы нужно было использовать redis. Либо пример конкретный в студию плиз.
САД>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов.
Так сделайте materialized view. Есть такое понятие buffer pool. Он работает быстрее чем редис.
САД>>это может быть необходимо при микросервисной архитектуре. G>Микросервисная архитектура тут не имеет каких-либо особенностей, отличающей с этой точки зрения от другой архитектуры.
шаринг данных между микросервисами. один из вариантов.
G>Ничего такого микросервисная архитектура не привносит, чтобы нужно было использовать redis. Либо пример конкретный в студию плиз.
есть 5 активностей. мы должны прогнать все их 5 через какой-то кусок данных. каждая активность — отдельный микросервис.
что бы за этими данными не ходить постоянно в сиквел, они лежат в редисе, после того как вся работа будет проделана, данные сохранятся в сиквел.
САД>>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов. G>Так сделайте materialized view. Есть такое понятие buffer pool. Он работает быстрее чем редис.
материализованные вьюхи не всегда работают. особенно если логика выборки сложнее чем обычный селект. а еще бывают динамические запросы в базу
структура базы не всегда может быть нормализована.
Здравствуйте, Gattaka, Вы писали:
G>Распространенные базы данных позволяют тебе не думать об алгоритмах. Ты говоришь что тебе нужно, а они уже сами подбирают алгоритм. И уже сами решают как это сделать.
Ну хорошо. Допустим нам нужно сделать рейтинг игроков онлайн игры обновляемый в реальном времени. Это вполне себе жизненная задача.
Этот рейтинг должен уметь обрабатывать изменения количества очков в реальном времени, выдавать место в рейтинге по идентификатору игрока, количество очков по идентификатору игрока и идентификатор игрока по месту в рейтинге... и делать всё это максимально быстро(и конечно же нужно уметь эти данные сохранять на диске). Конечно же это можно реализовать поверх SQL-базы(ну или скажем MongoDB), но тогда придётся принести в жертву эффективность части из этих операций.
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>>>это может быть необходимо при микросервисной архитектуре. G>>Микросервисная архитектура тут не имеет каких-либо особенностей, отличающей с этой точки зрения от другой архитектуры.
САД>шаринг данных между микросервисами. один из вариантов.
Единая точка отказа. Представим, что схема хранимых в редис данных меняется. Обновили для этого один из сервисов. Остальные 4 начали падать. Т.к. не могут десериализовать новые данный. Упс. Нужно было их тоже обновить.
Обновляем в таком случае все 5 микросервисов. Упс. Да это же старый добрый монолит, только разделенный на несколько исполняемых файлов, что лишь добавляет гемора. Айда на хабр писать про провал микросервисов и понеслась. Так оно и бывает.
G>>Ничего такого микросервисная архитектура не привносит, чтобы нужно было использовать redis. Либо пример конкретный в студию плиз.
САД>есть 5 активностей. мы должны прогнать все их 5 через какой-то кусок данных. каждая активность — отдельный микросервис. САД>что бы за этими данными не ходить постоянно в сиквел, они лежат в редисе, после того как вся работа будет проделана, данные сохранятся в сиквел.
Недостаток описан выше. Это не микросервисы.
САД>>>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов. G>>Так сделайте materialized view. Есть такое понятие buffer pool. Он работает быстрее чем редис.
САД>материализованные вьюхи не всегда работают. особенно если логика выборки сложнее чем обычный селект. а еще бывают динамические запросы в базу САД>структура базы не всегда может быть нормализована.
Окей. Тут скорее всего какая-то дичь с этой самой бизнес логикой. Нужно смотреть откуда взялись эти дикие джойны и постараться свести все к более простым джойнам быть может даже с помощью дублирования данных.
САД>>шаринг данных между микросервисами. один из вариантов. G>Единая точка отказа. Представим, что схема хранимых в редис данных меняется. Обновили для этого один из сервисов. Остальные 4 начали падать. Т.к. не могут десериализовать новые данный. Упс. Нужно было их тоже обновить.
редис — это ин-мемори ДБ. с возможностью персистить данные.
если обновили сервиса — дропнули кэш. всё.
G>Обновляем в таком случае все 5 микросервисов. Упс. Да это же старый добрый монолит, только разделенный на несколько исполняемых файлов, что лишь добавляет гемора. Айда на хабр писать про провал микросервисов и понеслась. Так оно и бывает.
ничего такого не происходит. а вот с сиквелом как раз самое оно. изменили структуру базы данных — нужно обновлять все приложения, которые её юзают
САД>>есть 5 активностей. мы должны прогнать все их 5 через какой-то кусок данных. каждая активность — отдельный микросервис. САД>>что бы за этими данными не ходить постоянно в сиквел, они лежат в редисе, после того как вся работа будет проделана, данные сохранятся в сиквел. G>Недостаток описан выше. Это не микросервисы.
нет никаких недостатков в данном случае.
САД>>материализованные вьюхи не всегда работают. особенно если логика выборки сложнее чем обычный селект. а еще бывают динамические запросы в базу САД>>структура базы не всегда может быть нормализована. G>Окей. Тут скорее всего какая-то дичь с этой самой бизнес логикой. Нужно смотреть откуда взялись эти дикие джойны и постараться свести все к более простым джойнам быть может даже с помощью дублирования данных.
нет необходимости извращаться, если есть редис
сиквел быстрый и хороший, но не достаточно быстрый. увы.
потому в хайлоаде юзают денормализацию.
и для распределенных систем он тоже не всегда под все кейсы подходит напрямую.
Сервис на Руби, база Постгрес. Пишем каршеринг.
Человек забронировал авто бесплатно на 20 минут, потом нужно либо начать брать деньги, либо на разблокировать.
Как сделать таймер? Правильно — Редис.
Здравствуйте, A_l_e_x_e_y, Вы писали:
A__>Здравствуйте, Gattaka, Вы писали:
G>>Распространенные базы данных позволяют тебе не думать об алгоритмах. Ты говоришь что тебе нужно, а они уже сами подбирают алгоритм. И уже сами решают как это сделать.
A__>Ну хорошо. Допустим нам нужно сделать рейтинг игроков онлайн игры обновляемый в реальном времени. Это вполне себе жизненная задача. A__>Этот рейтинг должен уметь обрабатывать изменения количества очков в реальном времени, выдавать место в рейтинге по идентификатору игрока, количество очков по идентификатору игрока и идентификатор игрока по месту в рейтинге... и делать всё это максимально быстро(и конечно же нужно уметь эти данные сохранять на диске). Конечно же это можно реализовать поверх SQL-базы(ну или скажем MongoDB), но тогда придётся принести в жертву эффективность части из этих операций.
Первое что приходит на ум это event sourcing. Поступаю эвенты об изменении рейтинга. Мы их все прихраниваем как пришли в специально обученной таблице. Используем для этого sql server с in memory oltp.
Кроме того есть табличка с актуальными значениями. Тоже in memory oltp.
Преимущества и недостатки подхода с redis.
1. Если нода с редисом навернется, то она не сохранит на диск то что у нее в памяти. Иначе откуда скорость? То есть потеря данных.
2. Все таки что там с отказоустойчивостью редиса? Предположим у меня две ноды редиса. Один мастер, другой слейв.
У меня две апп ноды. В рейтинге есть игрок Вася с рейтингом 100.
а. Приходит событие увеличения рейтинга на 9. Взяли с мастера 100 добавили 9, записали 109 в мастер. Оно полетело в реплику, но еще не долетело.
б. Приходит событие увеличения рейтинга на 8. Взяли с реплики 100 (!) (т.к. еще не долетело) добавили 8, записали в мастер 108. Итого у нас значение рейтинга 108. А должно было быть 117.
Здравствуйте, Шубин Евгений, Вы писали:
ШЕ>Здравствуйте, Gattaka, Вы писали:
ШЕ>Сервис на Руби, база Постгрес. Пишем каршеринг. ШЕ>Человек забронировал авто бесплатно на 20 минут, потом нужно либо начать брать деньги, либо на разблокировать. ШЕ>Как сделать таймер? Правильно — Редис.
А если редис упал? Потеряем те 13 минут что остались у пользователя? Или как?
Такой вариант — заводим в постресе табличку с временем, есть джоба которая раз в 30 сек выгребает оттуда просроченных. Вуаля — все надежно и транзакционно.
Второй вариант заиспользовать раббит с отложенными сообщениями (код получится гораздо проще, чем с redis).
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>ничего такого не происходит. а вот с сиквелом как раз самое оно. изменили структуру базы данных — нужно обновлять все приложения, которые её юзают
Ну ты как полученные данные из Редис десериализуешь? Вот этот десериализатор тебе ексепшен и кинет. Когда вместо json обнаружит там xml. Положенный другим нерасторопным сервисом. Так то.
САД>>>есть 5 активностей. мы должны прогнать все их 5 через какой-то кусок данных. каждая активность — отдельный микросервис. САД>>>что бы за этими данными не ходить постоянно в сиквел, они лежат в редисе, после того как вся работа будет проделана, данные сохранятся в сиквел. G>>Недостаток описан выше. Это не микросервисы.
САД>нет никаких недостатков в данном случае.
Отрицание. Гнев. Принятие. Пока только отрицание идет.
САД>>>материализованные вьюхи не всегда работают. особенно если логика выборки сложнее чем обычный селект. а еще бывают динамические запросы в базу САД>>>структура базы не всегда может быть нормализована. G>>Окей. Тут скорее всего какая-то дичь с этой самой бизнес логикой. Нужно смотреть откуда взялись эти дикие джойны и постараться свести все к более простым джойнам быть может даже с помощью дублирования данных.
САД>нет необходимости извращаться, если есть редис
САД>сиквел быстрый и хороший, но не достаточно быстрый. увы. САД>потому в хайлоаде юзают денормализацию. САД>и для распределенных систем он тоже не всегда под все кейсы подходит напрямую.
По моим замерам скорость чтения в Sql Server выше, чем в redis. Он его просто обогнал. Да и почему должно быть иначе. Ведь Sql Server хранит также свои данные в buffer pool. Т.е. в оперативной памяти.
САД>>ничего такого не происходит. а вот с сиквелом как раз самое оно. изменили структуру базы данных — нужно обновлять все приложения, которые её юзают G>Ну ты как полученные данные из Редис десериализуешь? Вот этот десериализатор тебе ексепшен и кинет. Когда вместо json обнаружит там xml. Положенный другим нерасторопным сервисом. Так то.
еще раз — кэш будет сброшен и заполнен заново в новом формате.
САД>>нет никаких недостатков в данном случае. G>Отрицание. Гнев. Принятие. Пока только отрицание идет.
повторяй эту мантру перед сном.
САД>>сиквел быстрый и хороший, но не достаточно быстрый. увы. САД>>потому в хайлоаде юзают денормализацию. САД>>и для распределенных систем он тоже не всегда под все кейсы подходит напрямую. G>По моим замерам скорость чтения в Sql Server выше, чем в redis. Он его просто обогнал. Да и почему должно быть иначе. Ведь Sql Server хранит также свои данные в buffer pool. Т.е. в оперативной памяти.
когда у нас кластер и несколько, допустим, веб-нод, каждая может держать свой кеш рядом с собой в редисе. попробуй поставить столько сиквелов.
посмотрим что это будет по ресурсам и деньгам
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>>>ничего такого не происходит. а вот с сиквелом как раз самое оно. изменили структуру базы данных — нужно обновлять все приложения, которые её юзают G>>Ну ты как полученные данные из Редис десериализуешь? Вот этот десериализатор тебе ексепшен и кинет. Когда вместо json обнаружит там xml. Положенный другим нерасторопным сервисом. Так то.
САД>еще раз — кэш будет сброшен и заполнен заново в новом формате.
Кем он сброшен будет? Новым сервисом? Т.е. выкатка бьет по перфомансу всей системы? Это успех!
САД>>>сиквел быстрый и хороший, но не достаточно быстрый. увы. САД>>>потому в хайлоаде юзают денормализацию. САД>>>и для распределенных систем он тоже не всегда под все кейсы подходит напрямую. G>>По моим замерам скорость чтения в Sql Server выше, чем в redis. Он его просто обогнал. Да и почему должно быть иначе. Ведь Sql Server хранит также свои данные в buffer pool. Т.е. в оперативной памяти.
САД>когда у нас кластер и несколько, допустим, веб-нод, каждая может держать свой кеш рядом с собой в редисе. попробуй поставить столько сиквелов. САД>посмотрим что это будет по ресурсам и деньгам
И так ясно, оперативка дорогая. Веб ноды будут золотыми буквально. Врят ли они будут утилизировать всегда всю память. Это успех. Плюс. В докере должен быть только один процесс. Так что опять успех!
САД>>еще раз — кэш будет сброшен и заполнен заново в новом формате. G>Кем он сброшен будет? Новым сервисом? Т.е. выкатка бьет по перфомансу всей системы? Это успех!
ну мы не фейсбук, не амазон, не можем обновлять всё без даунтайма.
впрочем, как и твой монолит.
кэш так или иначе рано или поздно инвалидируется. например другие данные туда попали, потому что выборки пользователей поменялись.
так что ничего страшного в этом нет.
попадание в кэш оно не 100%
САД>>когда у нас кластер и несколько, допустим, веб-нод, каждая может держать свой кеш рядом с собой в редисе. попробуй поставить столько сиквелов. САД>>посмотрим что это будет по ресурсам и деньгам G>И так ясно, оперативка дорогая. Веб ноды будут золотыми буквально. Врят ли они будут утилизировать всегда всю память. Это успех. Плюс. В докере должен быть только один процесс. Так что опять успех!
кому должен?
какой-то бесмысленный пост у тебя получился
ты почему-то думаешь что кроме твоей единственной "правильной" архитектуры больше ничего нет. но увы, это не так.
Здравствуйте, Gattaka, Вы писали:
A__>>Ну хорошо. Допустим нам нужно сделать рейтинг игроков онлайн игры обновляемый в реальном времени. Это вполне себе жизненная задача. A__>>Этот рейтинг должен уметь обрабатывать изменения количества очков в реальном времени, выдавать место в рейтинге по идентификатору игрока, количество очков по идентификатору игрока и идентификатор игрока по месту в рейтинге... и делать всё это максимально быстро(и конечно же нужно уметь эти данные сохранять на диске). Конечно же это можно реализовать поверх SQL-базы(ну или скажем MongoDB), но тогда придётся принести в жертву эффективность части из этих операций.
G>Первое что приходит на ум это event sourcing. Поступаю эвенты об изменении рейтинга. Мы их все прихраниваем как пришли в специально обученной таблице. Используем для этого sql server с in memory oltp. G>Кроме того есть табличка с актуальными значениями. Тоже in memory oltp.
Очевидно что это будет работать существенно медленней и будет потреблять существенно больше памяти чем это делает редис... И что-то мне подсказывает что разница будет на столько велика что на одинаковом железе редис сможет обработать в десятки(по меньшей мере) раз большее количество запросов.
G>Преимущества и недостатки подхода с redis. G>1. Если нода с редисом навернется, то она не сохранит на диск то что у нее в памяти. Иначе откуда скорость? То есть потеря данных.
Редису не обязательно уметь писать на диск с большей скоростью. Ему достаточно использовать эффективный алгоритм, которому не требуются костыли.
Редис Sorted Sets это специализированное решение, просто таки заточенное под рейтинги(не обязательно это должны быть игры).
Редис пишет на диск приходящие команды и уровень надёжности настраиваться — можно удовлетвориться отправкой данных ОС, а можно дождаться от неё подтверждения записи.
G>2. Все таки что там с отказоустойчивостью редиса? Предположим у меня две ноды редиса. Один мастер, другой слейв. G>У меня две апп ноды. В рейтинге есть игрок Вася с рейтингом 100. G>а. Приходит событие увеличения рейтинга на 9. Взяли с мастера 100 добавили 9, записали 109 в мастер. Оно полетело в реплику, но еще не долетело. G>б. Приходит событие увеличения рейтинга на 8. Взяли с реплики 100 (!) (т.к. еще не долетело) добавили 8, записали в мастер 108. Итого у нас значение рейтинга 108. А должно было быть 117.
Редис так не работает. Для одной таблицы рейтинга работа всегда идёт с одной нодой(по крайней мере так было раньше, возможно за последние пару лет что-то и изменилось, но я сомневаюсь). Конечно добиться того, чтобы мы ни при каких условиях не потеряли данные в редисе и максимальный уровень доступности очень сложно... Но это не менее сложно и для других систем, да и далеко не всегда нужно.
Производительность редиса достаточно велика чтобы необходимость разделения таблицы не несколько машин возникала у пары десятков проектов в мире у которых определённо хватит ресурсов для того чтобы сделать ещё более специализированное решение, отвечающее их нуждам.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, Danchik, Вы писали:
D>>Здравствуйте, Gattaka, Вы писали:
G>>>Коллеги, G>>>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>>>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
D>>Да кагбы понятно, если не как база данных то бесплатно это: D>>Message Queue G>- реббит, кафка
Это сейчас то есть где развернуться
D>>Cache G>? зачем? оперативка приложения.
Сори Distributed Cache
D>>Sql Server в те времена был слишком платным, а развернуть MMQ был еще тот квест (по слухам). G>Что это такое?
Microsoft Message Queue, что-то я много наопечатывался.
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
Тем, что Sql Server он вообще то платный. Особенно в кластерной конфигурации. С этим платным софтом и лицензиями геморроя как то многовато.
Здравствуйте, Gattaka, Вы писали:
G>GarryIV моментально влепил минус. Без аргументов, без ответа. Это успех. В священных войнах это успех. G>Вполне возможно, что одним только своим вопросом я отправил опонента в больницу. Он успел только поставить минус и схватился за сердце... "Ааа.... мой редис, редис... сердце!" И упал со стула. G>Успех! Хорошо! Как же я силен в этих самых войнах священных.
Уныло потому что. Перетирать одно и то же в надцатый раз. Хоть тебя минусом порадовал, и то хорошо.
Redis is faster than SQL Server for a key/value cache store. About 15x faster for reads and 19x faster for writes according to my tests on a single machine (no clustering or other multi-machine setup).
САД>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов.
А кто мешает класть в сиквел денормализованные данные?
Джо>Redis is faster than SQL Server for a key/value cache store. About 15x faster for reads and 19x faster for writes according to my tests on a single machine (no clustering or other multi-machine setup).
САД>>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов. hlt>А кто мешает класть в сиквел денормализованные данные?
таблица с 100500 колонок?
а потом делать хитрые маппинги плоских сущностей на иэрархию объектов?
но зачем? если можно положить и достать as is
Здравствуйте, Gattaka, Вы писали:
AB>>Тут, вероятно, имелся ввиду distributed cache. Но даже в рамках одного хоста далеко не всегда есть возможность или целесообразность делать кэш в памяти приложения (например для prefork модели или микросервисов). G>Вот зачем давать такие многозначительные ответы, чтобы люди потом гадали что имелось в виду? Да чтобы казаться умнее. Потому как если много скажешь — сразу станет понятно, что аргументов то и нет.
если ты не понимаешь, то это не значит, что остальные тоже не понимают
имелось в виду, что на одном хосте может быть несколько процессов, которым нужен общий кэш. делать кэш в памяти каждого процесса — глупо и неэффективно.
G>И чем же он так хорош как ditributed cache? Как у него с отказоустойчивостью. Если значение попало на одну ноду редиса, то как скоро оно доберется до другой ноды? G>В обще зачем нужен distributed cache? Можно конкретный пример?
это как реплики БД. зачем реплики БД? чтобы снизить нагрузку
Здравствуйте, Gattaka, Вы писали:
G>GarryIV моментально влепил минус. Без аргументов, без ответа. Это успех. В священных войнах это успех.
Я тоже. Просто потому, что вопрос оставляет стойкое послевкусие "is it troll or just very stupid".
Т.е. я понимаю, что подфорум специфический, но в такой формулировке это успех даже для СВ.
САД>таблица с 100500 колонок? САД>а потом делать хитрые маппинги плоских сущностей на иэрархию объектов? САД>но зачем? если можно положить и достать as is
Что такое "as is" в данном случае?
САД>>таблица с 100500 колонок? САД>>а потом делать хитрые маппинги плоских сущностей на иэрархию объектов? САД>>но зачем? если можно положить и достать as is hlt>Что такое "as is" в данном случае?
в каком виде документ положили — в таком и достали.
это очень удобно.
Ops>JSON в постгре — это не просто текст, по нему вполне можно запросы делать. Так что это не просто key-value
можно, я в курсе.
но обычно этого не требуется.
впрочем, такое сейчас и сиквел поддерживает.
но нужно сравнивать перфоманс с специализированными решениями, как тот же монго.
САД>>>таблица с 100500 колонок? САД>>>а потом делать хитрые маппинги плоских сущностей на иэрархию объектов? САД>>>но зачем? если можно положить и достать as is hlt>>Что такое "as is" в данном случае? САД>в каком виде документ положили — в таком и достали. САД>это очень удобно.
Что это за вид такой, в котором в Redis можно положить, а в sql нельзя?
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>можно, я в курсе. САД>но обычно этого не требуется.
Когда не требуется — тогда и монга не нужна. САД>впрочем, такое сейчас и сиквел поддерживает. САД>но нужно сравнивать перфоманс с специализированными решениями, как тот же монго.
По крайней мере индексы по полям json можно строить. А так — конечно, надо сравнивать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Джо>Redis is faster than SQL Server for a key/value cache store. About 15x faster for reads and 19x faster for writes according to my tests on a single machine (no clustering or other multi-machine setup).
Здравствуйте, Gattaka, Вы писали:
G> И чем же он так хорош как ditributed cache? G> Как у него с отказоустойчивостью. G> Если значение попало на одну ноду редиса, то как скоро оно доберется до другой ноды? G> В обще зачем нужен distributed cache? Можно конкретный пример?
Боюсь, что на объяснение базовых практик распределенных систем и цитирование документации по redis я потрачу сильно много времени впустую.
P.S. "В КСВ к звёздам надо приходить подготовленными, а не так как вы: вчера — у подворотни, а сегодня — здесь, на втором ряду..."
Здравствуйте, Anton Batenev, Вы писали:
AB>Боюсь, что на объяснение базовых практик распределенных систем и цитирование документации по redis я потрачу сильно много времени впустую. AB>P.S. "В КСВ к звёздам надо приходить подготовленными, а не так как вы: вчера — у подворотни, а сегодня — здесь, на втором ряду..."
За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
А какой тип лучше подошел бы? Выглядит как аналог типа данных Redis:
Strings are the most basic kind of Redis value. Redis Strings are binary safe, this means that a Redis string can contain any kind of data, for instance a JPEG image or a serialized Ruby object.
A String value can be at max 512 Megabytes in length.
Т.е. значение получаемое по ключу, это произвольная строка переменной длины.
На чтение это же не должно влиять, почему операции чтения медленнее? Кроме того, Redis обеспечивает именно такой уровень изоляции по сути, по скольку он однопоточный.
И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
Здравствуйте, Джо, Вы писали:
Джо>И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
Здравствуйте, Джо, Вы писали:
G>>varchar(max)
Джо>А какой тип лучше подошел бы? Выглядит как аналог типа данных Redis: Джо>
Джо>Strings are the most basic kind of Redis value. Redis Strings are binary safe, this means that a Redis string can contain any kind of data, for instance a JPEG image or a serialized Ruby object.
Джо>A String value can be at max 512 Megabytes in length.
Джо>Т.е. значение получаемое по ключу, это произвольная строка переменной длины.
Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
Джо>>Т.е. значение получаемое по ключу, это произвольная строка переменной длины. G>Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
512Mb vs 2Gb — это примерно одно и тоже. Я смотрю на эксперимент как ответ на вопрос "можно ли создать сервис Redis на базе MS SQL In-memory OLTP". Функционал redis в том что ты можем положить по ключу строку от 0 до 512Mb, какой тип SQL Server для этого подойдет лучше чем varchar(max)? То что фактически он работает со строками длиной в GUID, это детали теста. То что SQL Server не может предоставить аналогичный функционал без деградации производительности говорит о его недостатках когда его заставляют работать как замену Redis.
G>Распространенные базы данных позволяют тебе не думать об алгоритмах. Ты говоришь что тебе нужно, а они уже сами подбирают алгоритм. И уже сами решают как это сделать.
До первой проблемы. В реальном проде надо знать и алгоритмы, как работают блокировки, как устроены уровни изоляции, итд.
Здравствуйте, Gattaka, Вы писали:
G>За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Gattaka, Вы писали:
G>>За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
F>ты просто недостоин этой чести.
Здравствуйте, Джо, Вы писали:
Джо>>>Т.е. значение получаемое по ключу, это произвольная строка переменной длины. G>>Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
Джо>512Mb vs 2Gb — это примерно одно и тоже. Я смотрю на эксперимент как ответ на вопрос "можно ли создать сервис Redis на базе MS SQL In-memory OLTP". Функционал redis в том что ты можем положить по ключу строку от 0 до 512Mb, какой тип SQL Server для этого подойдет лучше чем varchar(max)? То что фактически он работает со строками длиной в GUID, это детали теста. То что SQL Server не может предоставить аналогичный функционал без деградации производительности говорит о его недостатках когда его заставляют работать как замену Redis.
А можно ли в редис положить строчку оптимальным образом не более 200 символов, как это можно в Sql Server?
Здравствуйте, Джо, Вы писали:
Gt_>>чудик наркоман Gt_>>TRANSACTION ISOLATION LEVEL = SNAPSHOT
Джо>На чтение это же не должно влиять, почему операции чтения медленнее? Кроме того, Redis обеспечивает именно такой уровень изоляции по сути, по скольку он однопоточный.
Джо>И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
как видим ошибся. врятли редис мог бы проиграть mysql в трезвых руках
Здравствуйте, Gattaka, Вы писали:
САД>>но в целом, в редис кладут денормализованные данные, и вытащить сущность по ключу значительно быстрее чем из сиквела с кучей джойнов. G>Так сделайте materialized view.
Здравствуйте, Gattaka, Вы писали:
САД>>и для распределенных систем он тоже не всегда под все кейсы подходит напрямую. G>По моим замерам скорость чтения в Sql Server выше, чем в redis.
Ну так код замеров и результат в студию.
G>Ведь Sql Server хранит также свои данные в buffer pool. Т.е. в оперативной памяти.
buffer pool такая штука — случайно залетевший тяжелый запрос может оттуда твой кеш выгнать.
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>таблица с 100500 колонок?
Зачем? В редисе ж никаких колонок нет.
Проблема в сиквеле не в том, что он чего то не может, а в том что при сходной латентности сиквел будет в разы, а то и на порядок дороже.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Gattaka, Вы писали:
G>>Коллеги, G>>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server.
НС>Латентностью. Отличие примерно на порядок.
G>>Итак вопрос, назовите use-case где Redis необходим.
НС>Распределенный кеш кластера, средство синхронизации кластера (кластерные локи, прогресс и т.п.)
Здравствуйте, Gattaka, Вы писали:
НС>>Распределенный кеш кластера, средство синхронизации кластера (кластерные локи, прогресс и т.п.) G>А можешь пример конкретные придумать?
Здравствуйте, Gattaka, Вы писали:
НС>>Не очень понятен вопрос. Примеры чего? G>Пример использования распределенного кеша кластера, средства синхронизации кластера (кластерных локов, прогресса и т.п.)
Типичный пример кеша — при каждом обращении нужен, к примеру, профиль пользователя. Профиль лежит в БД, выборка — сотни мс. Если каждый раз лазать за ним — сервер БД быстро кончится. Поэтому профиль нужно кешировать. В standalone обычно хранят в памяти сервера, но с кластером такой вариант не прокатывает. Поэтому заменяют на распределенный кеш — тоже в памяти, но общий для всего кластера.
С кластерными локами вроде все понятно, не? Иногда нужно обеспечить, чтобы какой то кусочек кода выполнялся в один момент времени строго один раз. Можно, конечно, мутить с DTC, но иногда достаточно несложного решения на баже Редиса.
С прогрессом еще проще. Пусть есть некий асинхронный процесс. А в UI нужно отобразить его состояние. При этом машина, на которой идет процесс, и машина, к которой пришел реквест пользователя могут быть разными. Можно, конечно, через сиквел передавать, но его такими вещами очень просто перегрузить, так как запросов потенциально может быть очень много, хоть и простых. Редис с такими задачами справляется не в пример эффективнее и дешевле.
Здравствуйте, Gattaka, Вы писали:
G>А если редис упал? Потеряем те 13 минут что остались у пользователя? Или как?
Если упал, поднимай, в чем проблема?
G>Такой вариант — заводим в постресе табличку с временем, есть джоба которая раз в 30 сек выгребает оттуда просроченных. Вуаля — все надежно и транзакционно.
С постгрисом другая проблема. Он бывает так нагружен, что его всегда немного разгрузить хочется. Если выделять под это отдельный постгрис, то нужная нам транзакционность по сути теряется. Для разгрузки редис и применяется, под различные распределенные кеши, под управление фоновыми задачами. FTS, MQ тоже выделяют в отдельные сервисы.
Еще в редис можно сложить и анализировать потом всякую не сильно критичную к утере, но важную для бизнеса информацию — статистику просмотров, лайки, букмарки. Потом искать по ним что-то типа "вам может быть интересно", не терзая основную БД, с помощью его операций со множествами.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, Джо, Вы писали:
Джо>>И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
G>Инструмент для тупых?
Чтобы отрезать кусок хлеба вы берёте простой кухонный нож или же швейцарский?
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>Не сочтите за троллинг. Реально не особо понятно чем он луче просто Sql Server. Мне думается, что те аргументы что вы приведете в пользу Redis я смогу опровергнуть опять же аргументированно. Давайте попробуем? G>Итак вопрос, назовите use-case где Redis необходим. Давайте наберем несколько таких Use Cases.
С какой стати это мы должны что-либо аргументировать и придумывать юзкейсы, которые смогут убедить тебя?
Давай пойдём от обратного. Скажем, тебе нужно _хранить_ самые обычные структуры данных: списки, множества, сортируемые множества, хештаблицы, счётчики.
Обоснуй, почему реляционная модель для этого подходит лучше. Как по мне, так это извращение.
К>С какой стати это мы должны что-либо аргументировать и придумывать юзкейсы, которые смогут убедить тебя? К>Давай пойдём от обратного. Скажем, тебе нужно _хранить_ самые обычные структуры данных: списки, множества, сортируемые множества, хештаблицы, счётчики. К>Обоснуй, почему реляционная модель для этого подходит лучше. Как по мне, так это извращение.
Сам обоснуй!
Здравствуйте, Крякозавр, Вы писали:
К>Здравствуйте, Gattaka, Вы писали:
G>>Здравствуйте, Джо, Вы писали:
Джо>>>И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
G>>Инструмент для тупых?
К>Чтобы отрезать кусок хлеба вы берёте простой кухонный нож или же швейцарский?
Все делаю одним кухонным ножом. Швейцарский нож не нужен. Фигня. На помойку.
G>И так ясно, оперативка дорогая. Веб ноды будут золотыми буквально. Врят ли они будут утилизировать всегда всю память. Это успех. Плюс. В докере должен быть только один процесс. Так что опять успех!
Это не так.
Lifetime контейнера определяется временем жизни основного pid 0 процесса, который может запускать произвольное количество child процессов. См supervisord, s6 daemon и т.п.
Здравствуйте, Vetal_ca, Вы писали:
V_>Это не так.
V_>Lifetime контейнера определяется временем жизни основного pid 0 процесса, который может запускать произвольное количество child процессов. См supervisord, s6 daemon и т.п.
