【问题标题】:Can consecutive updates to different fields on a row in Cassandra lead to inconsistency?Cassandra中连续更新不同字段会导致不一致吗?
【发布时间】:2017-03-29 21:54:36
【问题描述】:

假设您有一个表,其中的字段(列)用作主(分区)键(假设其名称为“id”),其余字段列是“常规”(无聚类) - 让将它们称为“field1”、“field2”、“field3”、“field4”等。系统中当前存在的逻辑可能会为同一行生成 2 个单独的更新命令。例如:

UPDATE table SET field1='value1' WHERE id='key';
UPDATE table SET field2='value2' WHERE id='key';

这些命令在仲裁中一个接一个地运行。

很少,当您从数据库中检索行(仲裁读取)时,就好像其中一个更新没有发生一样。不一致是否可能是由于这种写入模式造成的,并且可以通过像这样进行一次更新调用来规避:

UPDATE table SET field1='value1',field2='value2' WHERE id='key';

这发生在 Cassandra 2.1.17 上

【问题讨论】:

    标签: cassandra


    【解决方案1】:

    是的,这完全有可能。

    如果你在做这两个语句时需要保留订单,你可以做两件事:

    1. using timestamp 添加到您的查询中并在客户端代码中明确设置 - 这将防止出现不一致
    2. 使用批处理

    【讨论】:

    • 一般来说 - 顺序无关紧要。如果我更新 field1 然后 field2 或 field2 然后 field1 我想得到相同的结果。所以在我看来,这不是关于顺序,而是关于最终的一致性。因此,如果对不同字段的 2 次不同更新可能会失败,但具有 2 次字段更改的更新不会失败 - 很高兴知道这一点。
    • 在这种情况下,要实现强一致性,您需要检查此公式NUM_WRITES + NUM_READ > REPLICATION_FACTOR 基本上您始终必须确保需要响应写入请求和需要响应的节点数对您需要的字段的读取请求大于复制因子。拆分操作不会影响它,除了由于客户端处理而稍微慢一些。
    • 但是如果读写是quorum,那还不够吗?同样,这些是对 2 个单独字段的 2 次更新。
    • 理论上是的,这应该足够了。如果读写都符合法定人数,那应该没问题。请提供您实际用于进行更新的代码。该值也是刚刚设置为某个“旧值”还是未定义。可能是您无意中更新了某些字段。此外,如果读取相对接近第二次更新(毫秒级别),那么节点上的时钟也会启动。我需要更多细节来确定问题的确切来源,但老实说,它开始看起来像 qery 排序问题。
    【解决方案2】:

    我会做的是更改表定义

            CREATE TABLE TABLE_NAME(
          id text,
          field text,
          value text
        PRIMARY KEY( id , field )
    

    这样您就不必担心特定键的字段更新。

    您的查询将是,

            INSERT INTO TABLE_NAME (id , field , value  ) VALUES ('key','fieldname1', 'value1' );
        INSERT INTO TABLE_NAME (id , field , value  ) VALUES ('key','fieldname2', 'value2' );
    

    设计的缺点是,如果你有太多的'key'数据,它会创建宽行。

    对于选择查询 -

    SELECT * from TABLE_NAME where id ='key';
    

    在客户端,构建您的对象。

    【讨论】:

      猜你喜欢
      • 2018-08-11
      • 1970-01-01
      • 2013-07-07
      • 2020-09-04
      • 2018-04-21
      • 2015-09-02
      • 1970-01-01
      • 1970-01-01
      • 2023-03-24
      相关资源
      最近更新 更多