Когда приходится работать большими redis базами в десятки Гб понимание “а как оно там?”, “откуда такой размер?”, “как правильно отстрелить ногу при проектировании схемы данных?” - может быть полезно. Вообще структура хеш-таблиц в redis используется достаточно широко. Возьмём, к примеру структуру базы данных.
База данных redis (статья написана по redis_version:8.0) это сложное хранилище состоящее из большого количества hash-таблиц
Читать полностью »Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Дрю ДеВолт объясняет, что веб-интерфейс Github.com требует множества лишних действий. Гораздо эффективнее использовать консольный почтовый клиент, отправляя тот же пулл-реквест одной командой из консоли
Американский разработчик Дрю ДеВолт (Drew DeVault) известен как создатель и исполнительный директор платформы для хостинга проектов SourceHut, которую Фонд сохранения свободы ПО выбрал как альтернативу майкрософтовскому сервису GitHub (наряду с CodeBerg) в рамках кампании Give Up GitHub по уходу свободных проектов с этого коммерческого хостинга, задача которого — генерировать продажи Copilot.
ДеВолт также известен как автор нового языка системного программирования Hare, который похож на С, только лучше и проще его.Читать полностью »
Redis — хранилище из семейства нереляционных (NoSQL) баз данных. Redis является очень быстрым хранилищем данных благодаря своей архитектуре in-memory. Он идеально подходит для задач, требующих быстрого доступа к данным, таких как кэширование, очереди сообщений, сессионная информация и многое другое. Go также известен своей высокой производительностью за счет компиляции в машинный код и эффективного управления памятью.
Некоторые компании, работающие с персональными данными пользователей, сталкиваются с невозможностью хранить их в течение долгого периода времени из-за правовых ограничений. Такое часто можно встретить в финтехах. Позволяется сохранить данные на очень короткое время, которые также должны быть удалены сразу после использования в целях сервиса. Существует несколько вариантов решения этой задачи. В данном посте я показываю упрощенный пример микросервиса, работающего с чувствительной информацией, используя Spring и Redis.
Недавно на Хабре публиковался перевод статьи «Просто выберите Postgres» (оригинал, англ. яз) с аргументами, что Postgres — оптимальная БД для десктопных и мобильных приложений. Аналогичное мнение высказывают в других популярных статьях вроде «До свидания MongoDB, здравствуй PostgreSQL». Главным недостатком SQLite называют то, что данные хранятся в одном файле, а MongoDB (а также DynamoDB и Cassandra) — низкую производительность:
«Всё это связано с тем, что подобные базы данных, по сути, представляют собой огромную распределённую хеш-таблицу. Единственные операции, работающие без необходимости сканирования всей базы данных — это поиск по секционному ключу и сканы, при которых используется ключ сортировки.
…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».
Более производительные резидентные БД хранят данные в памяти (Redis, Valkey), но их использование ограничено объёмом ОЗУ.
После такого заявления интересно посмотреть на независимые тесты производительности разных СУБД.Читать полностью »
Мы (R&D-банда devhands.io) закончили тестирование официального релиза Valkey и его сравнение с прародителем, Redis, форком которого тот является. Для тех, кто не очень в курсе: Valkey появился на свет после смены лицензии Redis, под покровительством облачных провайдеров, в первую очередь AWS.
Основное внимание мы уделили пропускной способности и времени отклика в режиме чтения - в зависимости от параметра io-threads, отвечающего за "частичный параллелизм" в этих продуктах. Забегая вперед, скажем, что в режиме записи результаты похожие и все пропорции сохраняются - всё-таки это in-memory store.
Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint Highload++ 2024, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.
