С того места, где я остановился…

Я не из тех, кто сильно привязывается к своим собственным проектам. Когда я решил уйти из Redis, это было примерно 1620 дней назад (около 4,44 года), я напрочь перестал заглядывать в исходный код, смотреть коммиты или вообще что-то читать о Redis. Время от времени, когда мне требовался Redis, я просто скачивал его и компилил. Я просто набирал make и радовался, что даже спустя все эти годы сборка по-прежнему элементарна.

Моё решение отдалиться от проекта не было связано с тем, что я возненавидел свою прежнюю работу. Со временем творческие задачи стали всё менее важны, а всё больше — «обслуживания проекта». Многие разработчики могут без проблем перейти к такой работе, но это явно не моё призвание. При этом на самом деле мне всё ещё нравилось заниматься Redis, когда я уходил. Просто у меня нет той же убеждённости, что у многих моих ровесников (сейчас мне 47), которые считают себя «всё ещё молодыми». Я хотел заняться чем-то совершенно новым, в частности писательством. Хотел проводить больше времени с семьёй и помогать близким. Мне действительно требовалась пауза.

Но даже в «годы писательства» (к слову, я до сих пор пишу) я постоянно возвращался к программированию, чтобы отвлечься от ментальной нагрузки, которую даёт писательский труд (из всех интеллектуальных занятий, которые я пробовал, писательство оказалось самым изматывающим — даже в сравнении с кодингом). За это время я сделал несколько проектов для встраиваемых систем, игрался с нейронными сетями, писал ботов для Telegram — в общем всего по-немногу. Рандомный хакинг - это весело, но в какой-то момент я стал чувствовать, что мне не хватает настоящего смысла, и с каждым днём желание вернуться в мир технологий росло. Заодно мне было тревожно наблюдать со стороны, как сообщество Redis начинает расползаться, дробиться.

Так мне в голову пришла мысль, что, возможно, у меня действительно может быть новая роль в экосистеме Redis. Я мог бы заняться тем, чтобы перенастроить отношения компании с сообществом. Может, я даже смогу помочь вернуть внимание к ядру Redis как к ключевому фокусу для новых разработок. По сути, я мог бы стать кем-то вроде «евангелиста» (не очень люблю это слово, но вы понимаете идею) — то есть быть мостом между компанией и сообществом, а параллельно делать демо-проекты, придумывать и описывать новые паттерны, писать документацию, снимать видео и писать посты о разных полезных штуках. А что насчет дизайных новых фич? Я мог бы учиться у людей «в полях», которые рассказывают о своих сложностях, и потом возвращать эти идеи команде, чтобы помочь развивать Redis.

Время, проведённое в Нью-Йорке

В какой-то момент моя дочка, которой сейчас 12 и которая — невероятно важный человек в моей жизни (она каждый день удивляет меня умом, креативом и любовью), захотела на день рождения слетать в Нью-Йорк. Мы решили, что это хорошая мысль: последние годы у нас выдались весьма тяжёлыми, так что почему бы и нет!? Тем более дочь уже почти не ребёнок, а подросток.

И вот мы в Нью-Йорке, и я думаю: «Может, настало время? Я могу поработать хотя бы на парт-тайм». Я недавно познакомился с новым CEO Redis, Роуэном Тролоупом, по видеосвязи — и мне показалось, что я могу вместе с ним всерьёз заняться отношениями компании с сообществом и работать над кодовой базой в целом. Тогда я написал ему письмо, мол: «Слушай, может, мне стоит в какой-то мере вернуться Redis?» Роуэн отнёсся к этой идее с энтузиазмом, и мы довольно быстро нашли общий язык.

Про смену лицензии

Разумеется, люди будут задаваться вопросом, что на самом деле за этим стоит, не было ли каких-то подковёрных историй, соглашений, громадных сумм денег — чего-нибудь в этом роде. Но иногда всё куда скучнее и проще:

1. Я сам написал компании, а не наоборот.

2. Мне не предложили никаких бешеных гонораров; всё вполне стандартно (и да, у меня есть опцион на акции, как и раньше, но без каких-то особых условий).

