61–70 of 164 posts
You went to the effort of forking Redis but didn’t bother to fix the glaring lack of TLS support? What is the fucking point of a replicated KV store if the connections between nodes aren’t encrypted.
On 32 cores? Doesn't seem like particularly great scaling.
Earlier quoted context omitted.
But isn't the point of Redis is to be used as a caching layer instead of persistent layer
But what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.
Basically redis can't necessarily guarantee data safety - which is perfectly fine for it's normal use case as a caching layer and data you don't necessarily care if you lose (for example rate limiting relies on tracking the number of requests/s within say an hour - if you lose the data you don't really care). User sessions too, worst case people have to log in again, meh whatever.
You went to the effort of forking Redis but didn’t bother to fix the glaring lack of TLS support? What is the fucking point of a replicated KV store if the connections between nodes aren’t encrypted.
We have it in Redis 6, ETA for RC1 is end of year. However we did it the right way with a socket abstraction layer, one of the reasons it took so long.
Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
The idle CPU might very well be due to redis being single threaded. It might be hitting is limits and still show low CPU utilization. Also, you didn't mention that, but I've seen this happening often, you should never use redis as a primary data store if your data is important.
I guess I don't know how redis deals with the network, but I'd assume that it handles concurrent requests. If not, then I guess that's the case where you'd see less than 1/n cpu utilization and it could still be CPU bound.
I guess I can no longer use Redis. I mean what can the use case of normal Redis possibly be?
Earlier quoted context omitted.
Facebook just published a blog about moving petabytes per hour. I read it, I find the design interesting. I don't need it. But if I do, it's good to know that it's possible, that someone has solved, to have a reference and to possibly use their tool if it's free. So relax, I for one welcome whatever folks are working on out there. If it's true, we can learn from it and apply it in order domains too.
> Facebook just published a blog about moving petabytes per hour. For the curious: https://engineering.fb.com/data-infrastructure/scribe/ Edit: HN thread: https://news.ycombinator.com/item?id=21181982
Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
If redis isn't multi-threaded the more cores and threads you have, the less CPU usage the machine would show, even if Redis is being stressed.
You went to the effort of forking Redis but didn’t bother to fix the glaring lack of TLS support? What is the fucking point of a replicated KV store if the connections between nodes aren’t encrypted.
We have it in Redis 6, ETA for RC1 is end of year. However we did it the right way with a socket abstraction layer, one of the reasons it took so long.
Earlier quoted context omitted.
We have it in Redis 6, ETA for RC1 is end of year. However we did it the right way with a socket abstraction layer, one of the reasons it took so long.
Is there any relevant documentation/discussion available?