4 ms·

As one of the folks that currently works on Redis, I want to highlight the "Redis can be improved and should be improved". There is a lot of really good ideas p

As one of the folks that currently works on Redis, I want to highlight the "Redis can be improved and should be improved". There is a lot of really good ideas put forth that are likely worth consideration in the Redis project as well. There has been a lot of conversations about renewing multi-threading, especially to address the point of simplifying management and better resource utilization. Glad to see you guys made a lot of progress, although a little disappointing you chose to go down the path of building yet another source available DB and not contributing to open source.

tayo42 4y ago
Can someone/outsider realistically show up and start working on making redis multi threaded?
- reconditerose 4y ago
  Yes, the core folks in Redis now have outlined a plan for moving towards multi-threaded awhile ago. It's honestly not made a lot of progress because raw performance matters a lot less than is argued here. As was succinctly mentioned by antirez already, Redis scales comfortably to 100s of millions of QPS with cluster mode. So, it's really building a lot of custom functionality to support better vertical scaling. Which is useful, especially when the vertical scaling keeps you on a single process. The conversation happened here, https://github.com/redis/redis/issues/8340 https://github.com/redis/redis/issues/8340, and it's not like the most pressing issue for the project. It's also not as complex as what was implemented for dragonfly, which basically has native support from the ground up for concurrent programming during command execution. It would be hard to do in C as well.
  - tayo42 4y ago
    > raw performance matters a lot less than is argued here It matters a lot for where i work, we believe multithreading is holding redis peformance back. > Redis scales comfortably to 100s of millions of QPS with cluster mode. is there somewhere i can read more about that? curious about the server needs to do that. i worth key/value clusters a little larger then that. if possible it would be cool to use redis for it.
    - reconditerose 4y ago
      > It matters a lot for where i work, we believe multithreading is holding redis peformance back. Do you run stand alone Redis or Redis cluster? Multithreading is a strategy, but it isn't the only strategy to improving raw performance. > is there somewhere i can read more about that? curious about the server needs to do that. i worth key/value clusters a little larger then that. if possible it would be cool to use redis for it. Redis scales to about ~1000 nodes with each node supporting about 200k qps, math gets you to around 200m qps as the practical upper bound for Redis these days. Multithreading would potentially help us push clusters to the billion RPS boundary.
      - romange 4y ago
        Do you actually have a customer that runs a cluster of 1000 nodes? No need to answer this question. I can guess the answer.
    - romange 4y ago
      @tayo42 - we would love to engage and see how Dragonfly can fit the use-cases of your company.
      - tayo42 4y ago
        Hey sure don't mind chatting. How should I reach out?
        romange 4y ago
        @tayo42 roman@dragonflydb.io
- daniele_dll 4y ago
  https://github.com/danielealbano/cachegrand https://github.com/danielealbano/cachegrand :) I am not going to get into what's better and what's not, especially because I haven't released the v0.1 yet and therefore it's not usable, but I am working on cachegrand which is aims to be (also) a redis compatible platform. I have done A LOT of research and development before picking up the current architecture (you can see it from the amounts of commits) and I am trying to test as much as possible (Almost 1000 unit tests so far, but there is still plenty to do). if you look at the repository please bare in mind that: - there is no v0.1, the code available in the repo only supports the basic GET, SET and DELETE (apart from a few additional commands like HELLO, QUIT, PING) - the code in main currently supports only storing the data on the disk, which is also why the tests are failing, I am doing some general refactoring and need to bring back the in-memory storage (issue n. 88) - there are some general performance metrics available on the repo - don't enable verbose logging, it's currently synchronous :) - cachegrand is able to fully run in single thread mode so I can actually compare it to redis (well when it will make sense) - only linux, requires a kernel 5.8 at least (e.g. it's provided by ubuntu 20.04.2 lts, but I didn't really care too much as it will take quite a bit more before I get the first stable version and by that point the kernel requirement will not be an issue anymore) What I can say is that the project really focus ONLY on performances, therefore is not as memory saavy as redis or similar platforms, and it actually aims more to compete with Redis Enterprise long term than just Redis, on the other end it implements a number of things from the ground to boost massively the performances: - cachegrand architecture follows almost the share nothing principle with the only exception of the hashtable because it has been built around that need - I implemented from ground an hashtable capable to deliver lock-free and wait-free GET operations and which uses localized spinlocks for the SET and GET operations, basically the contention is spread across the hashtable instead of being bound to X queues - the hashtable also support SIMD operations (AVX, AVX2 and AVX512F), it's heavily optmized to reduce the memory accesses is able to embed short strings in the bucket to further reduce memory accesses - cachegrand will support both memory and ad-hoc backend for the storage that is going to be basically a time-series database (cachegrand is not bound to redis functionalities, the redis command set is just a way to expose these for now) - I implemented from scratch a fiber library able to do a context switch in just 7ns - the network and storage backend are modular, currently it really only support io_uring but the goal is to also add XDP+the FreeBSD network stack support for the network (e.g. similar to what has been done with F-Stack and DPDK) and then io_uring with the NVME passthrough for the storage (not sure if I will also add support for SPDK) - I have also implement an ad hoc memory allocator which waste some memory but it's able to do memory allocations and free in O(1) (here a nice chart https://www.linkedin.com/posts/danielesalvatorealbano_dublin-zurich-microsoft-activity-6918906983848796160-5Xwx?utm_source=linkedin_share&utm_medium=member_desktop_web https://www.linkedin.com/posts/danielesalvatorealbano_dublin...) - most of the code is built aiming to be zero-copy (there are a few places where it happens right now as I need to fix a couple of things) Just to underline it, currently it's not possible to play with it, until I merge the branch I am working on, because performances would be terrible (only on-disk storage and currently without caching), the tests are broken for the same reason.