3. У меня нет глобальных претензий к тому, что Redis сменила лицензию. Если честно, я не думаю, что именно из-за этого возникла трещина в сообществе. Но поскольку тема важная, лучше сразу об этом поговорить.

Лицензионная дилемма

Я пишу опенсорс фактически всю свою жизнь. Хоть я и атеист, но при этом вполне рад за людей верующих в Бога, если это помогает им пережить жизненные трудности. Так и в вопросе программирования я не верю, что опенсорс единственный возможный способ написания кода. Когда я начинал писать Redis в рамках компании, которую мы основали вдвоём, исходный код мы держали закрытым (Redis, собственно, и открыли потому, что считали его лишь частью основного продукта). Мы просто не хотели, чтобы наш сервис кто-то копировал. Вот и всё. То есть я не радикал в вопросе лицензий — только в вопросе дизайна софта.

К тому же я не уверен, что «открытость» и «лицензия» строго привязаны к тому, что одобряет OSI. Я вижу их как некий спектр возможностей и ограничений. При этом меня правда беспокоит, что крупные облачные провайдеры меняют баланс сил в мире системного ПО. Redis ведь не единственный проект, который поменял лицензию; на деле он был одним из последних... среди многих. И у меня есть подозрение, что за последние годы в принципе не появился целый ряд новых проектов, потому что разработчики не видели для себя разумной бизнес-модели. Так что перевод Redis на новую лицензию был не моим решением. Выбрал бы я другую лицензию, окажись я там? Не уверен — задним числом слишком легко это обсуждать, не будучи под влиянием бизнеса. В целом же, я понимаю, почему приняли именно такое решение.

Если смотреть на новую лицензию, то, да, это уже не BSD, но по сути, если вы не торгуете Redis как сервисом, то можно использовать всё почти так же свободно, как раньше (можно модифицировать, распространять, применять в коммерческих целях, хоть в вашей собственной компании — и всё это бесплатно). Более того, вы всё ещё можете продавать Redis как сервис, если готовы открыть сопутствующий код оркестрации по тем же условиям (на что, вероятно, никто не пойдёт, но это отражает «копилефтную» природу лицензии). Язык лицензии в целом следует AGPL кроме того, что касается SAAS. Так что да, новая лицензия не одобрена OSI, но и назвать её закрытой у меня язык не поворачивается.

Вы можете возразить (и я это буквально слышу): «А как же тот факт, что за многими проектами стоят компании, которые, по сути, и направляют их будущее? В итоге интересы всё равно сдвигаются не в сторону пользователей, а в сторону компаний». Я рад, что есть проекты, у которых вообще нет прямой бизнес-привязки (кроме спонсоров). Но знаете что? Во многих крупных проектах присутствие компании, как ни странно, способно замедлить смещение фокуса и позволить остаться на верном пути. Так было и с Redis.

Робин Гуд в мире софта

Вернёмся мысленно к первым дням Redis.

Когда Redis начала набирать популярность, я раздумывал, как продолжать над ней работать. Это было ещё до того, как VMware предложила мне спонсорство. Тогда я думал запустить какой-то бизнес, связанный с Redis. И угадайте, что? Да, это должна была быть закрытая модель с некими дополнительными продуктами для работы с Redis. (Что интересно, один старый репозиторий с попытками что-то подобное сделать до сих пор доступен — antirez/redis-tools с коммитами пятнадцатилетней давности!)

Я всерьёз присматривался к подходу «open core». Помню, у меня была мысль выкладывать новый код под BSD, но с отсрочкой в шесть месяцев, чтобы у платящих пользователей было преимущество. Сейчас не думаю, что я стал бы делать пакости сообществу, но вряд ли я смог бы стать «Робином Гудом опенсорса», каким я оказался, когда VMware, а затем и Redis Labs, стали выделять мне зарплату не за то, чтобы я работал строго в их интересах, а за то, чтобы я мог делать что-то по-настоящему ценное для всех пользователей Redis. Это куда лучше, чем вести свой бизнес — я абсолютно уверен в этом.

К тому же спонсировали они не только меня. Если поглядите на вклад в репозиторий, вы увидите, что второй по числу коммитов человек — Оран Агра (Oran Agra, Redis), третий — Питер Нордхёйс (Pieter Noordhuis, VMware) и так далее.

