Re: [DISCUSS] LWT UPDATE semantics with + and - when null

[Andrés de la Peña]

I think I'd prefer 2), the SQL behaviour. We could also get the convenience
of 3) by adding CQL functions such as "ifNull(column, default)" or
"zeroIfNull(column)", as it's done by other dbs. So we could do things like
"UPDATE ... SET name = zeroIfNull(name) + 42".

On Wed, 31 Aug 2022 at 04:54, Caleb Rackliffe 
wrote:

> Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1
> (depending on the type) in our previous discussion, but for some reason
> didn't bring up the SQL analog :-|
>
> On Tue, Aug 30, 2022 at 5:38 PM Benedict  wrote:
>
>> I’m a bit torn here, as consistency with counters is important. But they
>> are a unique eventually consistent data type, and I am inclined to default
>> standard numeric types to behave as SQL does, since they write a new value
>> rather than a “delta”
>>
>> It is far from optimal to have divergent behaviours, but also suboptimal
>> to diverge from relational algebra, and probably special casing counters is
>> the least bad outcome IMO.
>>
>>
>> On 30 Aug 2022, at 22:52, David Capwell  wrote:
>>
>> 
>> 4.1 added the ability for LWT to support "UPDATE ... SET name = name +
>> 42", but we never really fleshed out with the larger community what the
>> semantics should be in the case where the column or row are NULL; I opened
>> up https://issues.apache.org/jira/browse/CASSANDRA-17857 for this issue.
>>
>> As I see it there are 3 possible outcomes:
>> 1) fail the query
>> 2) null + 42 = null (matches SQL)
>> 3) null + 42 == 0 + 42 = 42 (matches counters)
>>
>> In SQL you get NULL (option 2), but CQL counters treat NULL as 0 (option
>> 3) meaning we already do not match SQL (though counters are not a standard
>> SQL type so might not be applicable).  Personally I lean towards option 3
>> as the "zero" for addition and subtraction is 0 (1 for multiplication and
>> division).
>>
>> So looking for feedback so we can update in CASSANDRA-17857 before 4.1
>> release.
>>
>>
>>

Re: [DISCUSS] CEP-20: Dynamic Data Masking

[Claude Warren via dev]

Is there enough support here for VIEWS to be the implementation strategy 
for displaying masking functions?


It seems to me the view would have to store the query and apply a where 
clause to it, so the same PK would be in play.


It has data leaking properties.

It has more use cases as it can be used to

 * construct views that filter out sensitive columns
 * apply transforms to convert units of measure

Are there more thoughts along this line?

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

[Claude Warren via dev]

I like this approach.  However, in light of some of the discussions on 
view and the like perhaps the function is  (column value as returned by 
select ) + 42


So a null counter column becomes 0 before the update calculation is applied.

Then any null can be considered null unless addressed by IfNull(), or 
zeroIfNull()


Any operation on null returns null.

I think this follows what would be expected by most users in most cases.


On 31/08/2022 11:55, Andrés de la Peña wrote:
I think I'd prefer 2), the SQL behaviour. We could also get the 
convenience of 3) by adding CQL functions such as "ifNull(column, 
default)" or "zeroIfNull(column)", as it's done by other dbs. So we 
could do things like "UPDATE ... SET name = zeroIfNull(name) + 42".


On Wed, 31 Aug 2022 at 04:54, Caleb Rackliffe 
 wrote:


Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" /
0 / 1 (depending on the type) in our previous discussion, but for
some reason didn't bring up the SQL analog :-|

On Tue, Aug 30, 2022 at 5:38 PM Benedict  wrote:

I’m a bit torn here, as consistency with counters is
important. But they are a unique eventually consistent data
type, and I am inclined to default standard numeric types to
behave as SQL does, since they write a new value rather than a
“delta”

It is far from optimal to have divergent behaviours, but also
suboptimal to diverge from relational algebra, and probably
special casing counters is the least bad outcome IMO.



On 30 Aug 2022, at 22:52, David Capwell 
wrote:


4.1 added the ability for LWT to support "UPDATE ... SET name
= name + 42", but we never really fleshed out with the larger
community what the semantics should be in the case where the
column or row are NULL; I opened up
https://issues.apache.org/jira/browse/CASSANDRA-17857 for
this issue.

