简体繁体 English

设置Cassandra DDL的一致性级别

[英]SET consistency level for Cassandra DDL

原文 2016-12-20 18:03:20 9 2 cassandra/ datastax/ spring-data-cassandra

In my application logs I've seen that, by default, after running create/alter table statements, cassandra driver seems to do processing to bring schema into agreement for up to 10 seconds. 在我的应用程序日志中，我已经看到，默认情况下，在运行create / alter table语句之后，cassandra驱动程序似乎进行处理以使模式达成协议最多10秒。

Can I (and should I) set a consistency level for example 'quorum' while executing DDL statements like 'Create Table .. IF NOT EXISTS' to make sure my table gets created and propagated to all nodes? 我可以（并且应该）在执行DDL语句时设置一致性级别，例如'quorum'，例如'Create Table .. IF NOT EXISTS'以确保我的表被创建并传播到所有节点？

2 个解决方案

Changing the Consistency Level does not affect how long the cluster takes to come into agreement. 更改一致性级别不会影响群集达成协议所需的时间。 If this is taking 10 seconds on your cluster your client may simply be hitting the default timeout instead of fully waiting for all nodes to come into agreement. 如果您的群集需要10秒钟，您的客户端可能只是达到默认超时而不是完全等待所有节点达成协议。 Check the Java Driver docs for more information on this process. 有关此过程的更多信息，请查看Java驱动程序文档。

Outside of your application you can check the schema state with nodetool describecluster . 在应用程序之外，您可以使用nodetool describecluster检查架构状态。 This will show you if a particular node is not accepting changes to the schema. 这将显示特定节点是否不接受对架构的更改。 Here's some more information on resolving schema disagreements from an Operators perspective. 以下是有关从Operators角度解决模式分歧的更多信息。

Schema changes (data definition) in Cassandra since 1.1+ are done via gossip . 自1.1+以来，Cassandra中的模式更改（数据定义）是通过八卦完成的。 Since it uses Gossip, it is a separate read/write path than your typical data manipulation requests (SELECT, DELETE, INSERT, etc), and hence has no tunable consistency for such operations, since gossip doesn't operate with tunable consistency. 由于它使用Gossip，因此它是一个独立的读/写路径，而不是典型的数据操作请求（SELECT，DELETE，INSERT等），因此对于此类操作没有可调整的一致性，因为八卦不能以可调整的一致性运行。 From the article I linked, you can see that schema changes are passively announced in the cluster, and furthermore you can get schema disagreement/resolution when you have nodes that were unreachable when the schema change was made. 从我链接的文章中，您可以看到在集群中被动地宣布模式更改，而且当您具有在进行模式更改时无法访问的节点时，您可以获得模式不一致/解决方案。

How often are you modifying your schema? 您多久修改一次架构？ As you can see schema changes, while vastly improved from what it used to be, is still a very expensive operation as every node has to become consistent. 正如您所看到的那样，虽然每个节点都必须保持一致，但仍然是一个非常昂贵的操作，因为您可以看到架构更改。 Frequent schema changes in Cassandra should be avoided (aka dynamic columns) for this reason. 出于这个原因，应该避免Cassandra中频繁的模式更改（也就是动态列）。 I would be curious to hear how often and why the schema is being change, perhaps you could remodel to avoid dynamic columns/tables to avoid expensive schema changes in Cassandra. 我很想知道模式的更改频率和原因，也许您可以重新构建以避免动态列/表以避免在Cassandra中进行昂贵的模式更改。