В итоге мы имеем 12 лет открытой разработки под лицензией BSD, где приоритетом было исключительно удобство и выгода для пользователей Redis. Это ли не повод для гордости? А вот сейчас, на мой взгляд, главный момент в том, что «раскол» с сообществом объясняется не только лицензией, или, точнее, не столь лицензией. На самом деле новая лицензия может кое-что и улучшить: теперь нет стимула забросить ядро в «режим поддержки» и уводить все инновации в закрытые модули. С SSPL облачные гиганты не смогут просто взять код Redis, чуть адаптировать его и продавать, ничего не отдавая взамен. (Разве это слишком наглая идея — попросить делиться доходом с командой, которая написала большую часть этого кода? Возможно, тогда лицензии не пришлось бы менять ни Redis, ни куче других проектов.) По сути, теперь внимание снова может быть сосредоточено на ядре Redis, позволяя всем разработчикам получать крутые новые фичи. И десятки людей будут получать зарплату, чтобы писать полезные, хорошо задокументированные изменения прямо в основной репозиторий на GitHub. Это именно то, в чём я могу помочь компании, и я настроен приложить все силы, чтобы это действительно пошло на пользу и пользователям, и продукту. Вот в чем моя идея!

Немного про AI, LLM и векторные индексы

Но есть ещё кое-что важное: Redis начала активно смотреть в сторону векторных возможностей и, шире, поддержку сценариев, связанных с ИИ. Сейчас я каждый день захожу на Hacker News, и вижу, сколько там людей, которым вся эта история с искусственным интеллектом и современными моделями кажется чем-то сомнительным. А уж тех, кто толком и не попробовал актуальные большие языковые модели (подсказка: Claude AI определенно лучший выбор) и сразу отмахивается — полно. У меня же всё с точностью до наоборот. Мне всегда нравились нейронные сети. Ещё в 2003 году я написал свою первую библиотеку для них и был абсолютно поражён, насколько это мощная идея. А сейчас, в конце 2024-го, я вижу вещи, которые ещё совсем недавно казались фантастикой. Claude AI для меня — это и собеседник для осмысления идей, и редактор, и партнёр по кодингу. Я стал работать быстрее и масштабнее, чем когда-либо.

Иногда я работаю больше благодаря ИИ, но делаю это намного эффективнее. Вот совсем недавно я писал научно-фантастический рассказ для одного итальянского издательства, и Claude помог мне взглядом «со стороны» — я переписал концовку, и текст стал ощутимо сильнее (при этом я не разрешил ИИ написать даже строчки: грамотно использовать ИИ — это не переложить на него работу, которую вы можете сделать лучше).

Вчера у меня возникла задача: понять, на сколько ускорится вычисление скалярного произведения при 8-битной квантизации векторов. Я сказал Claude, какой именно бенчмарк мне нужен, и буквально через пару минут у меня уже был тест, который я мог крутить, дорабатывать и сразу же понимать получилось ли что-то стоящее или нет. То есть ИИ не заменил меня, а ускорил и улучшил, давая быстрый фидбэк. И, полагаю, что (невзирая на всю шумиху вокруг RAG — retrieval augmented generation, которая, может, и не станет самой важной «убийственной фичей», особенно по мере увеличения контекстов у моделей), простите за лирическое отступление, — я действительно уверен, что эмбеддинги с нами надолго и что поиск по векторным представлениям идеально сочетается с Redis. Во-первых, потому что векторные структуры данных сами по себе тяжёлые для вычислений, и им полезно жить в памяти. Во-вторых, мне кажется, что я нашёл классный вариант API, чтобы это реализовать в духе Redis.

Во время разработки Redis у меня всегда была парочка противоречивых склонностей. С одной стороны, я регулярно говорил «нет» вещам, которые казались очевидно подходящими для проекта (как, например, именованные скрипты на Lua или срок жизни для полей внутри хэшей — забавно, но эти штуки в итоге оказались в Redis), а с другой — я брал и добавлял Lua-скрипты (да, интерпретатор внутри Redis?!), Pub/Sub, а потом Streams и даже нестандартные структуры данных вроде sorted sets, которых вы не найдёте классических книжках по CS. Просто для меня было важно, чтобы новая фича приносила практическую пользую и органично вписывалась в общий дизайн Redis. Я всегда относился к Redis как к конструктору Lego для программистов, а не «продукту» в традиционном смысле.

