Hacker News Reader

Comment by maxmcd | Hacker News Reader

My understanding is that Redis is fast because it writes and reads from memory. Postgres is slower because it ensures writes are persisted to disk before responding (among other reasons). So even if you use RDB and AOF with Redis, you can still readily lose data even after the database has confirmed it's been written. The database can confirm a write and then crash before that write has been persisted to the AOF and RDB.

This is why I thought you wouldn't want to run Redis as a primary database.

View on HN

> My understanding is that Redis is fast because it writes and reads from memory. Postgres is slower because it ensures writes are persisted to disk before responding (among other reasons).

If you don't need transaction commits to be durable, you can turn that off in postgres, on a per-transaction/connection/user/database basis. E.g.

  BEGIN;
  SET LOCAL synchronous_commit = off;
  /* bunch of writes */
  COMMIT;

will, just for that one transaction, not wait for transaction commits to be flushed to disk. Can be very useful for not-that-important data...

Redis does have an option `set appendfsync always` which ensures that every write is written to disk, but as you might expect this drastically impacts performance.

It still only syncs every 1 second, IIRC.

What you really want is 2 replicas in a shared-nothing environment, and use min-replicas-to-write.

I believe you may be confusing `set appendfsync always` which syncs on every write with `set appendfsync everysec` which syncs every second. The latter is more practical for typical redis use-cases and therefore I suspect much more common in the wild.

You're also manipulating datastructures directly with Redis. So there is very little abstraction compared to a DB.

Presumably that means Redis is fundamentally single threaded?

It is, but not because you manipulate datastructures directly. You could "just" implement fine-grained locking around elements of the data structures and have a multi-threaded Redis-like system. Indeed, there are several forks of Redis that do this.

Redis itself is single-threaded because it makes for a very straightforward implementation that is easy to expand with new data structures and easy to grok for users. For 99% of applications, read scaling through replicas and write scaling through keyspace sharding is still more than fast enough, because the biggest time sink is in the latency between servers and not in the execution of the commands themselves. Therefore, multithreading would not win you much throughput except when you have very hot keys containing hashmaps or something like that. In those cases, consider one of the multi-threaded variants.

it's single threaded, but event driven. it doesn't block the whole server when it does blocking IO.

for good or bad, that means you scale it horizontally by running an instance per core and shard appropriately to that.

What kind of IO operations Redis does? The replication or disk persistence? I thought that prolly runs in other threads not the one which is serving clients

yes, I believe (haven't actually looked closely at it, just based on other stuff I've done with redis module interface) that they occur in the single process, just via event driven architecture so the process doesn't block on them.

follow https://github.com/RedisLabs/redisraft/

Reply on news.ycombinator.com