|Hacker News, Reddit, Stack Overflow Stats|
No public GitHub repository stats available
|Description||An in-memory database that persists on disk||Flash-optimized in-memory open source NoSQL database||Database for real-time transactions and analytics.|
|Why people like using this service||
|Companies using this service|
Good for a cluster, much slower than EhCache
February 17, 2017 18:25
Redis is a good caching tool for a cluster, but our application had performance issues while using Aws Elasticache Redis since some page had 3000 cache hits per a page load and Redis just couldn't quickly process them all in once + latency and object deseialization time - page load took 8-9 seconds. We create a custom hybrid caching based on Redis and EhCache which worked great for our goals. Check it out on github, it's called HybriCache - https://github.com/batir-akhmerov/hybricache.
Redis makes certain operations very easy. When I need a high-availability store, I typically look elsewhere, but for rapid development with the ability to land on your feet in prod, Redis is great. The available data types make it easy to build non-trivial indexes that would require complex queries in postgres.
I use Redis for cacheing, data storage, mining and augmentation, proprietary distributed event system for disparate apps and services to talk to each other, and more. Redis has some very useful native data types for tracking, slicing and dicing information.
We use redis as a cache. Nothing too fancy here. At one point we were using it to cache character information, but we've since moved that entirely to DynamoDB and are evaluating the performance before we bring redis back in.
Used as a caching layer (when we need more functionality than simple key-value storage); keeping lists of online users, used for our smart-assigning feature, keeping track of sliding-window rate limiting information.
It is used as a caching tool. If a query is made, it is cached in Redis. For 2 minutes, other users see Redis query cache, instead of keeping crawling ESHOT page.
Queue to speed up requests of long running operations (e.g. sending email, push notifications)
Fast cache is used to store short term information from devices and detect change in status of the device.
As our in-memory database, to temporarily store individual object properties and query results, which in turn powers our live feed and quick filtering of driver data.
Redis is the backing data store for Sidekiq, only used for background queue processing.
We used Redis to cache server requests, which cut down response times on most requests by at least 1/10.
Cache for data we need fast. Local regions. We sync some tables with either mysql or mongo.
Redis is used to cache data which is rarely changed but often requested like huge JSON structures.
I used Redis to store subscriber preferences (such as language), for which a database would have been overkill.
All data not yet commited to PostgreSQL, lives in multiple redis instances. We are heavy users of lua in redis to enable custom queue behavior.
Redis is used for caching and advanced key-value storage to maintain quick access objects and counters. It also used to back resque workers
Redis is used for storing all ephemeral (that's data you don't necessarily want to store permanently) user data, such as mapping of session IDs (stored in cookies) to current session variables at Cloudcraft.co. The many datastructures supported by Redis also makes it an excellent caching and realtime statistics layer. It doesn't hurt that the author, Antirez, is the nicest guy ever! These days, I would be really hard pressed to find any situation where I would pick something like Memcached over Redis.
Easy persistence with json semantics that fits my program structure: No searches and no indices where I just have direct references.
We use Redis for several different things, but majoritively for server or frontend caching, and session management, both things it excels at.
Session management, Leaderboards, instant messages, and many others use Redis (cluster with Redis Sentinel)
We also have support for Redis databases so that developers can interact with their data.
We use Redis as a key-value store, a cache, and a message queue. It's a ridiculously fast and simple-to-maintain jack-of-all-trades.
memcached 와 비슷한 퍼포먼스를 내면서 persistence 지원을 통해 in-memory cache 의 단점을 충분히 극복합니다. 메인 캐시서버로 사용하고 있습니다.
→ Tom Z
Replaced memcache and alleviated lots of issues on the spot absolutely amazing caching, with memory-based storage it's a win-win.
The UI has message inbox that is sent a message when you get a new badge, receive a message, significant event, etc. Done using WebSockets and is powered by redis. Redis has 2 slaves, SQL has 2 replicas, tag engine has 3 nodes, elastic has 3 nodes - any other service has high availability as well (and exists in both data centers).
Trello uses Redis for ephemeral data that needs to be shared between server processes but not persisted to disk. Things like the activity level of a session or a temporary OpenID key are stored in Redis, and the application is built to recover gracefully if any of these (or all of them) are lost. We run with allkeys-lru enabled and about five times as much space as its actual working set needs, so Redis automatically discards data that hasn’t been accessed lately, and reconstructs it when necessary.
Aerospike is used heavily in our real time kafka pipeline. We use it two ways: we harness the fast key-value store lookup and leveraging Aerospikes ACID capabilities through UDFs we could manage updates in real time.