[flaghacker]

What would be the point of embedding Redis into an application? What's the advantage of using Redis over using the builtin (or third party) data structures of the language the application is developed in?

I'm asking as a non-webdev who never quite got what Redis actually does, but would love to learn.

[jchw]

To me the thing I like about Redis is that it gives you a storage engine very suitable for caches; it handles TTLs and memory pressure, as well as built-in serialization with the ability to get better performance by allowing for some data loss. At the same time, many users will be deploying small programs to individual machines. If you could just have Redis be embedded this would make it very operationally simple: no additional daemons and a single file to backup if you want to.

It would also be useful because of the ability to switch modalities. When running a multi node service, you can use Redis to share data between nodes and use Redis pubsub as a communication bus. If you wanted to support a simple single node configuration too, then it wouldn't need to be a special case, it could just go through the same mechanism but with an embedded Redis instance.

It's pretty similar to SQLite: being able to embed more or less a complete storage engine into your app can be very convenient and powerful.

[0x457]

Well, if you have a single instance than using language libraries and structures will be better in most cases.

If you use multiple nodes, then you probably want your redis lifecycle not be tied to application lifecycle.

[jchw]

I am not aware of an in-process alternative similar to what Redis offers.

[WJW]

Well the most basic redis replacement would be just a global hashmap to replace GET and SET, possibly with a background thread to periodically delete expired keys. But obviously that stops working as soon as you get a second node.

The entire value of redis IMO is that is ISN'T inside your normal application, but rather some shared storage that all nodes can use to coordinate and that survives deploys, but that provides more ergonomic data structures than SQL databases. Caches are only one type of such shared data, but things like feature flags, circuit breakers and rate limiters are also super common (and super useful).

[nomel]

Neat. Write that up, match parity, and give all the function calls with the same name as redis, and you're both happy! You get to hand roll something, he gets to use a library that others have perfected over the years!

[WJW]

Ehm no? Do it yourself if you want. I'm already happy.

[s_trumpet]

Mnesia, if you’re using Erlang or Elixir.

[jchw]

Unfortunately I have never really used Erlang outside of deploying RabbitMQ. I mostly use Go, Rust, Python, sometimes C/C++.

However, Mnesia seems like it is quite a bit more of a complete distributed database engine than Redis. To me the nicest thing about Redis is just the convenience of what it offers: very fast data structures, serialized, optimized (at least by default) for cases where speed is more important than durability. It is simple on many levels and somewhat constrained in scope. Mnesia seems to be aiming more generally in the distributed database category.

So how do you feel they compare?

[wkrp]

Really it would be more like Nebulex/Cachex which provide a really nice caching interface across ETS (what Mnesia is built off of) or other data stores.

[0x457]

I would Cache with TTL? A cache that can store lists?

[freakynit]

Probably because Redis gives you a very well-defined/understood set of rich data structures with built-in behavior like TTL, atomic operations, eviction, and persistence. These things are otherwise usually scattered across native types, helper classes, or entirely separate libraries.

[stingraycharles]

It doesn’t seem like the right tool for the job, though. Aren’t your own programming language’s constructs much more well-defined / understood ?

[freakynit]

Language's own native data-structures are generally much more capable and vast. 99%+ developers use only a very limited set of those capabilities. This approach packages those most used ones into a nice, consistent DSL.

It's similar in effect to what busybox does to shell utilities, though the motives are different.

[atmosx]

Doesn’t depend on the language? Actually I am thinking of the standard library… Python’s in kinda huge and some are hard (for me) to grasp. Golangs seem pretty simple.

[stingraycharles]

Language’s own native data structures isn’t limited to just the standard library.

[rsalus]

agreed but depends on then language. for instance, the .NET equivalent (MemoryCache) is pretty poor.

[simonw]

Redis has some pretty useful primitive that many languages don't:

- HyperLogLog, bloom filter, other probabilistic data structures