As I see it there are 3 possible outcomes:
1) fail the query
2) null + 42 = null (matches SQL)
3) null + 42 == 0 + 42 = 42 (matches counters)

In SQL you get NULL (option 2), but CQL counters treat NULL
as 0 (option 3) meaning we already do not match SQL (though
counters are not a standard SQL type so might not be
applicable).  Personally I lean towards option 3 as the
"zero" for addition and subtraction is 0 (1 for
multiplication and division).

So looking for feedback so we can update in CASSANDRA-17857
before 4.1 release.

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

[Ekaterina Dimitrova]

I am also +1 to match SQL, option 2. Also, I like Andres’ suggestion

On Wed, 31 Aug 2022 at 7:15, Claude Warren via dev 
wrote:

> I like this approach.  However, in light of some of the discussions on
> view and the like perhaps the function is  (column value as returned by
> select ) + 42
>
> So a null counter column becomes 0 before the update calculation is
> applied.
>
> Then any null can be considered null unless addressed by IfNull(), or
> zeroIfNull()
>
> Any operation on null returns null.
>
> I think this follows what would be expected by most users in most cases.
>
>
> On 31/08/2022 11:55, Andrés de la Peña wrote:
>
> I think I'd prefer 2), the SQL behaviour. We could also get the
> convenience of 3) by adding CQL functions such as "ifNull(column, default)"
> or "zeroIfNull(column)", as it's done by other dbs. So we could do things
> like "UPDATE ... SET name = zeroIfNull(name) + 42".
>
> On Wed, 31 Aug 2022 at 04:54, Caleb Rackliffe 
> wrote:
>
>> Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1
>> (depending on the type) in our previous discussion, but for some reason
>> didn't bring up the SQL analog :-|
>>
>> On Tue, Aug 30, 2022 at 5:38 PM Benedict  wrote:
>>
>>> I’m a bit torn here, as consistency with counters is important. But they
>>> are a unique eventually consistent data type, and I am inclined to default
>>> standard numeric types to behave as SQL does, since they write a new value
>>> rather than a “delta”
>>>
>>> It is far from optimal to have divergent behaviours, but also suboptimal
>>> to diverge from relational algebra, and probably special casing counters is
>>> the least bad outcome IMO.
>>>
>>>
>>> On 30 Aug 2022, at 22:52, David Capwell  wrote:
>>>
>>> 
>>> 4.1 added the ability for LWT to support "UPDATE ... SET name = name +
>>> 42", but we never really fleshed out with the larger community what the
>>> semantics should be in the case where the column or row are NULL; I opened
>>> up https://issues.apache.org/jira/browse/CASSANDRA-17857 for this
>>> issue.
>>>
>>> As I see it there are 3 possible outcomes:
>>> 1) fail the query
>>> 2) null + 42 = null (matches SQL)
>>> 3) null + 42 == 0 + 42 = 42 (matches counters)
>>>
>>> In SQL you get NULL (option 2), but CQL counters treat NULL as 0 (option
>>> 3) meaning we already do not match SQL (though counters are not a standard
>>> SQL type so might not be applicable).  Personally I lean towards option 3
>>> as the "zero" for addition and subtraction is 0 (1 for multiplication and
>>> division).
>>>
>>> So looking for feedback so we can update in CASSANDRA-17857 before 4.1
>>> release.
>>>
>>>
>>>

Re: [DISCUSS] CEP-20: Dynamic Data Masking

[Andrés de la Peña]

>
> Is there enough support here for VIEWS to be the implementation strategy
> for displaying masking functions?


I'm not sure that views should be "the" strategy for masking functions. We
have multiple approaches here:

1) CQL functions only. Users can decide to use the masking functions on
their own will. I think most dbs allow this pattern of usage, which is
quite straightforward. Obviously, it doesn't allow admins to decide enforce
users seeing only masked data. Nevertheless, it's still useful for trusted
database users generating masked data that will be consumed by the end
users of the application.