Векторные наборы

Недавно я подумал: а что, если взять вдохновение в sorted sets, но вместо одномерного score иметь вектор? Пока я обсуждал возможное возвращение, стал готовить дизайн-док, потом накодил proof-of-concept с HNSW (Hierarchical Navigable Small World), переписав эту штуку с нуля в «редисовском стиле» (не взяв чужую библиотеку, потому что мне хотелось контролировать каждый нюанс). На данный момент это отдельный модуль (так проще экспериментировать), но потенциально он может войти в ядро. Там есть новые команды для работы непосредственно с эмбеддингами. Пример:

VSIM top_1000_movies_imdb ELE "The Matrix" WITHSCORES
"The Matrix"
"0.9999999403953552"
"Ex Machina"
"0.8680362105369568"
"Akira"
"0.8635441958904266"
"District 9"
"0.8631418347358704"
"The Martian"
"0.8608670234680176"
"The Bourne Ultimatum"
"0.8599717319011688"
"The Bourne Supremacy"
"0.8591427505016327"
"Blade Runner"
"0.8585404753684998"
"Metropolis"
"0.8572960793972015"
"Inception"
"0.8521313071250916"

В итоге имеем очевидный набор команд из VSIM, VADD, VCARD. Получается что-то вроде sorted set, но со многомерным «весом» (ембеддинг!), и с поиском через KNN (поиск ближайших соседей). Звучит любопытно, да? Конечно, внутри куча трюков оптимизации. Сейчас это лишь набросок, я ещё внедряю потоки, уменьшение размерности, квантизацию и прочее — на самом деле делать это очень весело.

Как видите, здесь нет упоминания о гибридном поиске, новом модном слове, связанном с векторными хранилищами. Опять же, это путь Redis: дать разработчику возможность выбирать и находить компромиссы, ведь они знают, что именно моделируют. У вас есть векторный индекс на каждый ключ, и, как разработчики смогли сделать с sorted sets, они изобретут интересные стратегии разделения, новые схемы, Lua-скрипты, паттерны и всё необходимое для моделирования своих сценариев использования.

Тем не менее, хотя обычно связанный элемент будет скорее маленькой строкой или ID документа, ничто не мешает ему быть чем-то более сложным, с метаданными, которые можно будет отфильтровать позже (но я буду сопротивляться). У меня просто есть ощущение, что многие случаи использования действительно не нуждаются в сложной серверной фильтрации и могут быть смоделированы путем предварительного разделения данных.

С большим интересом я наблюдаю за добавлением потенциальной опции STORE, чтобы сохранять результат в sorted set вместо возврата пользователю, где оценка — это, конечно, сходство. Всё это также имеет сложные и интересные эффекты на эффективность, масштабируемость, возможность использования скриптов и так далее: надеюсь, у меня будет возможность поговорить об этом подробнее в ближайшие недели и месяцы.

Ладно, ладно: возвращаемся к сути этого блога. Но, возможно, вышеизложенное — это настоящая суть, новые идеи, которые могут быть захватывающими.

Итак, я вернулся ?

Все это для того, чтобы просто сказать — я вернулся. И хочу поблагодарить сообщество Redis за всё, что оно сделало за эти годы. Увидимся, надеюсь, что нам действительно ещё будет, чем дополнить эту историю.

P.S. Я сейчас активен в BlueSky, так что, если хотите следить за развитием событий: https://bsky.app/profile/antirez.bsky.social

От переводчика

В общем будем ждать возвращения Redis к "нормальности". Но как будто адекватный вектор развития уже взят:

• в v7.4, наконец-то, добавили TTL на уровне ключей в HashMap (что давно напрашивалось);

• а в v8 собираются затащить поддержку JSON, вторичных индексов и других классных штук из Redis Stack. А еще над перфомансом начали работать!

Будем наблюдать ?

P.S. Веду канал Alex Code в телеграме про разработку и не только ;-)