Cassandra-stress更新报错及更新删除压测配置求助

Hey there, let's break down the issue you're hitting with cassandra-stress when running UPDATE operations, and walk through fixes plus tuning tips for your delete/update-heavy workload.

First, a quick typo fix in your table definition: you wrote CLUSTERING ORDER BY (node_time DESC), but your clustering key is my_time—I assume that's a typo, so you'll want to correct that to CLUSTERING ORDER BY (my_time DESC) first to avoid unexpected behavior.

Why You're Getting the "slice restrictions not supported" Error #

Cassandra's CQL rules are strict here: UPDATE (and DELETE) statements require you to specify the full primary key exactly—that means all partition key columns and all clustering columns. You can't use range conditions (like my_time > ?) on clustering columns in these operations, which is what the default cassandra-stress update template is probably trying to do. That's exactly why you're seeing that error.

Fixing the cassandra-stress Profile for UPDATEs #

You'll need to create a custom profile YAML that defines an UPDATE query with the full, exact primary key, and configures the tool to generate values that match rows you've already inserted (since Cassandra treats UPDATEs without existing rows as inserts).

Here's a modified version of your profile tailored for update testing:

table: eventsrawtest
table_definition: |
  CREATE TABLE stresstest.eventsrawtest (
      my_id text,
      my_info text,
      my_date text,
      my_time timestamp,
      my_stats bigint,
      PRIMARY KEY ((my_id, my_info, my_date), my_time)
  ) WITH CLUSTERING ORDER BY (my_time DESC) 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', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 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 = '99PERCENTILE'

queries:
  update:
    cql: "UPDATE stresstest.eventsrawtest SET my_stats = ? WHERE my_id = ? AND my_info = ? AND my_date = ? AND my_time = ?"
    fields:
      # Update the stats column with new values
      - name: my_stats
        population: uniform(1, 1000000)
      # Match the same value ranges you used for INSERT to hit existing rows
      - name: my_id
        population: uniform(1, 10000) # Adjust to match your insert population
      - name: my_info
        population: uniform(1, 100) # Adjust to match your insert population
      - name: my_date
        population: uniform('2024-01-01', '2024-12-31') # Adjust to match your insert population
      - name: my_time
        population: sequential(1609459200000, 1735689600000, 1000) # Generate timestamps that exist in your inserted data

To run the update stress test, use this command:

cassandra-stress user profile=your_profile.yaml ops'(update=1)' -node <your_cassandra_node_ip>

Configuring for DELETE Operations #

The logic for DELETE is identical—you need to specify the full primary key. Add this to your profile's queries section:

delete:
    cql: "DELETE FROM stresstest.eventsrawtest WHERE my_id = ? AND my_info = ? AND my_date = ? AND my_time = ?"
    fields:
      - name: my_id
        population: uniform(1, 10000)
      - name: my_info
        population: uniform(1, 100)
      - name: my_date
        population: uniform('2024-01-01', '2024-12-31')
      - name: my_time
        population: sequential(1609459200000, 1735689600000, 1000)

Run the delete test with:

cassandra-stress user profile=your_profile.yaml ops'(delete=1)' -node <your_cassandra_node_ip>

Tuning Tips for Update/Delete-Heavy Clusters #

Since your workload is focused on updates and deletes, here are key cluster tweaks:

• Compaction Strategy: Switch to LeveledCompactionStrategy (LCS) instead of STCS. LCS handles frequent updates/deletes better by minimizing tombstone accumulation and keeping hot data in smaller, more manageable sstables.
• GC Grace Seconds: If you don't need to account for long node outages, reduce gc_grace_seconds (e.g., to 86400 for 1 day) to speed up tombstone cleanup. Just ensure your cluster's repair frequency is shorter than this value.
• Memtable Settings: For high update rates, consider setting memtable_allocation_type: heap_buffers to reduce garbage collection pressure. You can also adjust memtable_flush_period_in_ms to control how often memtables are flushed to disk.
• Tombstone Thresholds: Monitor tombstone counts with nodetool tablestats, and adjust tombstone_warn_threshold and tombstone_failure_threshold in cassandra.yaml if needed to avoid query failures from too many tombstones.
• Read Repair: If your workload has frequent updates across nodes, tweak dclocal_read_repair_chance (e.g., to 0.2) to ensure consistent reads without overloading the cluster.

内容的提问来源于stack exchange，提问作者mxm