Опубликован релиз СУБД Redis 7.0, относящейся к классу NoSQL-систем. Redis предоставляет функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества, а также возможностью выполнения на стороне сервера скриптов-обработчиков на языке Lua. Код проекта поставляется под лицензией BSD. Дополнительные модули, в которых предлагаются расширенные возможности для корпоративных пользователей, такие как RediSearch, RedisGraph, RedisJSON, RedisML, RedisBloom, с 2019 года поставляются под проприетарной лицензией RSAL. Развитие открытых вариантов данных модулей под лицензией AGPLv3 пытался продолжить проект GoodFORM, который последнее время находится в стагнации...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57100
Как БД и мемкэшд соотносятся? Сравнили зелёное и длинное.
Так редиска же часто как кэш используется. Вполне валидное сравнение.
Ну Redis в своё время был предложен как замена memcached с поддержкой сброса кэша на диск, а уже потом превратился в комбайн.
Ну обозвать redis СУБД - это чья та больная фантазия. Сами они себя называют "in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker".
т.е. именно "системой хранения данных в памяти".
Так он не только в памяти хранит так всё нормально.
> Ну обозвать redis СУБД - это чья та больная фантазия.Ну, Berkeley DB именуется СУБД вполне официально. Так что можно быть локальным KV и всё равно считаться СУБД.
Или, может, дело в том, что за ними Оракл, а любой продукт оракла автоматически считается СУБД?
На самом деле удобная вещь. Записал значение как в key-value бд, выставил ему время жизни, всё ты в шоколаде. Как ещё использовать я не представляю, только как кэш.
Ну - например у нас редиска используется как "общая память" для обмена информацией между процессами АСУТП.
Как вариант. Я использую, чтобы не создавать лишнюю нагрузку от пользователей дорогими запросами там, где общие данные и им совсем не требуется актуальность. Но и сервис не то чтобы нагруженный, просто зачем тратить секунды там где нет никакого смысла их тратить. Несколько видов кеширования, это один из них. Возможно, стоит рассмотреть возможность применения для IPC, но у меня нет IPC на данный момент. Раньше Redis никогда не использовал, а тут решил пощупать что-то.
Редис бывает и просто технических кешем например для того же celery. Т.е. не для пользователей, а для сервисов ака месседж брокер
"Кэш для пользователей" - это скорее varnish/nginx/haproxy.
С тем, что в редисе хранится, в любом случае взаимодействует код, а не пользователь.
У него еще куча полезных фич, кроме key/value стораджа.
Например:
- pub/sub
- shared lock
А вот так. И то и другое на кейвалуях. Redis - это по сути отказоустойчивый Memcached, плюс-минус.
>>зелёное и длинное...Огурец что ли..?
крокодил :)
Многопоточность так и не прикрутили?
В 4 прикрутили, в 6 докрутили
Потому что она всё так же ненужна.
Зачем?
Иногда запросов так много, что одно ядро не справляется. А ядер в сервере обычно много и у них не особо высокая частота. Можно конечно устроить закат солнца вручную, но удобнее когда оно из коробки есть
Давно уже.
https://keydb.dev/ - форк редиса с многопоточностью. Кодовая база регулярно синхронизируется с апстримом.
> Давно уже.
> https://keydb.dev/Его нету под FreeBSD, фтопку.
Я только знаю, что 6.2.6 работал с luajit-2.0.5 (2.1.0 выдаёт ошибки), и в 6.2.7 зависимость от lua-5.1 который жуткое старьё и легаси. Ничего не вижу про это в новости.
Это кстати же камень в огород всем небезопасных jit версий любых языков и их вариаций. И тут поняли что jit в общем и целом ненужен.
Ребята, а реально запилить сайт который будет использовать только редиску, без любого SQL?
Без проблем. В целом можно даже на диск скидывать сторадж, но будет медленнее.
> Ребята, а реально запилить сайт который будет использовать только редиску, без любого SQL?Разработчики из одного известного жёлтого "дофига хай-тек" банка ухитрились даже на нём видеохостинг сделать, для внутренних нужд. Причём на одном инстансе, без шардирования и сохранения (была репликация, но отвалилась по дороге).
Были очень удивлены, когда место стало заканчиваться.
Прям туда где value писали видео?
По-моему, в value писали JSON, в одном из полей которого был base64-кодированный видеофайл.
современные ойтишнеги очень любят стрелять себе в ноги
Специфика корпоративной культуры разработки. По-моему, такая культура формируется во всех более-менее крупных корпорациях - менеджеры получают премии за количество новых проектов, а не за их работоспособность, а разработчики набираются из бывших курьеров и таксистов, которым не хватило интеллекта для навигации по городу.
А в чём проблема-то? Мы на Редисе делали хранение стриминговых видеофайлов в одном из крупных видеомессенджеров, весьма успешно. Гораздо лучше, чем использование для хранения видеофайлов CEPH, например.
А кто нить работает в хайлоаде? На чем крутятся какие-нибудь комменты в ВК и других соцсетях?
На кластере серверов.
В ВК хз у нас все крутится в мемкеше работает быстро есть не просит.
в мемкеше данные коментов? а тип если кластер умрет - их не жалко?
Заново греть кеши? При запросе все данные в том числе предиктовые запрашиваются из БД и попадают мемкеш и от туда запрашиваются пользователем. Как их перестают запрашивать данные удаляются.Ты спросишь про валидацию кешей вот там велосипед на велосипеде. Ака консистеностность в конечном счете.
"В программировании есть две реально сложных проблемы - именование сущностей и валидация кэшей. Все остальное - простые проблемы" © не помню кто
Джефф Этвуд, один из основателей Stack Overflow
А чем плохи Hazel Cache и Ignite Cache?https://stackoverflow.com/questions/31932836/hazelcast-vs-ig...
Они же сами все автоматически синхронизируют на всех узлах или нет?
А кто сказал, что они обязательно плохи?
Просто они гораздо сильнее интегрируются в логику приложения, и хорошо заходят, если у вас энтерпрайз Java и SpringEverything (по крайней мере, Hazelcast)
> А чем плохи Hazel Cache и Ignite Cache?GridGain еще есть, пока на практике не попробуешь, не поймешь
Имена сущностей и ИНВАЛИДАЦИЯ
кешей.Вот и выросло поколение, которое не умеет в классиков.
Автор данной фразы, как и её каноническое написание, вообще не очень точно известны. Её приписывают Тиму, но по его же словам, он её сам слышал от кого-то.
сейчас появились оч быстрые железки по диску, и ... можно на небольшом кол-ве железа процессить оч большие объемы.
понятное дело, что в вк там кластер, потому что ну очень много + отказоустойяиво нужно.
но этт нк рокет сайнс. ну нагрузки много, но она примитивная. шардированный доступ в зубы, и вперед. тут больше архитектурное решение решает.
а так: мускул, каучбэйз, аероспайк, кассандра.
хотя кауч и аероспайк в рф вероятно уже не продаются, так что если про вк говорим - наверное без них )
> а так: мускул, каучбэйз, аероспайк, кассандра.Если про couchbase и aerospike ещё плюс-минус попадание, то кеши в кускуле или кассандре - это прямо первоапрельская шутка (причём не очень умная).
вопрос был как сделаны коменты? или где кеш лежит?
вроде как про комменты
про шутки - почитай для чего фб вообще делал кассандру изначально
мускл - ну ты попробуй положить в него кей-валуе данные, дать ему 256 гиг памяти под кеш, пачку pcie ssd, и несколько зионов платинум проца. скажешь потом, где проблема, и где оно хуже кауча.
> ну ты попробуй положить в него кей-валуе данные, дать ему 256 гиг памяти под кеш, пачку pcie ssd, и несколько зионов платинум процаЛучше всё-таки 1 Тб оперативки, а то вдруг данных много окажется, гигабайт, например.
И в итоге получится что-то, способное догнать по скорости Redis на Pentium 4.
Вот когда ты напишешь тест хоть один по сравнению скорости кеша в памяти с кешем на диске, да посчитаешь сколько бабла тебе потребуется для уравнивания их скоростей -- вот тогда и приходи комменты писать.
о как! т.е. кеш рсубд, живет на диске?
расскажу по секрету - нет ) он живет в памяти, внезапно, как и данные редиса. и в мускле, и пг и оракле.
и прогрев кеша нужен и в редисе (хм, данные на диске, если рестарт, то нужно сильно думать).
а внезапно аероспайк и придумывали, чтобы хранить данные на диске, не парясь на инмемори и не парится, если их ну оч много.
> о как! т.е. кеш рсубд, живет на диске?Ну давай, расскажи мне, как поднять постгрес без диска, вперде))
И как гарантировать, что те данные что должны быть в памяти не будут вытеснены на диск в Постгресе/Оракле/что там у тебя ещё есть. И как данные шарить между нодами, которые поднимаются и ложатся по требованию.
балин... ну о чем спорить? в память положил, из памяти взял. но тогда вычитка с диска, и инвалидация - ручками. хочешь, чтобы это работало само - база данных, с кучей кеша данных и/или ключей. все упирается в объем данных, время и желание делать велосипеды.
зашардировать данные в редисе - фокус. проверять схему - фокус. реплицировать при высокой летенси сети (xdc) и высокой нагрузке - фокус.
юзать как локальный кеш сервиса - отлично работает.
ну как-то так...
Благодарю за ответы. Но интересно, если в РСУБД все как-то атомарно связано транзакциями, констрейтами, в общем, конторолем на уровне СУБД, то как здесь решается проблема синхронизация первичных и прочих агрегированных данных, статистики и прочих витрин? Получается, с помощью бизнес-логики приложения или сервисов?
Такое ощущение, что вы просто накопипастили случайные фразы из первых ссылок по выдаче гугла.
Просто я работал с одной нераспределенной БД Oracle и Maria DB в рамках одного корпоративного монолита. А про остальное не знаю, вот и спрашиваю.
Одно дело, когда целостность данных конролируется триггерами и прочими связями самой БД. А как это в монгах и редисах я даже не представляю. И полагаю, что это делается на уровне модели софта.
Что вы подразумеваете под "целостностью данных" в key-value storage?
Именно там как раз нет, а получается, на уровне софта значит решают вопрос или вообще не решают?
Именно так.
Понятие "целостности", а точнее, консистентности данных, вообще растёт именно из реляционных СУБД, где данные (обычно) хранятся в нормализованном виде, то есть один объект представлен множеством записей во множестве таблиц. Соответственно, изменение свойств объекта может затрагивать несколько таблиц сразу. Отсюда и появляется необходимость в атомарных, консистентных, изолированных и детерминированных транзакциях (https://ru.wikipedia.org/wiki/ACID), которые значительно усложняют логику работы сервера БД.В документ-ориентированных и key-value СУБД объекты обычно либо атомарны сами по себе (например, настройка something=10), либо хранятся в денормализованном виде (все сведения об объекте в одной записи), поэтому там необходимость строго синхронно обновлять множество сущностей не является краеугольным камнем архитектуры БД. Обычно там вообще нет понятия foreign key.
NoSQL база хранит агрегат. Т. е. одна запись не раскидывается по нескольким таблицам, а значит для поддержания консистентности объекта -- транзакции не нужны. Если речь идеи о ссылках в объекте на другие объекты -- ссылки в NoSQL у нормальных людей постоянны (но вовсе не значения по ссылкам). Если же критично изменение конкретного числа объектов одновременно -- да, там используются всë теже транзакции. Но в голове всегда держим: транзакции гарантируют консистентность, но не гарантируют целостность. Тут поможет только фактор репликации "три". За счëт отсутствия необходимости транзакции на раскладывание сложного объекта -- NoSQL работает быстрее на запись/чтение. Вопрос быстрого поиска решается фильтрами Блума (да, индексы никто не отменял).
да нету там целосности. если целосность нужна (межсервисная), она реализуется тем, что операции умеют накатываться, откатываться, есть очереди для достижения консистентности к определенному моменту, ечть контроль, если очереди мертвых сообщений.
читай кафка, читай дельта-лямбда архитектуры, читай евент процессинг, гугли оркестрация, и проч.
Благодарю
Вы не понимаете, что такое "консистентность" и "целостность".
В NoSQL (сюрприз-сюрприз) есть как механизмы поддержания консистентности (нет, не так как в РСУБД) так и целостности.
да, русские термины перепутал, сорри.
имелось ввиду консистентность реализуется руками. встроенных механизмов нету.
с целостностью тоже не все очевидно. все что кей-валуе гарантирует - что есть кей, и что есть валуе. а вот что там - ...
так что снова руками.
тут конешн, все от конкретной бд зависит, их оч много.
> да, русские термины перепутал, сорри.
> имелось ввиду консистентность реализуется руками. встроенных механизмов нету.Ну вот не надо гнать. всё уже давно есть.
> с целостностью тоже не все очевидно. все что кей-валуе гарантирует - что
> есть кей, и что есть валуе. а вот что там -
> ...
> так что снова руками.Нет, давно уже не руками.
> тут конешн, все от конкретной бд зависит, их оч много.
Именно. Не все васяны одинаково полезны. Но все приличные васяны давно уже умеют и консистентность, и целостность.
>[оверквотинг удален]
>> имелось ввиду консистентность реализуется руками. встроенных механизмов нету.
> Ну вот не надо гнать. всё уже давно есть.
>> с целостностью тоже не все очевидно. все что кей-валуе гарантирует - что
>> есть кей, и что есть валуе. а вот что там -
>> ...
>> так что снова руками.
> Нет, давно уже не руками.
>> тут конешн, все от конкретной бд зависит, их оч много.
> Именно. Не все васяны одинаково полезны. Но все приличные васяны давно уже
> умеют и консистентность, и целостность.приличные васяны, это монга, да?)
ps CAP теорема как бэ - консистентность... ну в общем трейдоф )
Aerospike, Scylla
реббиты, эластики, постгресы + мемкаши и лоад-балансеры
>Redis обеспечивает постоянное хранение данных на диске и гарантирует сохранность БД в случае аварийного завершения работыОшибочное и вводящее в заблуждение утверждение.
Redis может работать как "in memory only", так и с дисковым хранилищем. Все зависит от настроек. Можно настроить сохранение на диск, например, после 500 успешных записей, или по таймеру.
Для того, что-бы *гарантировать* сохранность БД в случае аварийного завершения работы, надо настроить сохранение на диск после *каждой* операции записи. Только в таком режиме Redis ни кому не нужен.
Да нет, БД-то сохранится в любом случае, если save или aof включен.
Сохранность данных каждой операции - это уже явный перебор.
Даже в "больших и сложных" БД для этого нужен синхронный режим, который сильно просаживает производительность и поэтому нафиг не сдался.
А чем Редиска лучше Тарантула?
> А чем Редиска лучше Тарантула?Редиской :)
Чушь написали. Гуглите "сигналы ОС и их перехват".
И какой сигнал отправится процессам, если я выдерну оба блока питания?
> И какой сигнал отправится процессам, если я выдерну оба блока питания?А у вас размах рук 1500 км?
Вы когда-нибудь видели стоечный сервер?
> Вы когда-нибудь видели стоечный сервер?Вы когда-нибудь слышали, что реплики одной и той же базы нельзя размещать не то что в одной стойке -- даже в одном дата-центре?
И кто ж запрещает-то? Хоть на одном сервере размещай.
> И кто ж запрещает-то? Хоть на одном сервере размещай.Запрещает требование высокодоступности и высоконадёжности.
Рациональное мышление?
>Дополнительные модули, в которых предлагаются расширенные возможности для корпоративных пользователей, такие как RediSearch, RedisGraph, RedisJSON, RedisML, RedisBloom, с 2019 года поставляются под проприетарной лицензией RSAL.И нормальная авторизация тоже проприетарно. Walled garden для неосиляторов IPC. У неосиляторов такая судьба - страдать и платить, платить и страдать.
> нормальная авторизациКритерий нормальности давай, а то звучит как будто бы ты понятия не имеешь что такоетРедис и с чем его едят.
>Критерий нормальности давайБез плейнтекста, например. И с tls. С каких пор там в редисе всё это появилося, не подскажешь? И сколько редис жил без этого?
Я иначе как через mTLS с Редисом только на локалхосте разговаривал. Мне юниксвей позволяет иметь такие базовые вещи не дожидаясь пока разработчики у себя реализуют. Что тебе мешает — загадка.
Не, это не юниксвей, а модульная архитектура в целом и service mesh в частности.
Юниксвей - это когда "чего нет - то нам не нужно!!!1"
Можно и до сервис-меша. С сервис-мешем, конечно же, значительно удобнее.
>Мне юниксвейУ тебя и докер юниксвей, да?
>Я иначе как через mTLS с Редисом только на локалхосте разговаривал.
И до использования хешей пропатчил, ага. Хорошо ты так с темы соскочил, любитель мусорного софта.
Зачем тебе для mTLS произвольного tcp-сокета докер, болезный?
Помню, что в свое время столкнулись с каким-то ограничением на размеры толи списка толи словаря в этом Redis и это прям как-то было очень проблемно. Сейчас все еще есть ограничения на размеры этих сущностей. Вообще есть где-то бенчмарки на максимальные обьемы и отзывчивость Redis? Кто-то делал?
Конечно есть. Расскажете как уперлись в лимит в 4 лярда элементов в словаре?