2) Masking functions attached to specific columns. This way the same
queries will see different data (masked or not) depending on the
permissions of the user running the query. It has the advantage of not
requiring to change the queries that users with different permissions run.
The downside is that users would need to query the schema if they need to
know whether a column is masked, unless we change the names of the returned
columns. This is the approach offered by Azure/SQL Server, PostgreSQL, IBM
Db2, Oracle, MariaDB/MaxScale and SnowFlake. All these databases support
applying the masking function to columns on the base table, and some of
them also allow to apply masking to views.

3) Masking functions as part of projected views. This ways users might need
to query the view appropriate for their permissions instead of the base
table. This might mean changing the queries if the masking policy is
changed by the admin. MySQL recommends this approach on a blog entry,
although it's not part of its main documentation for data masking, and the
implementation has security issues. Some of the other databases offering
the approach 2) as their main option also support masking on view columns.

Each approach has its own advantages and limitations, and I don't think we
necessarily have to choose. The CEP proposes implementing 1) and 2), but no
one impedes us to also have 3) if we get to have projected views. However,
I think that projected views is a new general-purpose feature with its own
complexities, so it would deserve its own CEP, if someone is willing to
work on the implementation.



On Wed, 31 Aug 2022 at 12:03, Claude Warren via dev <
dev@cassandra.apache.org> wrote:

> Is there enough support here for VIEWS to be the implementation strategy
> for displaying masking functions?
>
> It seems to me the view would have to store the query and apply a where
> clause to it, so the same PK would be in play.
>
> It has data leaking properties.
>
> It has more use cases as it can be used to
>
>- construct views that filter out sensitive columns
>- apply transforms to convert units of measure
>
> Are there more thoughts along this line?
>

Re: [Marketing] For Review: Performance Benchmarking of Apache Cassandra in the Cloud

[Chris Thornett]

Update: This blog is on hold for additional discussion and amends. Work is
also required to supply filtered links to certain benchmarks referenced
which won't be complete until 2 September. For that reason, revising the
suggested publication date to 6 September, but as it's a public holiday in
the US on 5 Sept it may slip to later in the week.

On Fri, Aug 26, 2022 at 8:08 AM Sharan Foga  wrote:

> Hi Chris
>
> Added a few suggestions (and I see some others have too!). As always
> please feel free to use or ignore as you think.
>
> Thanks
> Sharan
>
> On 2022/08/24 21:35:01 Chris Thornett wrote:
> > Here is Part 1 in a series of 3 on performance benchmarking in Apache
> > Cassandra by Daniel Seybold:
> >
> https://docs.google.com/document/d/1eMFYEOp8lNxZCYelYCWj6jXZ-VaJGNbl2YE3jLWRdOA/edit?usp=sharing
> >
> > We are opening this up for 72-hour community review. Please add your
> amends
> > in the comments—thanks very much!
> >
> > We are looking at 30 August for publication.
> >
> > Thanks,
> > --
> >
> > Chris Thornett
> > Senior Content Strategist, Constantia.io
> >
>

Re: [Marketing] For Review: Learn How CommitLog Works in Apache Cassandra

[Chris Thornett]

Update: Some sections have been flagged by the PMC for further revision.
Author, Alex Sorokoumov will review on 2 September.

Revising publication date to 8 September.

On Fri, Aug 26, 2022 at 11:15 PM Alexander Sorokoumov <
aleksandr.sorokou...@gmail.com> wrote:

> Hey Rhaul,
>
> Thanks for the feedback. I have changed it to just durability (without
> mentioning ACID) to prevent confusion.
>
> Best,
> Alex
>
> On Fri, Aug 26, 2022 at 11:53 PM Rahul Xavier Singh <
> rahul.xavier.si...@gmail.com> wrote:
>
>> Added a comment about "ACID". I would recommend not saying ACID until
>> it's there. C* has strong consistency when needed. It doesn't for example
>> guarantee that two competing mutations will be executed (or be able to be
>> rolled back to the previous state) in the same exact order they were
>> intended if they come in at the same time, especially if these are coming
>> from two different data centers for example.
>>
>> Maybe it can be explained later that the commitlog mechanism provides
>> ACID-like features ... ?
>>
>> From my understanding the Accord white paper has not been implemented
>> into any working Cassandra code. I may be wrong.
>>
>>
>> Rahul Singh
>>
>> Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
>> rahul.si...@anant.us li: http://linkedin.com/in/xingh ca:
>> http://calendly.com/xingh
>>
>> *We create, support, and manage real-time global data & analytics
>> platforms for the modern enterprise.*
>>
>> *Anant | https://anant.us *
>>
>> 3 Washington Circle, Suite 301
>>
>> Washington, D.C. 20037
>>
>> *http://Cassandra.Link * : The best resources
>> for Apache Cassandra
>>
>>
>> On Tue, Aug 23, 2022 at 5:43 AM Sharan Foga  wrote:
>>
>>> Hi Chris
>>>
>>> I've added a few comments and suggestions. Please feel free to use
>>> /ignore whichever ones you think :-)
>>>
>>> Thanks
>>> Sharan
>>>
>>> On 2022/08/23 00:08:52 Chris Thornett wrote:
>>> > Opening up Alex Sorokoumov's guide 'Learn How CommitLog Works in Apache
>>> > Cassandra' for a 72-hr community review by lazy consensus.
>>> >
>>> > Please add any amends and suggestions in the comments:
>>> >
>>> https://docs.google.com/document/d/1cyOi-IeU_I9GBkpQbJS6IIrmemAesEqvzLb-eeFs_rM/edit#
>>> >
>>> > Thanks!
>>> >
>>> > --
>>> >
>>> > Chris Thornett
>>> > Senior Content Strategist, Constantia.io
>>> >
>>>
>>

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

[David Capwell]

Sounds like matching SQL is the current favor, the current patch matches this 
so will leave this thread open a while longer before trying to merge the patch.

> On Aug 31, 2022, at 5:07 AM, Ekaterina Dimitrova  
> wrote:
> 
> I am also +1 to match SQL, option 2. Also, I like Andres’ suggestion
> 
> On Wed, 31 Aug 2022 at 7:15, Claude Warren via dev  > wrote:
> I like this approach.  However, in light of some of the discussions on view 
> and the like perhaps the function is  (column value as returned by select ) + 
> 42
> 
> So a null counter column becomes 0 before the update calculation is applied.
> 
> Then any null can be considered null unless addressed by IfNull(), or 
> zeroIfNull()
> 
> Any operation on null returns null.
> 
> I think this follows what would be expected by most users in most cases.
> 
> 
> On 31/08/2022 11:55, Andrés de la Peña wrote:
>> I think I'd prefer 2), the SQL behaviour. We could also get the convenience 
>> of 3) by adding CQL functions such as "ifNull(column, default)" or 
>> "zeroIfNull(column)", as it's done by other dbs. So we could do things like 
>> "UPDATE ... SET name = zeroIfNull(name) + 42".
>> 
>> On Wed, 31 Aug 2022 at 04:54, Caleb Rackliffe > > wrote:
>> Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1 
>> (depending on the type) in our previous discussion, but for some reason 
>> didn't bring up the SQL analog :-|
>> 
>> On Tue, Aug 30, 2022 at 5:38 PM Benedict > > wrote:
>> I’m a bit torn here, as consistency with counters is important. But they are 
>> a unique eventually consistent data type, and I am inclined to default 
>> standard numeric types to behave as SQL does, since they write a new value 
>> rather than a “delta” 
>> 
>> It is far from optimal to have divergent behaviours, but also suboptimal to 
>> diverge from relational algebra, and probably special casing counters is the 
>> least bad outcome IMO.
>> 
>> 
>>> On 30 Aug 2022, at 22:52, David Capwell >> > wrote:
>>> 
>>> 
>>> 4.1 added the ability for LWT to support "UPDATE ... SET name = name + 42", 
>>> but we never really fleshed out with the larger community what the 
>>> semantics should be in the case where the column or row are NULL; I opened 
>>> up https://issues.apache.org/jira/browse/CASSANDRA-17857 
>>>  for this issue.
>>> 
>>> As I see it there are 3 possible outcomes:
>>> 1) fail the query
>>> 2) null + 42 = null (matches SQL)
>>> 3) null + 42 == 0 + 42 = 42 (matches counters)
>>> 
>>> In SQL you get NULL (option 2), but CQL counters treat NULL as 0 (option 3) 
>>> meaning we already do not match SQL (though counters are not a standard SQL 
>>> type so might not be applicable).  Personally I lean towards option 3 as 
>>> the "zero" for addition and subtraction is 0 (1 for multiplication and 
>>> division).
>>> 
>>> So looking for feedback so we can update in CASSANDRA-17857 before 4.1 
>>> release.
>>> 
>>> 

