я могу конечно ошибаться, но насколько я понял, обычный редис этого не умеет

мне бы вообще любая бд подошла, в том числе и простая key value, не обязательно структуры редиса иметь. лишь бы была эта опция - пользовать память по-максимуму, которую я разрешил и пользовать по-максимуму диск, который я разрешил + желательно automatical eviction на диске (если переполнится)

ну и конечно желательно чтобы был биндинг для луа, так что если кто что подскажет - буду благодарен

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

я тут почитал, оказывается этот энтерпрайз редис использует рокс дб для хранения данных на ссд. в теории можно самостоятельно сделать такой же механизм. только как оценить горячие и холодные ключи? придется самостоятельно статистику писать.

Все можно самому запилить. Это же не инопланетянами писалось (скорее даже и не писалось, а настраивалось). Напоминает как эластик продаёт связку эластик+логстеш как сервис. При том что само по себе это все бесплатное и несложно настраивается. И сделать у себя можно вообще что душа пожелает, а в "облачном" решении - как дядя за тебя сделал.

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

именно облачные решение я вообще не рассматриваю, на них неадекватные цены

а так да, взяли стандартную rocksdb + допилили механизм определения холодных горячих ключей

я нашел кое что у них на этот счет, есть команда object и там есть доп команда FREQ и IDLETIME - вот это можно использовать

но в этом случае придется включить опцию LFU для FREQ или (LRU или noeviction) для IDLETIME и макс мемори

либо считать это самому, но это на каждое чтение будет одна запись.

в принципе можно взять связку ssdb + redis, но как этот механизм хоткейс реализовать вопрос

ну и конечно луа в этой связке будет тоже. читаем ключ в редисе. если нет, читаем в ссдб, если там нет - создаем.

собственно вопрос в том, как это эффективно делать

как вариант можно позволить редису эвакуировать данные по LFU, а самому все переменные дублировать на ссд. тогда как раз, в этом случае часть переменных на ссд будет излишней, но будут недостающие.

хотя такой вариант подойдет только для простого key value, для сложных структур не подойдет

кстати, я тут на днях спрашивал по поводу бд - вот нашел идеальный вариант, но непонятна цена, скорее всего она будет неадекватной

А почему никто tarantool не предлагает?

я его не пробовал, он может эту задачу исполнять, что я написал?

есть ли возможность использовать его из луа?

есть ли возможность использовать его из луа?

tarantool/vynil умеет: https://www.tarantool.io/en/doc/2.1/book/box/engines/ https://habr.com/ru/company/mailru/blog/358210/ в tarantool всё на lua https://www.tarantool.io/en/doc/2.1/book/app_server/cookbook/

спасибо, я почитаю

tarantol 100% in-memory db?

tarantol 100% in-memory db?

есть движок винил есть мемтх движки

ага, понял, вот как раз про него статью читаю эту

https://www.tarantool.io/en/doc/2.1/book/box/engines/#differences-between-memtx-and-vinyl-storage-engines

тут про различия

понял, спасибо, похоже это то, что мне нужно

буду пробовать

@basilsemuonov ты лучше расскажи вот что. умеет ли vshard select * обработать?

тяжело конечно привыкнуть к тарантолу после редиса

тяжело конечно привыкнуть к тарантолу после редиса

а что именно?

напиши свои get\set на lua

секунду, сейчас покажу примеры

ну вот например я использовал битмап для хранения фиксированного количества чисел по ключу

local lua_script = [[ local clicks_key = KEYS[1] local tag_id = KEYS[2] local thumbs_key = KEYS[3] local thumbs_bytes = KEYS[4] local thumbs_amount = KEYS[5] local result = {} local total_clicks = redis.call("HGET", clicks_key, tag_id) table.insert(result, total_clicks) local thumbs = {} local i for i=0, thumbs_amount do local res = redis.call("BITFIELD", thumbs_key, "GET", thumbs_bytes, "#" .. i) local thumb = {} table.insert(thumb, i) table.insert(thumb, res[1]) table.insert(thumbs, thumb) end table.insert(result, thumbs) return result ]] return red:eval(lua_script, 5, clicks_key, tag_id, thumbs_key, thumbs_bytes, thumbs_amount)

вообще ранее я обходился без bitfield, я к ним пришел т.к. они экономнее место используют

по сути мне нужен hash set sorted set и обычный string

если рассматривать спейс как таблицу, то индекс это как столбец? я правильно понял?

если рассматривать спейс как таблицу, то индекс это как столбец? я правильно понял?

это все тот же key val, но с возможностью строить индексы автоматически.

@basilsemuonov ты лучше расскажи вот что. умеет ли vshard select * обработать?

а почему не должен уметь? выполнить в каждом сегменте запрос всех данных

мало ли. 3000 бродкаст-запросов. склейка ответов

дорого

мало ли. 3000 бродкаст-запросов. склейка ответов

ну, я не специалист по tarantool, наверное в @tarantoolru / @tarantool ответят точно и посуществу

ну я уже раскопал. можно но дорого-больно. придумал объодной маневр

А тут у нас бот, который выжидает сутки чтобы его не отстрелил daysandbox

Фейк, который через сутки запостит какую-нибудь дичь.

@arkashakakasha здесь, намечается какой-то стартап кэмп 😱

Надо поставить себе успешный аватар

Всё, я человек который зарабатывает деньги сам, и не работает на дядю.

Молодец

Тэкс, шутка-минутка, какой логический ответ на вопрос to be or not to be? С луями ответ даже интуитивнее чем со всякими сями.

true

)

Малацом

