カサンドラ・テーブル・墓石私はカサンドラとの問題を抱えて0

Question

ではありません。

：

私はnodetool -h 10.169.20.8 cfstats name.name -H

をすれば、私は結果や統計情報を取得するには、このようなものです

Read Count: 0 
    Read Latency: NaN ms. 
    Write Count: 739812 
    Write Latency: 0.038670616318740435 ms. 
    Pending Flushes: 0 
     Table: name 
     SSTable count: 10 
     Space used (live): 1.48 GB 
     Space used (total): 1.48 GB 
     Space used by snapshots (total): 0 bytes 
     Off heap memory used (total): 3.04 MB 
     SSTable Compression Ratio: 0.5047407001982581 
     Number of keys (estimate): 701190 
     Memtable cell count: 22562 
     Memtable data size: 14.12 MB 
     Memtable off heap memory used: 0 bytes 
     Memtable switch count: 7 
     Local read count: 0 
     Local read latency: NaN ms 
     Local write count: 739812 
     Local write latency: 0.043 ms 
     Pending flushes: 0 
     Bloom filter false positives: 0 
     Bloom filter false ratio: 0.00000 
     Bloom filter space used: 2.39 MB 
     Bloom filter off heap memory used: 2.39 MB 
     Index summary off heap memory used: 302.03 KB 
     Compression metadata off heap memory used: 366.3 KB 
     Compacted partition minimum bytes: 87 bytes 
     Compacted partition maximum bytes: 3.22 MB 
     Compacted partition mean bytes: 2.99 KB 
     Average live cells per slice (last five minutes): 1101.2357892212697 
     Maximum live cells per slice (last five minutes): 1109 
     Average tombstones per slice (last five minutes): 271.6848030693603 
     Maximum tombstones per slice (last five minutes): 1109 
     Dropped Mutations: 0 bytes 

なぜ墓石の統計情報が0でないのですか？ここではカサンドラに書き込むだけです。誰もレコードを削除しません。私たちはTTLを使用せず、デフォルト設定に設定されています。

2番目の問題（おそらく問題に関連する） - テーブルの行数がランダムに変化するため、何が起こっているのかわかりません。

Answer 1

墓石を説明する方法があるとは確信が持てません。削除をしていない場合です。

私はあなたにこれを試して分析する2つの方法を提供できます。おそらく、これは飼い主とその方法をよりよく理解するのに役立ちます。

sstable2jsonというツールがある - 次のスキーマ

のための墓石とsstableファイルにsstable2jsonを実行している

cqlsh> describe schema; 

CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true; 

CREATE TABLE test.t1 (
    key text PRIMARY KEY, 
    value text 
) WITH 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'; 

ため例えば

- それはsstableを取り、JSONにそれをダンプすることができますが、完全なパーティションはfolliowing

[ 
{"key": "key", 
"metadata": {"deletionInfo": {"markedForDeleteAt":1475270192779047,"localDeletionTime":1475270192}}, 
"cells": []} 
] 

を提供し、この場合にはmarkjerは、「キー」を使用してパーティションのためです

墓石の数が増えているので、もう1つの方法はtcpdumpを使ってwiresharkで解析することです。 ScyllaDBのBenoit Canetはwiresharkに貢献しました。CQLをサポートしている最新の安定版リリース2.2.0（https://www.wireshark.org/docs/relnotes/wireshark-2.2.0.html）

cqlの削除は、QUERYとPREPAREDの2種類があります。準備されたステートメント）。

プリペアドステートメントで完了した場合は、準備済みステートメントを持つ特定のパケットを確実に捕捉するために、CQL接続を削除する必要があります。ここで

は、上記

Answer 2

N.B.からdelete文をキャプチャwiresharkのからのサンプルであります：準備文にNULLsバインディングを使用して墓碑を作成することがあります。 - http://thelastpickle.com/blog/2016/09/15/Null-bindings-on-prepared-statements-and-undesired-tombstone-creation.html

Answer 3

カラムに値を書き込むと、削除と同じで、墓石が作成されます。 Wait... Say What.