romange 4y ago
I think at this point of time and the state of this 14 years old project the status quo can be changed only from the outside. If chrome was not born you would still use microsoft explorer with aspx sites.
- reconditerose 4y ago
  I think that is a pretty baseless claim, even more so given that the project had a complete leadership change only 2 years ago. There is a lot of interest in revamping the internals of Redis while still trying to maintain the original tenets that established Redis. There isn't much justification for saying it could only be changed from the outside when, AFAIK, you didn't try to engage with the system at all.
  - romange 4y ago
    Believe me, I kinda tried to engage with the system. Maybe a bit different system ;) I based my clain on my personal experience and it's not related to Redis specifically. People are people. They become defensive when something new tries to replace old views. Usually it does not work when you have no leverage and challenge the status quo within the system that has no good reason to change i.e loose money and margins due to increased efficiency of the underlying infrastructure. It's a classic innovator's dillema. Imho...
- teach 4y ago
  I just want to say that this comment alone has put me off looking into Dragonflydb.
  - romange 4y ago
    Sorry to hear that. But let me quote antirez response from this topic: "...But I think that Redis may go fully threaded soon or later, and perhaps your project may accelerate the process". Lets at least agree that if Dragonfly will push redis to evolve, it's a good thing.

tayo42 4y ago

Can someone/outsider realistically show up and start working on making redis multi threaded?

reconditerose 4y ago
Yes, the core folks in Redis now have outlined a plan for moving towards multi-threaded awhile ago. It's honestly not made a lot of progress because raw performance matters a lot less than is argued here. As was succinctly mentioned by antirez already, Redis scales comfortably to 100s of millions of QPS with cluster mode. So, it's really building a lot of custom functionality to support better vertical scaling. Which is useful, especially when the vertical scaling keeps you on a single process. The conversation happened here, https://github.com/redis/redis/issues/8340 https://github.com/redis/redis/issues/8340, and it's not like the most pressing issue for the project. It's also not as complex as what was implemented for dragonfly, which basically has native support from the ground up for concurrent programming during command execution. It would be hard to do in C as well.
- tayo42 4y ago
  > raw performance matters a lot less than is argued here It matters a lot for where i work, we believe multithreading is holding redis peformance back. > Redis scales comfortably to 100s of millions of QPS with cluster mode. is there somewhere i can read more about that? curious about the server needs to do that. i worth key/value clusters a little larger then that. if possible it would be cool to use redis for it.
  - reconditerose 4y ago
    > It matters a lot for where i work, we believe multithreading is holding redis peformance back. Do you run stand alone Redis or Redis cluster? Multithreading is a strategy, but it isn't the only strategy to improving raw performance. > is there somewhere i can read more about that? curious about the server needs to do that. i worth key/value clusters a little larger then that. if possible it would be cool to use redis for it. Redis scales to about ~1000 nodes with each node supporting about 200k qps, math gets you to around 200m qps as the practical upper bound for Redis these days. Multithreading would potentially help us push clusters to the billion RPS boundary.
    - romange 4y ago
      Do you actually have a customer that runs a cluster of 1000 nodes? No need to answer this question. I can guess the answer.
  - romange 4y ago
    @tayo42 - we would love to engage and see how Dragonfly can fit the use-cases of your company.
    - tayo42 4y ago
      Hey sure don't mind chatting. How should I reach out?
      - romange 4y ago
        @tayo42 roman@dragonflydb.io
