Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск СУБД Redis 8.2"	+/–
Сообщение от opennews (ok), 11-Авг-25, 17:58
Опубликован релиз СУБД Redis 8.2, относящейся к классу NoSQL-систем. Redis предоставляет функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества, а также возможностью выполнения на стороне сервера скриптов-обработчиков на языке Lua.  Код проекта написан на язык Си и распространяется под лицензией AGPLv3... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63709
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 11-Авг-25, 18:02	+4 +/–
И даже оптимизации на 30% не покрывают издержек на лицензии в нашем случае, и договориться на более подходящие условия с Redis Inc. не удалось. Поэтому примерно 70ТБ в проде и еще 10ТБ в разработке и тестировании переехали в valkey. Надо сказать, это была самая безболезненная миграция на моей памяти. Drop-in в лучшем виде.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #7, #9, #14

3. Сообщение от abi (?), 11-Авг-25, 18:15	+2 +/–
Мы всё проспали, пока сидели на старой версии, лицензию назад вернули
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5, #6, #10

4. Сообщение от Аноним (4), 11-Авг-25, 18:17	+1 +/–
Нужен новый тест бенчей
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

5. Сообщение от Аноним (5), 11-Авг-25, 18:46	+3 +/–
Да всё уже, ясно же, что потом опять поменяют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8

6. Сообщение от Аноним (2), 11-Авг-25, 18:48	+/–
Мы как раз были готовы мигрировать прод когда лицензию откатили обратно, но руководство решило, что эти качели туда-сюда хуже для бизнеса чем пара лишних инстансов и миграция состоялась. Я думаю ещё то, что Redis Inc. упёрлись рогом по стоимости и структуре лицензий сыграло роль. Это вообще редкость чтобы нам что-то было нужно и не смогли договориться. Ну да ладно, мне так точно без разницы как софт называется, мне за это мнение денег не платят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

7. Сообщение от Ilya Indigo (ok), 11-Авг-25, 18:53	+/–
Чем вам лицензия AGPL-3.0-only НЕ устраивает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13, #16

8. Сообщение от Ilya Indigo (ok), 11-Авг-25, 18:56	–11 +/–
Аргументация полного идиота! Что вам ясно? Назовите мне хоть 1 прецедент, где лицензия была свободной, потом сменили, на НЕ свободную, потом снова изменили на свободную, а потом во второй раз сменили на НЕ свободную?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #11, #27

9. Сообщение от минона (?), 11-Авг-25, 18:58	+/–
Думаю, можно дождаться релиза Valkey
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

10. Сообщение от Ilya Indigo (ok), 11-Авг-25, 18:59	–2 +/–
Не совсем, они НЕ вернули MIT, а добавили AGPL-3.0-only. Сейчас у redis тройная лицензия. License change: licensed under your choice of     (a) the Redis Source Available License 2.0 (RSALv2); or     (b) the Server Side Public License v1 (SSPLv1); or     (c) the GNU Affero General Public License (AGPLv3)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #15

11. Сообщение от Аноним (5), 11-Авг-25, 19:14	+/–
А что, есть прецеденты, где все не ливнули разу после таких выкрутасов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

13. Сообщение от Аноним (5), 11-Авг-25, 19:18	–2 +/–
> Чем вам лицензия AGPL-3.0-only НЕ устраивает? Это обычно только начало. Под AGPL идёт куцая обглоданная версия, под полной лицензией всё остальное. Ну и практически AGPL очень плохая лицензия буквально для примерно любого коммерческого использования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

14. Сообщение от penetrator (?), 11-Авг-25, 19:35	–1 +/–
а сколько у тебя серверов используется? и что это за массив такой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #17

15. Сообщение от Аноним (15), 11-Авг-25, 20:01	+1 +/–
Почему у тебя на аватарке Хёрли из Остаться в живых?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (2), 11-Авг-25, 20:04    Скрыто ботом-модератором	+/–
Тринадцатым параграфом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

17. Сообщение от Аноним (2), 11-Авг-25, 20:09	–2 +/–
> а сколько у тебя серверов используется? У меня — ноль. Я живу в обычном доме и не владею датацентром. Необходимости в серверах у себя в хозяйстве не нашёл. > и что это за массив такой? Какой «такой»? Если есть конкретные вопросы задавай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