Re: [DISCUSS] Removing support for java 8

[David Capwell]

+1 to remove from trunk

> On Aug 30, 2022, at 7:54 PM, Caleb Rackliffe  wrote:
> 
> +1 on removing 8 for trunk
> 
> On Tue, Aug 30, 2022 at 2:42 PM Jon Haddad  > wrote:
> +1 to removal of 8 in trunk.
> 
> On 2022/08/29 20:09:55 Blake Eggleston wrote:
> > Hi all, I wanted to propose removing jdk8 support for 4.1. Active support 
> > ended back in March of this year, and I believe the community has built 
> > enough confidence in java 11 to make it an uncontroversial change for our 
> > next major release. Let me know what you think.
> > 
> > Thanks,
> > 
> > Blake

Re: [DISCUSS] LWT UPDATE semantics with + and - when null

[Benjamin Lerer]

 The approach 2) is the one used by CQL operators.
SELECT v + 1 FROM t WHERE pk = 1; Will return null if the row exists but
the v is null.

Le mer. 31 août 2022 à 18:05, David Capwell  a écrit :

> Sounds like matching SQL is the current favor, the current patch matches
> this so will leave this thread open a while longer before trying to merge
> the patch.
>
> On Aug 31, 2022, at 5:07 AM, Ekaterina Dimitrova 
> wrote:
>
> I am also +1 to match SQL, option 2. Also, I like Andres’ suggestion
>
> On Wed, 31 Aug 2022 at 7:15, Claude Warren via dev <
> dev@cassandra.apache.org> wrote:
>
>> I like this approach.  However, in light of some of the discussions on
>> view and the like perhaps the function is  (column value as returned by
>> select ) + 42
>>
>> So a null counter column becomes 0 before the update calculation is
>> applied.
>>
>> Then any null can be considered null unless addressed by IfNull(), or
>> zeroIfNull()
>>
>> Any operation on null returns null.
>>
>> I think this follows what would be expected by most users in most cases.
>>
>>
>> On 31/08/2022 11:55, Andrés de la Peña wrote:
>>
>> I think I'd prefer 2), the SQL behaviour. We could also get the
>> convenience of 3) by adding CQL functions such as "ifNull(column, default)"
>> or "zeroIfNull(column)", as it's done by other dbs. So we could do things
>> like "UPDATE ... SET name = zeroIfNull(name) + 42".
>>
>> On Wed, 31 Aug 2022 at 04:54, Caleb Rackliffe 
>> wrote:
>>
>>> Also +1 on the SQL behavior here. I was uneasy w/ coercing to "" / 0 / 1
>>> (depending on the type) in our previous discussion, but for some reason
>>> didn't bring up the SQL analog :-|
>>>
>>> On Tue, Aug 30, 2022 at 5:38 PM Benedict  wrote:
>>>
 I’m a bit torn here, as consistency with counters is important. But
 they are a unique eventually consistent data type, and I am inclined to
 default standard numeric types to behave as SQL does, since they write a
 new value rather than a “delta”

 It is far from optimal to have divergent behaviours, but also
 suboptimal to diverge from relational algebra, and probably special casing
 counters is the least bad outcome IMO.


 On 30 Aug 2022, at 22:52, David Capwell  wrote:

 
 4.1 added the ability for LWT to support "UPDATE ... SET name = name +
 42", but we never really fleshed out with the larger community what the
 semantics should be in the case where the column or row are NULL; I opened
 up https://issues.apache.org/jira/browse/CASSANDRA-17857 for this
 issue.

 As I see it there are 3 possible outcomes:
 1) fail the query
 2) null + 42 = null (matches SQL)
 3) null + 42 == 0 + 42 = 42 (matches counters)

 In SQL you get NULL (option 2), but CQL counters treat NULL as 0
 (option 3) meaning we already do not match SQL (though counters are not a
 standard SQL type so might not be applicable).  Personally I lean
 towards option 3 as the "zero" for addition and subtraction is 0 (1 for
 multiplication and division).

 So looking for feedback so we can update in CASSANDRA-17857 before 4.1
 release.



