Live data from Hacker News

A multithreaded fork of Redis that is faster

docs.keydb.dev

161–164 of 164 posts

Re: A multithreaded fork of Redis that is faster

#161
This looks promising.

But I still love Redis.

1. It is one of the most reliable software I used in production.

2. Not everyone wants 'faster than light' software.

3. Simplicity of redis blows my mind. It is very easy to maintain and almost never have a single issue.

4. These days everyone talks about scale but very few projects need FAANG-level scale. Point is there are so many small projects where current redis fits seamlessly. Just making case for Redis.

Re: A multithreaded fork of Redis that is faster

#162
post #148

Earlier quoted context omitted.

> and contributed nothing back Why do we assume closed-source software vendors contribute nothing back? Speaking as an employee at a company that produces a closed-source software product that uses open-source libraries, I've contributed plenty back to various libraries, including publishing some of my own. Libraries with permissive licenses get more users, and more users mean more opportunities for receiving contrib…

Working in places that were based off permissively licensed software, the default position we had was "no upstreaming" and if I wanted to upstream something I need to ask for permission. when you're contributing to GPL software, you don't need your employer's permission for it to be upstreamed. If they release the code, and don't violate the GPL, then there's nothing the employer can do to stop it from going upstream…

> when you're contributing to GPL software, you don't need your employer's permission for it to be upstreamed.

Yes you do. Except the permission in this case is "permission to use the library" in the first place, which is a much higher bar than permission to upstream changes to a permissively-licensed library because using a GPL library has much farther-reaching implications than merely contributing changes back.

Re: A multithreaded fork of Redis that is faster

#163
post #148

Earlier quoted context omitted.

> and contributed nothing back Why do we assume closed-source software vendors contribute nothing back? Speaking as an employee at a company that produces a closed-source software product that uses open-source libraries, I've contributed plenty back to various libraries, including publishing some of my own. Libraries with permissive licenses get more users, and more users mean more opportunities for receiving contrib…

Working in places that were based off permissively licensed software, the default position we had was "no upstreaming" and if I wanted to upstream something I need to ask for permission. when you're contributing to GPL software, you don't need your employer's permission for it to be upstreamed. If they release the code, and don't violate the GPL, then there's nothing the employer can do to stop it from going upstream…

> when you're contributing to GPL software, you don't need your employer's permission for it to be upstreamed

Yes, you do; if you are contributing to it, you need to have exactly that permission. If you are working on a derivative, you need that permission before you can contribute it to anyone else, including upstream.

> If they release the code

Plenty of people work on internal code for their employers, so this is not a given.

Re: A multithreaded fork of Redis that is faster

#164
post #57

Earlier quoted context omitted.

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.

You'd expect a 1/n where n is number of cores available utilization in the case of redis being CPU bound. 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.

Redis handle all request serially, because of that it is much simpler to be correct and doesn't have to worry as much about distributed gotchas.

Because redis handles all requests serially you need to be very careful if the redis cluster is shared between different apps. You want to share the cluster among apps with similar usage patterns.

Post reply on HN