18. Сообщение от mumu (ok), 11-Авг-25, 20:43	–1 +/–
Один из редких примеров, когда ит-шечка развивает в правильном направлении и радует год от года. Сейчас очень мало таких стало.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

20. Сообщение от Кодогенератор (?), 12-Авг-25, 09:37	+/–
Pogocache кто-то пробовал? Автор хвалится что рвёт всех левой пяткой, и Редис тоже.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #23, #24

21. Сообщение от Димасс (?), 12-Авг-25, 10:26	–1 +/–
чем дольше живешь, тем больше понимаешь что куда важнее стабильность. Чем 10,20,да хоть 50% выше производительность, но которое может крашнуться и твой сервис станет вообще недоступен. Так что если вы молодой разработчик пробуйте стабильные вещи, которые давно на рынке. Плюс перед начальство проще защищать свой выбор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22

22. Сообщение от Заноним (?), 12-Авг-25, 18:23	+1 +/–
Быстродействие важнее. И нет никакой стабильности - любой сервис/сервер может покрошиться. Есть отказоустойчивость, её и следует реализовывать на практике. И не нужно молодым свои страхи навязывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

23. Сообщение от Аноним (2), 12-Авг-25, 18:33	+1 +/–
Интересный проект, но пока что хорош только для локалхоста: > Pogocache's initial goal was to create the fastest, most efficent cache. > Next steps are: > […] > Provide enterprise tooling such as distributed routing and failovers. Я из опыта знаю, насколько сложно правильно реализовать и distributed routing, и failover. И как это может замедлить систему в целом. Второй момент (на самом деле, первый): всё это появилось вчера и разрабатывается неизвестно кем и по каким принципам. Завтра разработчику всё наскучит, появятся дети, упрётся в лимит своих знаний и навыков, умрёт любимый хомяк, и проект будет закрыт. С таким business continuity не построишь. Если выживет хотя бы пару лет и появится inc. — будет о чём поговорить. Но замах на рубль: и все важные wire protocols поддерживает, и латенси (что дико бесит в редисе, кстати) на уровне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #37

24. Сообщение от Заноним (?), 12-Авг-25, 18:42	+1 +/–
Судя по описанию проделанных автором бенчмарков - ему надо ещё поковырять на предмет вертикального масштабирования. Garnet намного производительнее, чем в его бенчах. Например на железках в 256 ядер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

25. Сообщение от Заноним (?), 12-Авг-25, 19:26	+1 +/–
Всё такой же медленный: https://anonpaste.com/share/redis-803-2b9e0e8b94 https://anonpaste.com/share/redis-820-b1225895b7 https://anonpaste.com/share/garnet-1078-801ed06641
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

26. Сообщение от SubGun (ok), 12-Авг-25, 23:34	+3 +/–
Вот не про редис точно такое говорить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

27. Сообщение от Мукулутуру (?), 13-Авг-25, 07:51	+1 +/–
Достаточно одного раза, чтоб учитывать риски. Сейчас переезд стоит копейки, завтра ломается совместимость - и приехали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

29. Сообщение от freehck (ok), 15-Авг-25, 00:51	+/–
Оба неправы, потому что веруете в абсолюты. Что важнее, стабильность или быстродействие -- зависит от задачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30

30. Сообщение от Заноним (?), 15-Авг-25, 03:59	+/–
> Оба неправы, потому что веруете в абсолюты. Сам понял что сказал? С верующими это тебе не сюда. > Что важнее, стабильность или быстродействие -- зависит от задачи. Стабильности как не было так и нет. Отсюда следует автоматом, что быстродействие важнее. И вне зависимости от задач (если ещё говорим о процессах выполняющихся на СPU/GPU и других PU).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от freehck (ok), 15-Авг-25, 09:51	–1 +/–
>> Оба неправы, потому что веруете в абсолюты. > Сам понял что сказал? С верующими это тебе не сюда. Боюсь, Вам придётся перечитывать, ибо упрощать эту мысль уже просто некуда. >> Что важнее, стабильность или быстродействие -- зависит от задачи. > Стабильности как не было так и нет. > Есть отказоустойчивость Очевидно, что в контексте данного треда это -- синонимы. Не будь душнилой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #32

