Кассандра: счетчик для НЕКОТОРЫХ ключей не увеличен?

У меня есть очень простая таблица Cassandra под названием campaignvariantaction со столбцом счетчика под названием val. Сегодня столкнулся с очень странной проблемой. Для некоторых ключей Cassandra просто увеличивает счетчик. Для других это просто не работает. Я очень смущен, как это может быть.

Пример вывода Cassandra Shell (cqlsh) приведен ниже. Обратите внимание, что увеличение счетчика отлично работает для одного ключа (первые 3 примера) и не работает для другого (последний пример).

Cassandra версии 2.2.7 на Ubuntu.

cqlsh:z> UPDATE campaignvariantaction SET val = val + 1 WHERE campaignvariantaction = 'campaign_variant#54408#sent' AND date = 20161118;
cqlsh:z> select * from campaignvariantaction where campaignvariantaction = 'campaign_variant#54408#sent';

 campaignvariantaction             | date     | val
-----------------------------------+----------+-----
 campaign_variant#54408#sent | 20161118 |   1

(1 rows)
cqlsh:z> UPDATE campaignvariantaction SET val = val + 1 WHERE campaignvariantaction = 'campaign_variant#54408#sent' AND date = 20161118;
cqlsh:z> select * from campaignvariantaction where campaignvariantaction = 'campaign_variant#54408#sent';

 campaignvariantaction             | date     | val
-----------------------------------+----------+-----
 campaign_variant#54408#sent | 20161118 |   2

(1 rows)

    cqlsh:z> UPDATE campaignvariantaction SET val = val + 1 WHERE campaignvariantaction = 'campaign_variant#979165#sent' AND date = 20161118;
    cqlsh:z> select * from campaignvariantaction where campaignvariantaction = 'campaign_variant#979165#sent';

     campaignvariantaction | date | val
    -----------------------+------+-----

    (0 rows)

Опишите вывод:

cqlsh:z> describe table campaignvariantaction ;

CREATE TABLE z.campaignvariantaction (
    campaignvariantaction text,
    date int,
    val counter,
    PRIMARY KEY (campaignvariantaction, date)
) WITH CLUSTERING ORDER BY (date ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

person Alex Weinstein    schedule 18.11.2016    source источник
comment
Вы выполнили операцию удаления для этой таблицы с параметром кампании variantaction = 'campaign_variant#979165#sent' AND date = 20161118 ? Только тогда он не будет увеличиваться   -  person Ashraful Islam    schedule 18.11.2016
comment
stackoverflow.com/questions/13653681/   -  person Ashraful Islam    schedule 18.11.2016
comment
Оказывается, проблема была устранена путем простого обновления Cassandra — в последней версии (3.9) этой проблемы не было. Так что похоже на внутренний баг.   -  person Alex Weinstein    schedule 18.11.2016