>

RE: Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

[Unmesh Joshi]

Hi Sam,

Great to see this CEP. I have been documenting a few common 'patterns of
distributed systems, and have documented a pattern called 'consistent core
'
referring to the source code of various systems which use a linearizable
metadata store. I have also documented patterns like 'lease'

and
'state watch
'
which are commonly used by a consistent core. I also recently documented
how a typical partition assignment and partition movement is implemented in
systems that use a consistent core-based metadata store. (In systems like
YugabyteDb, Cockroachdb, Kafka etc..)
It might be of some use as a quick reference for this CEP to be compared
with others who use similar architecture.
A quick question about using existing Paxos machinery. I see that
implementing a Replicated Log

needs
significant changes, particularly about how two phases of Paxos are
implemented over the entire log. So will it be better to use Raft instead?


Thanks,
Unmesh

On 2022/08/23 08:50:27 Sam Tunnicliffe wrote:
> Thanks!
> The core of the proposal is around the sequencing metadata changes and
ensuring that they're delivered to/processed by nodes in the right order
and at the right time. The actual mechanisms for imposing that order and
for maintaining the log are pretty simple to implement. We envision using
the existing Paxos machinery by default, but swapping that for an
alternative implemention would not be difficult.
>
>
> > On 22 Aug 2022, at 19:14, Derek Chen-Becker 
wrote:
> >
> > This looks really interesting; thanks for putting this together! Just
so I'm clear on CEP nomenclature, having external management of metadata as
a non-goal doesn't preclude some future use, correct? Coincidentally, I'm
working on my ApacheCon talk on improving modularity in Cassandra and one
of the ideas I'm discussing is pluggably (?) replacing gossip with
something(s) that allow us to externalize some of the complexity of
maintaining consistency. I need to digest the proposal you've made, but I
don't see the two ideas being at odds on my first read.
> >
> > Cheers,
> >
> > Derek
> >
> > On Mon, Aug 22, 2022 at 6:45 AM Sam Tunnicliffe > wrote:
> > Hi,
> >
> > I'd like to open discussion about this CEP:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
<
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21:+Transactional+Cluster+Metadata>

> > Cluster metadata in Cassandra comprises a number of disparate elements
including, but not limited to, distributed schema, topology and token
ownership. Following the general design principles of Cassandra, the
mechanisms for coordinating updates to cluster state have favoured eventual
consistency, with probabilisitic delivery via gossip being a prime example.
Undoubtedly, this approach has benefits, not least in terms of resilience,
particularly in highly fluid distributed environments. However, this is not
the reality of most Cassandra deployments, where the total number of nodes
is relatively small (i.e. in the low thousands) and the rate of change
tends to be low.
> >
> > Historically, a significant proportion of issues affecting operators
and users of Cassandra have been due, at least in part, to a lack of
strongly consistent cluster metadata. In response to this, we propose a
design which aims to provide linearizability of metadata changes whilst
ensuring that the effects of those changes are made visible to all nodes in
a strongly consistent manner. At its core, it is also pluggable, enabling
Cassandra-derived projects to supply their own implementations if desired.
> >
> > In addition to the CEP document itself, we aim to publish a working
prototype of the proposed design. Obviously, this does not implement the
entire proposal and there are several parts which remain only partially
complete. It does include the core of the system, including a good deal of
test infrastructure, so may serve as both illustration of the design and a
starting point for real implementation.
> >
> >
> >
> > --
> > +---+
> > | Derek Chen-Becker |
> > | GPG Key available at https://keybase.io/dchenbecker <
https://keybase.io/dchenbecker> and |
> > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org <
https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org> |
> > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC |
> > +---+
> >
>
>

Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

