Hacker News Reader

Comment by dangoodmanUT | Hacker News Reader

I have a hard time believing that Redis local was beat by SQLite local unless the workload was poorly fit for Redis structures, or the integration code wasn't well written.

But always happy to see a discovery of a better solution. I agree removing the network is a win.

View on HN

I do agree it is somewhat fishy of the large performance difference not being explained by comparatively fundamentally poor data access patterns.

However, Redis runs as an out of process server with marshaling and unmarshaling of data across sockets. SQLite is in process and with a prepared query is basically one library call to a purpose built data access VM. So I’m not sure why it would be hard to believe this cache and TLB friendly setup can beat Redis.

Thank you. First explanation what might be the root cause :)

In Redis, the data is a sorted-set that we forced into being lexicographically ordered by setting all the scores to 0. We went through a lot of iterations of it and to be clear it's not _slow_ it's just not as fast as essentially `fopen`

1 - Redis sorted sets - https://redis.io/docs/latest/develop/data-types/sorted-sets/

Just look at their use case. The have to store a large amount of logs of web-sites visitors or bots. Of course Redis is a very bad choice, because most servers don't have that much amount of memory. It's really useless to store logs in the RAM.

Reply on news.ycombinator.com