romange

@throwaway888abc would love to hear what your impressions are.

you can dm me at roman at dragonflydb.io

yes

who do you think uses webdis and for what use-cases? we are curious about http but we want to understand the reasons first.

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 roman@dragonflydb.io

Indeed :) The moment i learned about io_uring I got hooked up immediately. People like Jens, Pavel are the type of innovators that make sure Linux stays on top of its game for the next generations.

I think I found a great analogy for the "N redises vs a single dragonfly" question.

In Israel, nowdays, the price of a watermelon in a local supermarket is 1.8$.

But if you go to farmers in the north, you can probably buy it for 30-50 cents. But then you would spend 3 hours in traffic and 20$ on gas.

So, Dragonfly is a local-supermarket that sells watermelons for 50 cents. mic drop.

The best tool out there is probably jepsen.io but it requires domain knowledge to properly operate it. The guy behind it is a beast!

Anyway, I wrote lots of unit tests to cover those atomicity issues. You can also write a custom python/nodejs/golang/... scripts that simultenusly write and read from the same multiple keys in such way that some invariant is preserved. For example, "mset x {i}, y {i}" for random `i` and in parallel do "mget x y" and to check that the response returns same values. You can also test this for other families using transactions like "MULTI; lpush x ${foo}; lpush y ${foo}; EXEC" .. and then similarly test that x and y have exactly the same lists.

1. I think this is how Redis the company designed their enterprise solution. You can find architecture documentation on their site. 2. Based on my knowledge it should be more or less equivalent. The reason they put it on the same machine (i am guessing here) is because shards on the same node are behind their Redis proxy, that kinda hides the complexity of connecting to each node separately. it's like a gateway to that machine and to all its redis processes.

It's interesting comment, phamilton. I agree with antirez and I agree with you. full discloser - I am ex-googler. I believe that "horizontal scale" movement staryted from Google. You could see it in their GFS and Mapreduce papers from early 2000s. And by that time they were completely right, of course. Geniuses of Jeff Dean and Sanjay Gwattemat put Google year ahead compared to other state of the art for more than a decade. There was not even one system developed in Google that is not horizontally scalable (i am omitting acquisitions here). We used to joke in 2009 that the most expensive server we have is our perforce server. Nowdays it's internally developed source control system that is backed by Bigtable. So of course, antirez is right, of course! If you need infinite scale - you must go horizontally.

But the reality is that most companies and most use-cases do not need terrabytes of data. I would say that today the comfort zone for Dragonfly is upto 512GB per instance (1). So dragonfly solves the issue for... I would say 99% percent of the use-cases. Only the last percentile would need horizontal scale, and probably their business is already big enough, so that they can affort a high-quality eng team to work with horizontal clusters.

(1) We need to improve some things (mainly around serialization format of rdb) to reach another magnitude of 4TB. Nobody wants to wait for days to load a 4TB snapshot.

interesting. i still need to learn a lot about how other systems provide durability guarantees. Based on what you are saying, Scylla guarantees H/A instead of full durability. I was thinking about WAL (AOF) for dragonfly and I kinda thought to start with "fdatasync once in every X seconds", but dragonfly is not a database. I would expect stronger guarantees from databases. Maybe it's inpractical to expect this in cloud environments...

they need at least perform fdatasync before replying to a client, imho. so I do not think it's every x seconds. I am not deeply familiar with scylla so maybe I am mistaken.

@tayo42 - we would love to engage and see how Dragonfly can fit the use-cases of your company.

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...

I benchmarked DF vs single core Redis. If there is a constructive suggestion for a different benchmark that compares similar product propositions I will happily oblige and do that. i.e. what do you mean by using Redis as intended?

Do you actually have a customer that runs a cluster of 1000 nodes? No need to answer this question. I can guess the answer.

btw, please follow me for updates about dragonflydb at https://twitter.com/romanger

Some valid business use-cases allow eventual consistency. Think of social apps, for example. FB and TW have excellent engineering teams and they built huge systems that rely on caching layers. Similarly, with gaming companies.

We did not disclose the algo yet. Once I publish the doc in the repo, I will tweet about it. (soon)

it is architecturally different. DF has the orchestrator underneath. The general. The guy that handles all the incoming requests and makes sure they execute atomically. Redis cluster is an orchestra without the orchestrator. Everyone to himself. It's share-nothing that is exposed outside. To actually hide the complexity in a *transparent way* is a difficult problem. Researches write articles on how to solve this problem efficiently.

Wow, glad to hear!

Thats what i did. I did not try to cheat. Running N redises is a completely different product. You will have n listening ports and your loadtest program will need to connect to each one of them. The power of dragonfly is that it hides all this complexity. You are saying that comparing single threaded redis to df is unfair, and i say - comparing n redises to df is unfair because you compare different products.

Thank you!

If you see that important command are missing, pks open an issue and we will prioritize their implementation.

Quite a few :) I wish i was 20 again - to have time to learn the language and to implement df in rust :) i am an old with old habits. Btw, I spent a short time coding in rust last year and i understand why the fuzz.

No, we used Redis 6 for all our tests.

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.

Yeah, some call it stupidity... Honestly, it's really irrational thing to do. My last company were good to me but i got the itch...

Wow, its beyond my knowledge:) I use my software skills to write a performant software but rarely i go to the assembly level. And i have zero knowledge about specifics if each command on every architecture. The rare exception is a code in dashtable. the authors of the paper designed it to allow vectorizing of the find() operation.

Those commands wont affect the design of the df, hence they wont affect the performance. Its just work that needs to be done.