[Alex Petrov]

> I see that implementing a Replicated Log 
> 
>  needs significant changes, particularly about how two phases of Paxos are 
> implemented over the entire log. So will it be better to use Raft instead?

There will be no changes required to our existing Paxos implementation. We can 
just use it. Besides, Paxos is only used as K-sequencer. There is no need to 
use Raft, and both existing LWTs (with Multi-Paxos) and Accord aren't tied to a 
single leader, which is well in the spirit of Cassandra.

> It might be of some use as a quick reference for this CEP to be compared with 
> others who use similar architecture.

I think introducing additional references to CEP may make it more difficult to 
navigate, but of course people can refer to from the mailing list discussion if 
they find it helpful. Many of the things described in CEP are 
Cassandra-specific, and describe not what you have referred to as "consistent 
store" but rather how it integrates Cassandra. The rest of the terms, I 
believe, are common knowledge. But even then, there are very few distributed 
systems concepts mentioned in the CEP.  We have strived to make the document 
self-contained. While some of the concepts are introduced slightly 
out-of-order, this was done deliberately, as we were searching for the best 
logical sequencing.

-- Alex

On Thu, Sep 1, 2022, at 6:14 AM, Unmesh Joshi wrote:
> Hi Sam,
> 
> Great to see this CEP. I have been documenting a few common 'patterns of 
> distributed systems, and have documented a pattern called 'consistent core 
> '
>  referring to the source code of various systems which use a linearizable 
> metadata store. I have also documented patterns like 'lease' 
> 
>  and 'state watch 
> '
>  which are commonly used by a consistent core. I also recently documented how 
> a typical partition assignment and partition movement is implemented in 
> systems that use a consistent core-based metadata store. (In systems like 
> YugabyteDb, Cockroachdb, Kafka etc..)
> It might be of some use as a quick reference for this CEP to be compared with 
> others who use similar architecture.
> A quick question about using existing Paxos machinery. I see that 
> implementing a Replicated Log 
> 
>  needs significant changes, particularly about how two phases of Paxos are 
> implemented over the entire log. So will it be better to use Raft instead?
> 
> 
> Thanks,
> Unmesh
> 
> On 2022/08/23 08:50:27 Sam Tunnicliffe wrote:
> > Thanks! 
> > The core of the proposal is around the sequencing metadata changes and 
> > ensuring that they're delivered to/processed by nodes in the right order 
> > and at the right time. The actual mechanisms for imposing that order and 
> > for maintaining the log are pretty simple to implement. We envision using 
> > the existing Paxos machinery by default, but swapping that for an 
> > alternative implemention would not be difficult.
> > 
> > 
> > > On 22 Aug 2022, at 19:14, Derek Chen-Becker  wrote:
> > > 
> > > This looks really interesting; thanks for putting this together! Just so 
> > > I'm clear on CEP nomenclature, having external management of metadata as 
> > > a non-goal doesn't preclude some future use, correct? Coincidentally, I'm 
> > > working on my ApacheCon talk on improving modularity in Cassandra and one 
> > > of the ideas I'm discussing is pluggably (?) replacing gossip with 
> > > something(s) that allow us to externalize some of the complexity of 
> > > maintaining consistency. I need to digest the proposal you've made, but I 
> > > don't see the two ideas being at odds on my first read. 
> > > 
> > > Cheers,
> > > 
> > > Derek
> > > 
> > > On Mon, Aug 22, 2022 at 6:45 AM Sam Tunnicliffe  > > > wrote:
> > > Hi,
> > > 
> > > I'd like to open discussion about this CEP: 
> > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
> > >  
> > > 
> > >  
> > > Cluster metadata in Cassandra comprises a number of disparate elements 
> > > including, but not limited to, distributed schema, topology and token 
> > > ownership. Following the general design principles of Cassandra, the 
> > > mechanisms for coordinating updates to cluster state have favoured 
> > > eventual consistency, with probabilisitic delivery via gossip being a 
> > > prime example. Undoubtedly, this approach has benefits, not least in 
> > > terms of resilience, particularly in highly fluid distributed