тут это ... 7 докладов выложили, ежели кому интересно🙄 https://www.youtube.com/channel/UCjFmUGYGlh7o9T6_VHsyIsA/videos

👍

https://semver.org/lang/ru/ Может кому нибудь будет интересно про эльфийскую магию с цифрами в версиях приложения, например: MySuperApp ver: 2.7.13-rc

Ну, обычно хватает версий вида X.Y, где X — версия текущего апи, несовместимая с предыдущими, а Y - патчи. 11.2, например. Ну и "единица" в мажорке как релиз.

А то слишком запутанно, особенно при консультациях по телефону: — А какая у вас версия приложения? — Одиннадцать точка двести восемьдесят шесть точка четыреста двенадцать дефис эр как я наоборот, ц как русская эс. — У вас устаревшая, обновляйтесь до одиннадцатой точка двести восемьдесят шестой точка четыреста тринадцатой дефис эр как я наоборот, ц как русская эс. Конечному юзеру совершенно необязательно в этом разбираться, и чем проще его жизнь тем лучше. P.S. А некоторые вообще обзывают версию текущим коммитом гита, вот страшные люди.

А то слишком запутанно, особенно при консультациях по телефону: — А какая у вас версия приложения? — Одиннадцать точка двести восемьдесят шесть точка четыреста двенадцать дефис эр как я наоборот, ц как русская эс. — У вас устаревшая, обновляйтесь до одиннадцатой точка двести восемьдесят шестой точка четыреста тринадцатой дефис эр как я наоборот, ц как русская эс. Конечному юзеру совершенно необязательно в этом разбираться, и чем проще его жизнь тем лучше. P.S. А некоторые вообще обзывают версию текущим коммитом гита, вот страшные люди.

1891ВМ8Я

Маркировка эльбруса

Ещё и кириллицей, мда.

Зато православные скрепы

Зато православные скрепы

Правильно говорить "скрипты"

Православная крипта

Православная крипта

С мощами?

С мощами?

Блджад. Ты следишь за мной ?

Блджад. Ты следишь за мной ?

Бггг ))) нет ))

тут это ... 7 докладов выложили, ежели кому интересно🙄 https://www.youtube.com/channel/UCjFmUGYGlh7o9T6_VHsyIsA/videos

интересно, посмотрим

А то слишком запутанно, особенно при консультациях по телефону: — А какая у вас версия приложения? — Одиннадцать точка двести восемьдесят шесть точка четыреста двенадцать дефис эр как я наоборот, ц как русская эс. — У вас устаревшая, обновляйтесь до одиннадцатой точка двести восемьдесят шестой точка четыреста тринадцатой дефис эр как я наоборот, ц как русская эс. Конечному юзеру совершенно необязательно в этом разбираться, и чем проще его жизнь тем лучше. P.S. А некоторые вообще обзывают версию текущим коммитом гита, вот страшные люди.

Как я понял -rc это релиз кандидат и пользователям эта версия не может быть доступна, а вот уже релиз пользователям доступен и версия должна состоять строго из цифр ))) по-моему это можно увидеть на примере дровишек nvidia, но могу ошибаться В итоге после статьи я так и не смог четко определить для себя что именно подразумевается под api, если например у меня в проекте нет api, но это уже тонкости и частные случаи

Если у тебя нет апи, то мажорные релизы это сборки фич текущей итерации.

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

Можно ещё версии (релизные) на даты завязывать. Типа 2019.04 апрельский релиз. А патчи багов просто не именовать и накатывать автоматом.

Не, баги надо отличать друг от друга. Иначе хз.

Можно ещё версии (релизные) на даты завязывать. Типа 2019.04 апрельский релиз. А патчи багов просто не именовать и накатывать автоматом.

Не, там в статье по правилам необходимо обнулять цифры справа при каждом релизе мажорной или минорной типа у тебя не может быть вот таких версий: 1.2.12 а за ней сразу 1.3.1, там обязательно нужно обнулять цифры справа и версия будет 1.3.0, так что даты можно использоваться но они не укладываются в рамки документа, там даты используются для указания билдов одной и той же версии, которые отличаются например окружением или набором софта, но не затрагивают функционал и патчами эти изменения не назвать

Не, там в статье по правилам необходимо обнулять цифры справа при каждом релизе мажорной или минорной типа у тебя не может быть вот таких версий: 1.2.12 а за ней сразу 1.3.1, там обязательно нужно обнулять цифры справа и версия будет 1.3.0, так что даты можно использоваться но они не укладываются в рамки документа, там даты используются для указания билдов одной и той же версии, которые отличаются например окружением или набором софта, но не затрагивают функционал и патчами эти изменения не назвать

Ну я не про статью, а про вообще. Для потребителя такое версионирование может быть понятнее

Ну я не про статью, а про вообще. Для потребителя такое версионирование может быть понятнее

Да, я встречал такой подход когда работал в компании dengionline.com , там было как раз 2010.1.1.build_number, через пол года косячных релизов и отсутствие понимания какой именно build_number содержит то что нужно (а это факапы на миллионы рублей по платежам пользователей) решили все таки воспользоваться семантическим версионированием, после этого наши релизы происходили с меньшим количеством факапов, но все равно не идеально, какой инструмент не выберешь если не умеешь им пользоваться то инструмент навряд ли сможет помочь каким бы хорошим он ни был. Например путались с тем какое число увеличивать на 1 при одинаковых значениях дня и месяца, кто то привык к одному написанию, кто то к другому и был бардак

Чот много народа, боты или кто-то ссылку запостил? Подайте голос если не боты (но только не рекламный голос, пожалуйста)