32. Сообщение от Заноним (?), 15-Авг-25, 12:45	+1 +/–
>>> Оба неправы, потому что веруете в абсолюты. >> Сам понял что сказал? С верующими это тебе не сюда. > Боюсь, Вам придётся перечитывать, ибо упрощать эту мысль уже просто некуда. Вот и перечитай сам несколько раз включив критическое мышление в отношении своего высказывания. >>> Что важнее, стабильность или быстродействие -- зависит от задачи. >> Стабильности как не было так и нет. >> Есть отказоустойчивость > Очевидно, что в контексте данного треда это -- синонимы. Не будь душнилой. Нет это не синонимы, вообще ни разу. Здесь как раз и надо быть душнилой. В контексте данного треда чел залечил с предложением молодому разработчику не гнаться за производительностью, а пробовать "стабильные вещи" (отсылая к тому, что-бы использовать redis, эдакий вариант консервативного взгляда, от чела не реализующего отказоустойчивость) для того что-бы обеспечить устойчивость сервиса. Только это не инженерный подход, а подход домохозяйки. В вычислительной технике можно вводить понятие о условной (локальной) стабильности - это понятие вводится когда аппаратура/система/алгоритм проявляет устойчивость на каком-то интервале времени, что и делают инженеры понимая, что нет никакой стабильности, для этого ввели метрики MTBF, MTTF, а для сервисов SLA - доступность сервиса, которую пользователи(!) могут воспринимать как "стабильность". И что-бы обеспечить приемлемый уровень доступности сервиса, применяют методы обеспечения отказоустойчивости, изначально закладывая в архитектуру ненадёжность отдельно взятых элементов реализующих сервис. А повышению производительности подчинено буквально всё развитие вычислительной техники. И по факту именно быстродействие определяет что использовать (особенно при росте нагрузок, когда доступность сервиса начинает снижаться), и дальше в работу идут методы реализации отказоустойчивости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #33

33. Сообщение от Аноним (2), 16-Авг-25, 21:08	+/–
> И по факту именно быстродействие определяет что использовать (особенно при росте нагрузок, когда доступность сервиса начинает снижаться), и дальше в работу идут методы реализации отказоустойчивости. Вот софт, работает очень быстро, но крашится каждые 13 секунд из-за ошибок. Вот другой софт, работает на 30% медленнее, но крашится только при отказе оборудования. Угадай, какой будет выбран инженером? Выучить пару аббревиатур и болтать с умным видом тут любой горазд. Ежедневная реальность эксплуатации чужого ПО в проде — совсем иная история.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #34

34. Сообщение от Заноним (?), 16-Авг-25, 23:10	+/–
> Вот софт, работает очень быстро, но крашится каждые 13 секунд из-за ошибок. > Вот другой софт, работает на 30% медленнее, но крашится только при отказе оборудования. Угадай, какой будет выбран инженером? А чего 30%? Это несущественно. Давай 300% или 3000% или 30000% медленнее? Если софт не крашится 13 секунд, но гораздо быстрее, то для инженера это повод  изучить почему он крашится через 13с и исправить, а не выбирать более тормозное решение. > Выучить пару аббревиатур и  болтать с умным видом тут любой горазд. Ежедневная реальность эксплуатации чужого ПО в проде — совсем иная история. Мимо со своими домыслами на чужой счёт ходи, не отсвечивай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #35

35. Сообщение от freehck (ok), 18-Авг-25, 11:58	+/–
> Если софт не крашится 13 секунд, но гораздо быстрее, то для > инженера это повод  изучить почему он крашится через 13с и > исправить, а не выбирать более тормозное решение. Нифига. Критерий выбора -- это не производительность софта, а стоимость его сопровождения. Во-первых, люди стоят дороже железа. Вместо того, чтобы оплачивать труд инженера, разгребающего косяки нового производительного, но относительно сырого решения -- дешевле и безопаснее тормозному, но стабильному решению накинуть парочку нод/инстансов. Во-вторых, проблемы нового решения -- не прогнозируемы. Ты не можешь быть уверен, где и когда они выстрелят, пока по нему не накоплена экспертиза. Ты не можешь сказать, сколько времени потратят твои люди на решение этих проблем. В случае их возникновения, всё это -- опять же расходы. Иными словами, лучше выбирать известное зло неизвестному. Утягивать себе в прод молодые производительные решения -- это банально дорого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #36