daniele_dll 4y ago
https://github.com/danielealbano/cachegrand https://github.com/danielealbano/cachegrand :) I am not going to get into what's better and what's not, especially because I haven't released the v0.1 yet and therefore it's not usable, but I am working on cachegrand which is aims to be (also) a redis compatible platform. I have done A LOT of research and development before picking up the current architecture (you can see it from the amounts of commits) and I am trying to test as much as possible (Almost 1000 unit tests so far, but there is still plenty to do). if you look at the repository please bare in mind that: - there is no v0.1, the code available in the repo only supports the basic GET, SET and DELETE (apart from a few additional commands like HELLO, QUIT, PING) - the code in main currently supports only storing the data on the disk, which is also why the tests are failing, I am doing some general refactoring and need to bring back the in-memory storage (issue n. 88) - there are some general performance metrics available on the repo - don't enable verbose logging, it's currently synchronous :) - cachegrand is able to fully run in single thread mode so I can actually compare it to redis (well when it will make sense) - only linux, requires a kernel 5.8 at least (e.g. it's provided by ubuntu 20.04.2 lts, but I didn't really care too much as it will take quite a bit more before I get the first stable version and by that point the kernel requirement will not be an issue anymore) What I can say is that the project really focus ONLY on performances, therefore is not as memory saavy as redis or similar platforms, and it actually aims more to compete with Redis Enterprise long term than just Redis, on the other end it implements a number of things from the ground to boost massively the performances: - cachegrand architecture follows almost the share nothing principle with the only exception of the hashtable because it has been built around that need - I implemented from ground an hashtable capable to deliver lock-free and wait-free GET operations and which uses localized spinlocks for the SET and GET operations, basically the contention is spread across the hashtable instead of being bound to X queues - the hashtable also support SIMD operations (AVX, AVX2 and AVX512F), it's heavily optmized to reduce the memory accesses is able to embed short strings in the bucket to further reduce memory accesses - cachegrand will support both memory and ad-hoc backend for the storage that is going to be basically a time-series database (cachegrand is not bound to redis functionalities, the redis command set is just a way to expose these for now) - I implemented from scratch a fiber library able to do a context switch in just 7ns - the network and storage backend are modular, currently it really only support io_uring but the goal is to also add XDP+the FreeBSD network stack support for the network (e.g. similar to what has been done with F-Stack and DPDK) and then io_uring with the NVME passthrough for the storage (not sure if I will also add support for SPDK) - I have also implement an ad hoc memory allocator which waste some memory but it's able to do memory allocations and free in O(1) (here a nice chart https://www.linkedin.com/posts/danielesalvatorealbano_dublin-zurich-microsoft-activity-6918906983848796160-5Xwx?utm_source=linkedin_share&utm_medium=member_desktop_web https://www.linkedin.com/posts/danielesalvatorealbano_dublin...) - most of the code is built aiming to be zero-copy (there are a few places where it happens right now as I need to fix a couple of things) Just to underline it, currently it's not possible to play with it, until I merge the branch I am working on, because performances would be terrible (only on-disk storage and currently without caching), the tests are broken for the same reason.

romange 4y ago

I think at this point of time and the state of this 14 years old project the status quo can be changed only from the outside. If chrome was not born you would still use microsoft explorer with aspx sites.

reconditerose 4y ago
I think that is a pretty baseless claim, even more so given that the project had a complete leadership change only 2 years ago. There is a lot of interest in revamping the internals of Redis while still trying to maintain the original tenets that established Redis. There isn't much justification for saying it could only be changed from the outside when, AFAIK, you didn't try to engage with the system at all.
- romange 4y ago
  Believe me, I kinda tried to engage with the system. Maybe a bit different system ;) I based my clain on my personal experience and it's not related to Redis specifically. People are people. They become defensive when something new tries to replace old views. Usually it does not work when you have no leverage and challenge the status quo within the system that has no good reason to change i.e loose money and margins due to increased efficiency of the underlying infrastructure. It's a classic innovator's dillema. Imho...
teach 4y ago
I just want to say that this comment alone has put me off looking into Dragonflydb.
- romange 4y ago
  Sorry to hear that. But let me quote antirez response from this topic: "...But I think that Redis may go fully threaded soon or later, and perhaps your project may accelerate the process". Lets at least agree that if Dragonfly will push redis to evolve, it's a good thing.