Lazy DEL and FLUSH*

[Salvatore Sanfilippo]

Hi all,

not everybody is on Twitter, so I think it's worth to post this here:

http://antirez.com/news/93

Feedbacks welcomed,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com

"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.

[ddorian43]

What do you think for redis to go on the ~direction of voltdb / scylladb, basically partitioning on each core?

[Josiah Carlson]

That is already possible with Redis Cluster.

 - Josiah

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

[ddorian43]

That was available even before cluster, but it's not the same thing. The cluster isn't even cp or ap.
And this way, you can even implement transactions?(slower) with synchronizing on the threads.

On Saturday, September 26, 2015 at 12:05:22 PM UTC+2, Salvatore Sanfilippo wrote:

[Josiah Carlson]

I know it's not the same thing, but when I replied, you hadn't provided any reason for wanting to have Redis running on multiple cores. Being that there is already multiple solutions for getting Redis running on multiple cores (Redis cluster, and indeed, client-side sharding before cluster, whether managed by twemproxy or not, ...), you need to be explicit about what you want to get out of the change.

In this reply, you bring up transactions and synchronizing on threads. What do you *mean* by transactions, and how do you mean to synchronize on threads? Are you talking about transactions that can be rolled back, as I implemented as a proof of concept in the Lua Transactions branch? Applied to MULTI/EXEC on error?

If you want to ask a question and get a meaningful or useful answer, you should provide information and context that would lead to someone understanding what you mean. Because "basically partitioning on each core" and "implement transactions?(slower) with synchronizing on the threads" is effectively meaningless, even in the context of your emails.

So, what do you want? What features? What functionality? What changes? What is going to be the subjective experience of users if Redis is now partitioned on each core? What do you expect to gain?

 - Josiah

--

[ddorian43]

I didn't request any feature, just wanted his opinion on the architecture of those systems, since he has written before that redis will eventually be multithread/multicore.
And I said that this way, you can (not I want) transactions (should've written pipeline) across all the cores (voltdb does transactions across all the cores, but slower than single-core-transactions).

My next question, would be, with multithreading, do you see a possibility of redis-cluster having sync-replication ?

On Saturday, September 26, 2015 at 12:05:22 PM UTC+2, Salvatore Sanfilippo wrote:

[Thomas Love]

Awesome work! That's gone very deep from lazyfree -> threading -> core data organization. "All problems in computer science can be solved by another level of indirection."

Something I don't understand from the writeup (noob to Redis internals and C for that matter, so forgive me): why does robj -> sds_string have indirection in the first place? I see very few static/automatic robj allocations. 

Thomas