To me that sounds like a completely different design pattern and a different use case. CS was not designed to guarantee order. It was build to be linear scalable, highly concurrent and eventual consistent. To me it sounds like a ACID DB better serves what you are asking for.
2017-02-21 10:17 GMT+01:00 Kant Kodali <k...@peernova.com>: > Agreed that async performs better than sync in general but the catch here > to me is the "order". > > The whole point of async is to do out of order processing by which I mean > say if a request 1 comes in at time t1 and a request 2 comes in at time t2 > where t1 < t2 and say now that t1 is taking longer to process than t2 in > which case request 2 should get a response first and subsequently a > response for request 1. This is where I would imagine all the benefits of > async come in but the moment you introduce order by saying for Last Write > Wins all the async requests should be processed in order I would imagine > all the benefits of async are lost. > > Let's see if anyone can comment about how it works inside C*. > > Thanks! > > > > On Mon, Feb 20, 2017 at 10:54 PM, Dor Laor <d...@scylladb.com> wrote: > >> Could be. Let's stay tuned to see if someone else pick it up. >> Anyway, if it's synchronous, you'll have a large penalty for latency. >> >> On Mon, Feb 20, 2017 at 10:11 PM, Kant Kodali <k...@peernova.com> wrote: >> >>> Thanks again for the response! if they mean it between client and server >>> I am not sure why they would use the word "replication" in the statement >>> below since there is no replication between client and server( coordinator). >>> >>> "Choose between synchronous or asynchronous replication for each update >>>> ." >>>> >>> >>> Sent from my iPhone >>> >>> On Feb 20, 2017, at 5:30 PM, Dor Laor <d...@scylladb.com> wrote: >>> >>> I think they mean the client to server and not among the servers >>> >>> On Mon, Feb 20, 2017 at 5:28 PM, Kant Kodali <k...@peernova.com> wrote: >>> >>>> Also here is a statement from C* website >>>> >>>> "Choose between synchronous or asynchronous replication for each update >>>> ." >>>> >>>> http://cassandra.apache.org/ >>>> >>>> Looks like we can choose then either sync or async then? >>>> >>>> On Mon, Feb 20, 2017 at 5:25 PM, Kant Kodali <k...@peernova.com> wrote: >>>> >>>>> Hi Dor, >>>>> >>>>> Great response! My comments are inline. >>>>> >>>>> Thanks a lot, >>>>> kant >>>>> >>>>> >>>>> On Mon, Feb 20, 2017 at 4:41 PM, Dor Laor <d...@scylladb.com> wrote: >>>>> >>>>>> I sent this answer but it bounced off the user@apache. >>>>>> Here is the email anyway: >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Dor Laor <d...@scylladb.com> >>>>>> Date: Mon, Feb 20, 2017 at 4:37 PM >>>>>> Subject: Re: Does C* coordinator writes to replicas in same order or >>>>>> different order? >>>>>> To: d...@cassandra.apache.org >>>>>> Cc: user@cassandra.apache.org >>>>>> >>>>>> >>>>>> + The C* coordinator send async write requests to the replicas. >>>>>> This is very important since it allows it to return a low latency >>>>>> reply to the client once the CL is reached. You wouldn't want >>>>>> to serialize the replicas one after the other. >>>>>> >>>>> >>>>> *so coordinator wont wait until a CL is reached before it >>>>> process another request? * >>>>> >>>>>> >>>>>> + The client <-> server sync/async isn't related to the coordinator >>>>>> in this case. >>>>>> >>>>>> + In the case of concurrent writes (always the case...), the time >>>>>> stamp >>>>>> sets the order. Note that it's possible to work with client >>>>>> timestamps or >>>>>> server timestamps. The client ones are usually the best choice. >>>>>> >>>>> >>>>> *In theory, Why we say concurrent writes they should have the same >>>>> timestamp right? What I am really looking for is that if I send write >>>>> request concurrently for record 1 and record 2 are they guaranteed to be >>>>> inserted in the same order across replicas? (Whatever order coordinator >>>>> may >>>>> choose is fine but I want the same order across all replicas and with >>>>> async >>>>> replication I am not sure how that is possible ? for example, if a >>>>> request >>>>> arrives with timestamp t1 and another request arrives with a timestamp t2 >>>>> where t1 < t2...with async replication what if one replica chooses to >>>>> execute t2 first and then t1 simply because t1 is slow while another >>>>> replica choose to execute t1 first and then t2..how would that work? )* >>>>> >>>>>> >>>>>> Note that C* each node can be a coordinator (one per request) and its >>>>>> the desired case in order to load balance the incoming requests. Once >>>>>> again, >>>>>> timestamps determine the order among the requests. >>>>>> >>>>>> Cheers, >>>>>> Dor >>>>>> >>>>>> On Mon, Feb 20, 2017 at 4:12 PM, Kant Kodali <k...@peernova.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> when C* coordinator writes to replicas does it write it in same >>>>>>> order or >>>>>>> different order? other words, Does the replication happen >>>>>>> synchronously or >>>>>>> asynchrnoulsy ? Also does this depend sync or async client? What >>>>>>> happens in >>>>>>> the case of concurrent writes to a coordinator ? >>>>>>> >>>>>>> Thanks, >>>>>>> kant >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- Benjamin Roth Prokurist Jaumo GmbH · www.jaumo.com Wehrstraße 46 · 73035 Göppingen · Germany Phone +49 7161 304880-6 · Fax +49 7161 304880-1 AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
