Lightweight transaction (paxos) vs double check.

[Wayne Schroeder <ws...@pinsightmedia.com>]

I have to come up with a “event dupe check” system that handles race conditions where two requests come in at the same time.  Obviously this can be solved with lightweight transactions (if not exists), however I am concerned that there may be costs/issues hidden to me for doing significant amounts of LWT such as locks or other contention issues.  If it comes down to pure time and operations, after doing some analysis with tracing, it appears that is actually cheaper (total time and operations wise) to simply do one LWT than implement a check/write/double check and or correct style reconciliation system. 

Are there hidden costs to LWT (paxos) that are not represented in the total time and number of operations?  For example, are there some under-the-hood locks that could cause contention issues when processing significant quantities of LWT under load?

Wayne

Re: Lightweight transaction (paxos) vs double check.

[Robert Coli <rc...@eventbrite.com>]

On Wed, Aug 13, 2014 at 12:28 PM, Wayne Schroeder <
wschroeder@pinsightmedia.com> wrote:

>  Knowing the price would help weigh the consequences of using them
> though.  I just don’t want to implement a check/write/double check solution
> if it ends up being actually more expensive in total operations and time
> than simply using LWT.  Any thoughts in that regard?
>

My understanding is that LWT performance currently degrades over time as
the history list is not effectively compacted away :

https://issues.apache.org/jira/browse/CASSANDRA-7753 (Unresolved; ): "Level
compaction for Paxos table"

This sort of class of issue reflects the general immaturity of LWT,
especially as relates to performance after sustained high volume usage.

My presumption is that LWT will perform in the same order of magnitude as
your check/write/double check solution, but will be slightly less error
prone. Were I in your case and had a hard requirement for this behavior and
to do it in Cassandra, I would performance test LWT robustly and give them
a shot.

=Rob

Re: Lightweight transaction (paxos) vs double check.

[Wayne Schroeder <ws...@pinsightmedia.com>]

Well… I didn’t expect them to be free :)

Knowing the price would help weigh the consequences of using them though.  I just don’t want to implement a check/write/double check solution if it ends up being actually more expensive in total operations and time than simply using LWT.  Any thoughts in that regard?

Wayne


On Aug 13, 2014, at 1:10 PM, Robert Coli <rc...@eventbrite.com>> wrote:

On Wed, Aug 13, 2014 at 9:16 AM, Wayne Schroeder <ws...@pinsightmedia.com>> wrote:
Are there hidden costs to LWT (paxos) that are not represented in the total time and number of operations?  For example, are there some under-the-hood locks that could cause contention issues when processing significant quantities of LWT under load?

"Transactions" are not the sweet spot of a distributed log structured database with immutable datafiles, LWT comes at a significant cost compared to other operations in Cassandra.

Put another way, lunch is still not free. :D

=Rob

Re: Lightweight transaction (paxos) vs double check.

[Robert Coli <rc...@eventbrite.com>]

On Wed, Aug 13, 2014 at 9:16 AM, Wayne Schroeder <
wschroeder@pinsightmedia.com> wrote:

> Are there hidden costs to LWT (paxos) that are not represented in the
> total time and number of operations?  For example, are there some
> under-the-hood locks that could cause contention issues when processing
> significant quantities of LWT under load?
>

"Transactions" are not the sweet spot of a distributed log structured
database with immutable datafiles, LWT comes at a significant cost compared
to other operations in Cassandra.

Put another way, lunch is still not free. :D

=Rob