36. Сообщение от Заноним (?), 18-Авг-25, 13:48	+/–
Нет, стоимость сопровождения это один из критериев выбора, но совсем не главный критерий. Если считать TCO, то именно производительность определяет всё, и сколько надо нод и сколько  надо инженеров. И накинуть нод может быть дешевле, только если у тебя уже в эксплуатации решение с большими объёмами данных, и производительности что-бы всё это перелопатить за разумное время в более быстрое решение недостаточно. В общем и целом, если сравнивать стоимости сопровождения, то вываливается лень сисадмина/девопса/программиста - если он/они не на почасовой оплате, а на ЗП, то стоимость сопровождения софтины в среднем одинакова, что для нового софта, что для старого. Бизнес же считает TCO - если более быстрое решение позволяет значительно снизить расходы или увеличить доходы, то его просто запустят рядом со старым решением, потом проведут миграцию и уберут старое решение.   Баги есть во всех приложения и не важно насколько они устойчивы, например тот же самый redis, кажущийся многим надёжным решением, при некоторых условиях превращается в падучий говнокод. И если никто не будет использовать новые производительные решения, никакой экспертизы накоплено не будет. Вся эта плеяда "сидящих с краю" никуда ничего не двигает. А молодым именно, что надо использовать новые решения, накапливать новую экспертизу и двигать прогресс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #38

37. Сообщение от funny.falcon (?), 18-Авг-25, 16:39	+/–
Автор pogocache - известный в узких кругах профессионал. Я уверен, что у него опыта хватит для допиливания любого функционала. А чтобы интерес не погас, он организовал фирму по продаже pogocache. Ну и, кстати, у pogocache не такая уж и свободная лицензия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

38. Сообщение от freehck (ok), 18-Авг-25, 16:53	+/–
> Если считать TCO, то именно производительность определяет всё, и сколько надо нод и сколько  надо инженеров. Я пожалуй могу согласиться, что в компаниях масштабов Amazon или Google это действительно так. Однако надо понимать, что эти гиганты рулят рисками на качественно ином уровне: они могут себе позволить нанимать узких специалистов, специализирующихся на вполне определённых инструментах. Но таких компаний мало, количество мест в них ограничено, да и по деньгам подобных узких специалистов они обидят. Потому рекомендовать молодым двигаться именно в эту сторону -- я бы не стал. Компании же, в которые скорее всего молодняк попадёт, с большой долей вероятности будут искать специалиста широкого профиля. И поскольку, как известно, опсов мало, разработчиков много, а архитектура большая -- чтобы иметь возможность контролировать инфру, нужно использовать именно стабильные решения. > И накинуть нод может быть дешевле, только если у тебя уже в эксплуатации решение с большими объёмами данных, и производительности что-бы всё это перелопатить за разумное время в более быстрое решение недостаточно. Либо если у бизнеса большие объёмы данных, либо если у бизнеса недостаток специалистов, которые могли бы этим заняться. Большинство компаний, особенно стартапов, где собственно самые деньги и крутятся, не нанимают узких специалистов под конкретную задачу. > Баги есть во всех приложения и не важно насколько они устойчивы, например тот же самый redis, кажущийся многим надёжным решением, при некоторых условиях превращается в падучий говнокод. И? У каждого софта, равно как и у каждого физического закона, есть область применения. Вот тот же redis отлично работает в весьма широком диапазоне нагрузок, его можно масштабировать с полпинка, его можно быстро внедрить. Если компания выживает и выходит на пределы его возможностей -- там уже можно будет подумать о замене. Это быстрое и дешёвое решение, потому и используется.   > И если никто не будет использовать новые производительные решения, никакой экспертизы накоплено не будет. Вот пускай экспертизу накапливают гиганты, которые эти инструменты и продвигают. Всё за их счёт, пожалуйста. Не вижу причин, почему за это должен платить я, и уж тем более -- молодняк. > Вся эта плеяда "сидящих с краю" никуда ничего не двигает. А нам клиенты деньги платят не за то, что мы прогресс двигаем, а за множество девяток в SLA. >  А молодым именно, что надо использовать новые решения, накапливать новую экспертизу и двигать прогресс. К сожалению, подобно тому, что большинству рокеров не суждено стать звёздами, так и установки "двигать прогресс" и "обеспечить себе высокий стабильный доход" -- для большинства специалистов окажутся в противофазе. -- И потому моя рекомендация молодым: использовать стабильные инструменты, а не гнаться изучать новомодные приблуды, что бы они там ни обещали. Новомодные приблуды можно изучать лишь в дополнение к стабильным широко используемым инструментам с накопленной экспертизой эксплуатаци, но никак не вместо. PS: Ну а в целом, мы оба пришли к тому, что TCO определяет всё. Вот только ты, похоже, считаешь с точки зрения интересов мега-корпов с неограниченными ресурсами и "прогресса", и у тебя естественным образом получается, что TCO определяется производительностью... А я считаю -- с точки зрения стартапа и возможностей заработка конкретно молодняка, которому мы и советуем; и у меня получается, что TCO определяется всё-таки по большей мере стабильностью. Но тем не менее, сойдясь на TCO, мы таким образом пришли к моему изначальному тезису: что важнее, стабильность или быстродействие -- таки зависит от вводных параметров, с которыми мы подходим к решению конкретной задачи. А значит спорить нам в общем-то не о чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #39