- Geospatial operations on stored points and polygons

- Expiring keys, for creating caches

These aren't in most standard libraries, and the Redis implementations tend to be fast, robust and well understood.

[0x457]

Can you name a single language that can talk to redis and doesn't have these in a form of a library that integrates with an app better than mystical embedded redis?

Every language you can talk to redis most likely has a library to do that, and it probably works much better with the rest of application than "embedded redis". If it doesn't, it probably has C-FFI and there is "fast, robust and well understood" implementations in C.

[simonw]

Sure. But if Redis was embeddable you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.

(I'm not personally sold on embedded Redis myself, but the question was "Aren’t your own programming language’s constructs much more well-defined / understood?")

[0x457]

> you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.

What are these mystical random libraries you're talking about? There is a solid C implementation of every data structure on this planet.

[lpapez]

I use PHP. None of the language tools or constructs available to me are adequate.

https://blog.codinghorror.com/the-php-singularity/

[stingraycharles]

And you want to embed Redis inside PHP as a solution?? That’s nuts.

[sinpif]

Where else could they store their serialized PHP data structures? (just kidding)

[zbentley]

A few nice things about doing this in no particular order:

Embedding would make local dev/CI integration testing convenient.

Embedding replicated Redis with each application instance would give you HA benefits while infra-management complexity.

Embedded redis (even via local RPC) is still going to be faster than a lot of languages or frameworks’ built-in data structures. Large array operations in, say, Python are gonna slower than RPCing to Redis (assuming that the data structures are built gradually and not built all at once); to beat Redis you’d have to use numpy or something—-which is definitely preferable, but is extra work if your app already uses Redis for other things.

Just like choosing SQLite over e.g. LMDB or RocksDB, embedded Redis would be a nice future proofing option for small apps during the prototype phase; less would have to be changed to move Redis out of the app than if a different cache or persistence service were chosen.

[jaapz]

I have 15 processes handling API requests over HTTP. I want rate limiting, so users don't DoS my API. I need shared state across these processes to store information about rate limits for each client key. I store those in redis.

Or queues, caching, pub/sub... Redis can do a lot, it's really (and i mean really) fast, very easy to get up and running and the protocol is pretty simple.

[jiggawatts]

Locality and latency.

Network hops are not free! Those milliseconds are an eternity compared to local function calls.

The optimal architecture is something like what Service Fabric or Orleans can do with their distributed dictionary types: reads are generally in-process and take only nanoseconds (but writes require a synchronous replica copy to a remote host.)

Obviously this requires load balancers to steer traffic consistently, but that’s a common feature… outside of the public clouds where they forgot latency exists.

[noodletheworld]

Why would you embed SQLite?

It’s the same use case with a different api.

A typical (meaningful) example might be communication between threads or actors in a single process, or idempotent tests.

As with SQLite, an external xxx that does this for you is certainly better, etc. but it’s convenient sometimes, to have an application that doesn’t go “now before you run this install Postgres…”.

It’s seldom useful for a web app where you control everything.

[razighter777]

In practice, mostly scaling sessions and ephemeral data (caching) across multiple intances of a microservice on multiple machines. Seperating the kv store and the application allows upgrading each application while retaining availability and avoiding loss of session data.

[nilamo]

I mostly use redis for pub/sub communication between services. If the app wasn't a collection of knative functions, and instead a monolith, it would be cool to also use redis for event based communication.

[mystifyingpoi]

For simple cases, it is probably a total overkill to even consider it, but for something heavier, embedding the database gives you a chance to trivially migrate later to a separate database server.

[thefreeman]

Redis is not a database. It’s a key / value store.

[rytis]

It kind of is a database:

A key-value database, or key-value store, is a data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a dictionary.

https://en.wikipedia.org/wiki/Key–value_database

[theultdev]

that's still a database.

it's not a relational database.

[bijowo1676]

you are confusing redis with memcached