Коллеги,
Не сочтите за троллинг. Реально не особо понятно чем он луче просто 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>Окей. Тут скорее всего какая-то дичь с этой самой бизнес логикой. Нужно смотреть откуда взялись эти дикие джойны и постараться свести все к более простым джойнам быть может даже с помощью дублирования данных.
нет необходимости извращаться, если есть редис
сиквел быстрый и хороший, но не достаточно быстрый. увы.
потому в хайлоаде юзают денормализацию.
и для распределенных систем он тоже не всегда под все кейсы подходит напрямую.
