Опубликован релиз СУБД Redis 8.2, относящейся к классу NoSQL-систем. Redis предоставляет функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества, а также возможностью выполнения на стороне сервера скриптов-обработчиков на языке Lua. Код проекта написан на язык Си и распространяется под лицензией AGPLv3...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63709
И даже оптимизации на 30% не покрывают издержек на лицензии в нашем случае, и договориться на более подходящие условия с Redis Inc. не удалось. Поэтому примерно 70ТБ в проде и еще 10ТБ в разработке и тестировании переехали в valkey. Надо сказать, это была самая безболезненная миграция на моей памяти. Drop-in в лучшем виде.
Мы всё проспали, пока сидели на старой версии, лицензию назад вернули
Да всё уже, ясно же, что потом опять поменяют.
Аргументация полного идиота!
Что вам ясно?
Назовите мне хоть 1 прецедент, где лицензия была свободной, потом сменили, на НЕ свободную, потом снова изменили на свободную, а потом во второй раз сменили на НЕ свободную?
А что, есть прецеденты, где все не ливнули разу после таких выкрутасов?
Достаточно одного раза, чтоб учитывать риски.
Сейчас переезд стоит копейки, завтра ломается совместимость - и приехали.
Мы как раз были готовы мигрировать прод когда лицензию откатили обратно, но руководство решило, что эти качели туда-сюда хуже для бизнеса чем пара лишних инстансов и миграция состоялась. Я думаю ещё то, что Redis Inc. упёрлись рогом по стоимости и структуре лицензий сыграло роль. Это вообще редкость чтобы нам что-то было нужно и не смогли договориться. Ну да ладно, мне так точно без разницы как софт называется, мне за это мнение денег не платят.
Не совсем, они НЕ вернули 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)
Почему у тебя на аватарке Хёрли из Остаться в живых?
Чем вам лицензия AGPL-3.0-only НЕ устраивает?
> Чем вам лицензия AGPL-3.0-only НЕ устраивает?Это обычно только начало. Под AGPL идёт куцая обглоданная версия, под полной лицензией всё остальное. Ну и практически AGPL очень плохая лицензия буквально для примерно любого коммерческого использования.
Тринадцатым параграфом.
Думаю, можно дождаться релиза Valkey
а сколько у тебя серверов используется?и что это за массив такой?
> а сколько у тебя серверов используется?У меня — ноль. Я живу в обычном доме и не владею датацентром. Необходимости в серверах у себя в хозяйстве не нашёл.
> и что это за массив такой?
Какой «такой»? Если есть конкретные вопросы задавай.
Нужен новый тест бенчей
Всё такой же медленный:
https://anonpaste.com/share/redis-803-2b9e0e8b94
https://anonpaste.com/share/redis-820-b1225895b7
https://anonpaste.com/share/garnet-1078-801ed06641
Один из редких примеров, когда ит-шечка развивает в правильном направлении и радует год от года. Сейчас очень мало таких стало.
Вот не про редис точно такое говорить.
Pogocache кто-то пробовал? Автор хвалится что рвёт всех левой пяткой, и Редис тоже.
чем дольше живешь, тем больше понимаешь что куда важнее стабильность. Чем 10,20,да хоть 50% выше производительность, но которое может крашнуться и твой сервис станет вообще недоступен. Так что если вы молодой разработчик пробуйте стабильные вещи, которые давно на рынке. Плюс перед начальство проще защищать свой выбор.
Быстродействие важнее.
И нет никакой стабильности - любой сервис/сервер может покрошиться.
Есть отказоустойчивость, её и следует реализовывать на практике.И не нужно молодым свои страхи навязывать.
Оба неправы, потому что веруете в абсолюты.
Что важнее, стабильность или быстродействие -- зависит от задачи.
> Оба неправы, потому что веруете в абсолюты.Сам понял что сказал? С верующими это тебе не сюда.
> Что важнее, стабильность или быстродействие -- зависит от задачи.
Стабильности как не было так и нет. Отсюда следует автоматом, что быстродействие важнее. И вне зависимости от задач (если ещё говорим о процессах выполняющихся на СPU/GPU и других PU).
>> Оба неправы, потому что веруете в абсолюты.
> Сам понял что сказал? С верующими это тебе не сюда.Боюсь, Вам придётся перечитывать, ибо упрощать эту мысль уже просто некуда.
>> Что важнее, стабильность или быстродействие -- зависит от задачи.
> Стабильности как не было так и нет.
> Есть отказоустойчивостьОчевидно, что в контексте данного треда это -- синонимы. Не будь душнилой.
>>> Оба неправы, потому что веруете в абсолюты.
>> Сам понял что сказал? С верующими это тебе не сюда.
> Боюсь, Вам придётся перечитывать, ибо упрощать эту мысль уже просто некуда.Вот и перечитай сам несколько раз включив критическое мышление в отношении своего высказывания.
>>> Что важнее, стабильность или быстродействие -- зависит от задачи.
>> Стабильности как не было так и нет.
>> Есть отказоустойчивость
> Очевидно, что в контексте данного треда это -- синонимы. Не будь душнилой.Нет это не синонимы, вообще ни разу. Здесь как раз и надо быть душнилой.
В контексте данного треда чел залечил с предложением молодому разработчику не гнаться за производительностью, а пробовать "стабильные вещи" (отсылая к тому, что-бы использовать redis, эдакий вариант консервативного взгляда, от чела не реализующего отказоустойчивость) для того что-бы обеспечить устойчивость сервиса. Только это не инженерный подход, а подход домохозяйки. В вычислительной технике можно вводить понятие о условной (локальной) стабильности - это понятие вводится когда аппаратура/система/алгоритм проявляет устойчивость на каком-то интервале времени, что и делают инженеры понимая, что нет никакой стабильности, для этого ввели метрики MTBF, MTTF, а для сервисов SLA - доступность сервиса, которую пользователи(!) могут воспринимать как "стабильность". И что-бы обеспечить приемлемый уровень доступности сервиса, применяют методы обеспечения отказоустойчивости, изначально закладывая в архитектуру ненадёжность отдельно взятых элементов реализующих сервис. А повышению производительности подчинено буквально всё развитие вычислительной техники. И по факту именно быстродействие определяет что использовать (особенно при росте нагрузок, когда доступность сервиса начинает снижаться), и дальше в работу идут методы реализации отказоустойчивости.
> И по факту именно быстродействие определяет что использовать (особенно при росте нагрузок, когда доступность сервиса начинает снижаться), и дальше в работу идут методы реализации отказоустойчивости.Вот софт, работает очень быстро, но крашится каждые 13 секунд из-за ошибок. Вот другой софт, работает на 30% медленнее, но крашится только при отказе оборудования. Угадай, какой будет выбран инженером? Выучить пару аббревиатур и болтать с умным видом тут любой горазд. Ежедневная реальность эксплуатации чужого ПО в проде — совсем иная история.
> Вот софт, работает очень быстро, но крашится каждые 13 секунд из-за ошибок.
> Вот другой софт, работает на 30% медленнее, но крашится только при отказе оборудования. Угадай, какой будет выбран инженером?А чего 30%? Это несущественно. Давай 300% или 3000% или 30000% медленнее? Если софт не крашится 13 секунд, но гораздо быстрее, то для инженера это повод изучить почему он крашится через 13с и исправить, а не выбирать более тормозное решение.
> Выучить пару аббревиатур и болтать с умным видом тут любой горазд. Ежедневная реальность эксплуатации чужого ПО в проде — совсем иная история.
Мимо со своими домыслами на чужой счёт ходи, не отсвечивай.
> Если софт не крашится 13 секунд, но гораздо быстрее, то для
> инженера это повод изучить почему он крашится через 13с и
> исправить, а не выбирать более тормозное решение.Нифига. Критерий выбора -- это не производительность софта, а стоимость его сопровождения.
Во-первых, люди стоят дороже железа. Вместо того, чтобы оплачивать труд инженера, разгребающего косяки нового производительного, но относительно сырого решения -- дешевле и безопаснее тормозному, но стабильному решению накинуть парочку нод/инстансов.
Во-вторых, проблемы нового решения -- не прогнозируемы. Ты не можешь быть уверен, где и когда они выстрелят, пока по нему не накоплена экспертиза. Ты не можешь сказать, сколько времени потратят твои люди на решение этих проблем. В случае их возникновения, всё это -- опять же расходы.
Иными словами, лучше выбирать известное зло неизвестному. Утягивать себе в прод молодые производительные решения -- это банально дорого.
Нет, стоимость сопровождения это один из критериев выбора, но совсем не главный критерий.
Если считать TCO, то именно производительность определяет всё, и сколько надо нод и сколько надо инженеров. И накинуть нод может быть дешевле, только если у тебя уже в эксплуатации решение с большими объёмами данных, и производительности что-бы всё это перелопатить за разумное время в более быстрое решение недостаточно.В общем и целом, если сравнивать стоимости сопровождения, то вываливается лень сисадмина/девопса/программиста - если он/они не на почасовой оплате, а на ЗП, то стоимость сопровождения софтины в среднем одинакова, что для нового софта, что для старого. Бизнес же считает TCO - если более быстрое решение позволяет значительно снизить расходы или увеличить доходы, то его просто запустят рядом со старым решением, потом проведут миграцию и уберут старое решение.
Баги есть во всех приложения и не важно насколько они устойчивы, например тот же самый redis, кажущийся многим надёжным решением, при некоторых условиях превращается в падучий говнокод.
И если никто не будет использовать новые производительные решения, никакой экспертизы накоплено не будет. Вся эта плеяда "сидящих с краю" никуда ничего не двигает. А молодым именно, что надо использовать новые решения, накапливать новую экспертизу и двигать прогресс.
> Если считать TCO, то именно производительность определяет всё, и сколько надо нод и сколько надо инженеров.Я пожалуй могу согласиться, что в компаниях масштабов Amazon или Google это действительно так. Однако надо понимать, что эти гиганты рулят рисками на качественно ином уровне: они могут себе позволить нанимать узких специалистов, специализирующихся на вполне определённых инструментах. Но таких компаний мало, количество мест в них ограничено, да и по деньгам подобных узких специалистов они обидят. Потому рекомендовать молодым двигаться именно в эту сторону -- я бы не стал.
Компании же, в которые скорее всего молодняк попадёт, с большой долей вероятности будут искать специалиста широкого профиля. И поскольку, как известно, опсов мало, разработчиков много, а архитектура большая -- чтобы иметь возможность контролировать инфру, нужно использовать именно стабильные решения.
> И накинуть нод может быть дешевле, только если у тебя уже в эксплуатации решение с большими объёмами данных, и производительности что-бы всё это перелопатить за разумное время в более быстрое решение недостаточно.
Либо если у бизнеса большие объёмы данных, либо если у бизнеса недостаток специалистов, которые могли бы этим заняться. Большинство компаний, особенно стартапов, где собственно самые деньги и крутятся, не нанимают узких специалистов под конкретную задачу.
> Баги есть во всех приложения и не важно насколько они устойчивы, например тот же самый redis, кажущийся многим надёжным решением, при некоторых условиях превращается в падучий говнокод.И? У каждого софта, равно как и у каждого физического закона, есть область применения. Вот тот же redis отлично работает в весьма широком диапазоне нагрузок, его можно масштабировать с полпинка, его можно быстро внедрить. Если компания выживает и выходит на пределы его возможностей -- там уже можно будет подумать о замене. Это быстрое и дешёвое решение, потому и используется.
> И если никто не будет использовать новые производительные решения, никакой экспертизы накоплено не будет.
Вот пускай экспертизу накапливают гиганты, которые эти инструменты и продвигают. Всё за их счёт, пожалуйста. Не вижу причин, почему за это должен платить я, и уж тем более -- молодняк.
> Вся эта плеяда "сидящих с краю" никуда ничего не двигает.
А нам клиенты деньги платят не за то, что мы прогресс двигаем, а за множество девяток в SLA.
> А молодым именно, что надо использовать новые решения, накапливать новую экспертизу и двигать прогресс.
К сожалению, подобно тому, что большинству рокеров не суждено стать звёздами, так и установки "двигать прогресс" и "обеспечить себе высокий стабильный доход" -- для большинства специалистов окажутся в противофазе.
--
И потому моя рекомендация молодым: использовать стабильные инструменты, а не гнаться изучать новомодные приблуды, что бы они там ни обещали. Новомодные приблуды можно изучать лишь в дополнение к стабильным широко используемым инструментам с накопленной экспертизой эксплуатаци, но никак не вместо.
PS:
Ну а в целом, мы оба пришли к тому, что TCO определяет всё. Вот только ты, похоже, считаешь с точки зрения интересов мега-корпов с неограниченными ресурсами и "прогресса", и у тебя естественным образом получается, что TCO определяется производительностью... А я считаю -- с точки зрения стартапа и возможностей заработка конкретно молодняка, которому мы и советуем; и у меня получается, что TCO определяется всё-таки по большей мере стабильностью.
Но тем не менее, сойдясь на TCO, мы таким образом пришли к моему изначальному тезису: что важнее, стабильность или быстродействие -- таки зависит от вводных параметров, с которыми мы подходим к решению конкретной задачи. А значит спорить нам в общем-то не о чем.
В ходе полемики я не приходил к тому, что TCO определяет всё. Это мне известно где-то с 2000г, после прочтения книжечек ibm redbook по aix.Мой тезис в том, что для вычислительной техники и софта именно производительность является определяющей в TCO, а не эфемерная стабильность.
И производительность является основным критерием для любого уровня - без разницы стартап на троих или google.
Ещё раз - нет стабильного софта, есть отказоустойчивость, через которую и обеспечиваются девятки в SLA.
И redis никогда не был устойчивым и масштабируется он только горизонтально, причём посредственно, со значительным оверхедом. Он просто стал массовым. А хорошо масштабируется например garnet, относительно новый софт, но в разы и даже на порядки превосходящий redis.
И двигают прогресс не столько корпорации, сколько именно молодые, пытливые. Да, тот же redis как раз пример того, как отдельно взятому челу потребовалось масштабировать его стартап и для этого он разработал инструмент для анализа. При этом уже как 6 лет существовал "проверенный" и "стабильный" memcached, который тоже появился в результате стремления чела увеличить производительность стартапа.
И ключевой момент в том, что-бы не загнать молодых своими посылами в "стабильность", пусть изначально знают, что нет её.
> Ещё раз - нет стабильного софта, есть отказоустойчивость, через которую и обеспечиваются девятки в SLA.Ещё раз -- стабильный софт есть, и от нестабильного он отличается частотой сбоев.
Обеспечивать отказоустойчивость для стабильного софта легче и дешевле, нежели для нестабильного.
Сбои -- требуют реакции инженеров, даже если не приводят к отказам. Оплата их труда учитывается в TCO.
Поскольку люди стоят дороже железа, смысл выбирать более стабильный софт смысл очень даже бывает.> И redis никогда не был устойчивым и масштабируется он только горизонтально, причём посредственно, со значительным оверхедом.
Смотря на каких нагрузках. На 50k qps он работает отлично.
> А хорошо масштабируется например garnet, относительно новый софт, но в разы и даже на порядки превосходящий redis.
Да, garnet хорош. Мы сами его в тестовом режиме на одном из проектов гоняем. Полёт нормальный.
> И ключевой момент в том, чтобы не загнать молодых своими посылами в "стабильность", пусть изначально знают, что нет её.
Странно говорить об отсутствии стабильности, ориентируясь только на граничные условия эксплуатации софта. Что redis, что garnet -- оба достаточно стабильные продукты.
Неа, нет стабильного софта.
Есть надёжный софт, отлаженный, устойчивый. А стабильного софта не существует.
Redis обладает какой-то устойчивостью при достаточно низких нагрузках, но при росте нагрузок сходу слетает по доступности и не обеспечивает никакой надёжности.
И garnet тоже не был устойчивым, тоже падал пока не отладили.
Про ФОТ я уже говорил. И сравнивая подобные друг-другу системы, можно просто сократить ФОТ, т.к. он будет в среднем одинаков.
И обеспечивать отказоустойчивость, что для надёжного софта, что для не надёжного - следует одинаково - разумнее сразу вынести за скобки надёжность софта."Стабильный" применительно к ПО - это скорее обиходный ярлых, чем инженерный термин.
> Неа, нет стабильного софта.
> Есть надёжный софт, отлаженный, устойчивый. А стабильного софта не существует.Более глупой полемики трудно представить с учётом того, что "стабильный" -- это по определению "отлаженный, устойчивый".
Настоятельно рекомендую уточнить для себя этот момент.
Проясните лучше для себя, что такое стабильность в математике и физике на которых основана вычислительная техника и софт. В обиходе "стабильный" - укоренившийся сленг, применяемый к тому что на поверку не является стабильным. В профессиональном же смысле к стабильным могут быть отнесены программы с формальной верификацией, да и те только в случае полноты и безошибочности спецификации и полного покрытия кода. И такого софта капля в море, CakeML редчайший экземпляр.
Так что нет никакой стабильности.
> В обиходе "стабильный" - укоренившийся сленг, применяемый к тому что на поверку не является стабильным.Ну-ну )
Интересный проект, но пока что хорош только для локалхоста:> 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 поддерживает, и латенси (что дико бесит в редисе, кстати) на уровне.
Автор pogocache - известный в узких кругах профессионал. Я уверен, что у него опыта хватит для допиливания любого функционала.А чтобы интерес не погас, он организовал фирму по продаже pogocache.
Ну и, кстати, у pogocache не такая уж и свободная лицензия.
Судя по описанию проделанных автором бенчмарков - ему надо ещё поковырять на предмет вертикального масштабирования. Garnet намного производительнее, чем в его бенчах. Например на железках в 256 ядер.