39. Сообщение от Заноним (?), 19-Авг-25, 02:01	+/–
В ходе полемики я не приходил к тому, что TCO определяет всё. Это мне известно где-то с 2000г, после прочтения книжечек ibm redbook по aix. Мой тезис в том, что для вычислительной техники и софта именно производительность является определяющей в TCO, а не эфемерная стабильность. И производительность является основным критерием для любого уровня - без разницы стартап на троих или google. Ещё раз - нет стабильного софта, есть отказоустойчивость, через которую и обеспечиваются девятки в SLA. И redis никогда не был устойчивым и масштабируется он только горизонтально, причём посредственно, со значительным оверхедом. Он просто стал массовым. А хорошо масштабируется например garnet, относительно новый софт, но в разы и даже на порядки превосходящий redis. И двигают прогресс не столько корпорации, сколько именно молодые, пытливые. Да, тот же redis как раз пример того, как отдельно взятому челу потребовалось масштабировать его стартап и для этого он разработал инструмент для анализа. При этом уже как 6 лет существовал "проверенный" и "стабильный" memcached, который тоже появился в результате стремления чела увеличить производительность стартапа. И ключевой момент в том, что-бы не загнать молодых своими посылами в "стабильность", пусть изначально знают, что нет её.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #40

40. Сообщение от freehck (ok), 19-Авг-25, 15:31	+/–
> Ещё раз - нет стабильного софта, есть отказоустойчивость, через которую и обеспечиваются девятки в SLA. Ещё раз -- стабильный софт есть, и от нестабильного он отличается частотой сбоев. Обеспечивать отказоустойчивость для стабильного софта легче и дешевле, нежели для нестабильного. Сбои -- требуют реакции инженеров, даже если не приводят к отказам. Оплата их труда учитывается в TCO. Поскольку люди стоят дороже железа, смысл выбирать более стабильный софт смысл очень даже бывает. > И redis никогда не был устойчивым и масштабируется он только горизонтально, причём посредственно, со значительным оверхедом. Смотря на каких нагрузках. На 50k qps он работает отлично. > А хорошо масштабируется например garnet, относительно новый софт, но в разы и даже на порядки превосходящий redis. Да, garnet хорош. Мы сами его в тестовом режиме на одном из проектов гоняем. Полёт нормальный. > И ключевой момент в том, чтобы не загнать молодых своими посылами в "стабильность", пусть изначально знают, что нет её. Странно говорить об отсутствии стабильности, ориентируясь только на граничные условия эксплуатации софта. Что redis, что garnet -- оба достаточно стабильные продукты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема