問題タブ [tombstone]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1389 参照

visual-studio-2010 - エラー「Newtonsoft.Json.Linq.JToken」はTombstoneHelperを使用してシリアル化できません

アプリの特定のページが墓石から復元されないという問題が発生しました。アプリにアクセスしようとすると、ホーム画面に戻されます。

デバッグ中に3行がコンソールに記録されました。

  • タイプの最初のチャンスの例外がSystem.Runtime.Serialization.InvalidDataContractException発生しましたSystem.Runtime.Serialization.dll
  • タイプの最初のチャンスの例外がSystem.Reflection.TargetInvocationException発生しましたmscorlib.dll
  • タイプの最初のチャンスの例外がSystem.Runtime.Serialization.InvalidDataContractException発生しましたSystem.Runtime.Serialization.dll

e.ExceptionObject.Message.ToString()次に、このエラーを調べて確認しました。

"Type 'Newtonsoft.Json.Linq.JToken' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute."

私はそのページのcsコードでいくつかJObjectsを使用しています。JTokens私は特にリストボックスのバインディング値をそれらからの値に設定していますJObjects

次にコードで:

墓石のために、私はこれをしているだけです:

墓石を作って生き残るために、私が違ったやり方でやるべきことはありますか?

0 投票する
1 に答える
1379 参照

cassandra - Cassandra 1.2.6で「トゥームストーン圧縮」を生成するにはどうすればよいですか

墓石圧縮について

cassandra1.2.6 で「トゥームストーンの圧縮」ができない理由を知りたいです。

【歩数】

  1. cassandra-cli で列ファミリーを作成する

    create keyspace keyspace1 with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options = {replication_factor:3};

    use keyspace1;

    create column family cf1 with comparator=AsciiType and default_validation_class=AsciiType and key_validation_class=AsciiType and compaction_strategy_options={tombstone_compaction_interval: 1, tombstone_threshold: '0.1'} and gc_grace=600 and column_metadata=[ {column_name: column1, validation_class: LongType} ];

  2. 次のように、cassandra-cli で TTL を使用していくつかのデータを入力します。

    set cf1['key1']['column1']=100 with ttl = 1;
    set cf1['key2']['column1']=200 with ttl = 1;
    set cf1['key3']['column1']=300 with ttl = 1;
    set cf1['key4']['column1']=400 with ttl = 600;
    set cf1['key5']['column1']=500 with ttl = 600;
    set cf1['key6']['column1']=600 with ttl = 600;

  3. 「nodetool フラッシュ」を実行します

  4. sstable2jsonでData.dbをチェック

    {"key": "2412441","columns": [["column1","100",1373516242953000,"d"]]},
    {"key": "2412442","columns": [["column1","200",1373516242963000,"d"]]},
    {"key": "2412443","columns": [["column1","300",1373516242973000,"d"]]},
    {"key": "2412444","columns": [["column1","400",1373516242983000,"e",600,1373516300]]},
    {"key": "2412445","columns": [["column1","500",1373516242983000,"e",600,1373516300]]},
    {"key": "2412446","columns": [["column1","600",1373516242983000,"e",600,1373516300]]}

  5. 1時間以上待ちます....Data.dbに変更はありません....トゥームストーンの圧縮は行われませんでした...

  6. いくつかのデータを入力して、nodetool flush を再度実行します...ちょうど新しい Data.db が作成されました... tombstone の圧縮は生成されませんでした...

「墓石の圧縮」を試してみたいと思います。

0 投票する
1 に答える
407 参照

cassandra - 予測可能な Cassandra 行の削除

1.2.5 の Cassandra クラスターに書き込み負荷の高いワークフローがあります。ディスク容量が限られているため、古いデータを時々削除する必要があります。この削除は、ディスクの空き容量が特定のレベルまで低下したときに開始されます。トゥームストーンの役割を学びました。つまり、トゥームストーンは gc_grace タイムアウトが期限切れになり、マイナー圧縮が進行中のときに削除されます。そのため、「忍耐の遅延」を設定し、期限が切れると、ディスクの空き容量を再度確認できます。

しかし、「マイナーな圧縮がいつか実行されるかもしれない」ということに頼ることができないため、より予測可能な削除スキームが必要です。これはあまり具体的ではないように思われるため、いつディスクの空き容量を再度確認する必要があるかわかりません。たぶん、あなたはいくつかのアイデアを提供することができます。

0 投票する
1 に答える
176 参照

cassandra - Cassandra でのスタンドアロンの圧縮

私は Cassandra にかなり慣れていないので、この質問が価値がないと思われる場合は申し訳ありません。

cassandra(1.2.5) クラスターの動作をテストしようとしています。そのため、列 ttl を 1 日に設定しました。1日後、データが利用できないことを確認できましたが、デフォルトのtombstone_threshold、つまり20%を使用しているときに、スタンドアロンの圧縮が行われ、墓石が占めるスペースを掃除していることを確認したいと思います.

だから私の質問は - スタンドアロンの圧縮が行われていることを確認する方法は? プロセスで解放されるディスク容量のサイズを知る方法はありますか。圧縮タイプと圧縮によって行われた作業について読み取ったログはありますか?

0 投票する
2 に答える
3071 参照

performance - 大きなデータ バンドルを削除した後、Cassandra ルックアップ クエリが非常に遅くなる

現在、100,000 を超える大量のデータ行を持つ cassandra 列ファミリがあります。ここで、この列ファミリーのすべてのデータを削除したいのですが、問題が発生しました:

すべてのデータが削除された後、この列ファミリーで検索クエリを実行すると、cassandra が空のクエリ結果を返すのに数十秒かかります。また、元のデータが大きいほど、時間コストは直線的に増加します

これは、Cassandra データベースからデータを削除する際のトゥームストーン機能が原因です。ルックアップ速度は、次の GC が起動されるまで通常に回復しません。Cassandra Distributed Deletesを参照してください。

私のシステムではこのようなクエリ操作が頻繁に使用されるため、最大数秒の巨大な遅延に耐えられません。

この問題の解決策を教えてください。

0 投票する
2 に答える
18013 参照

cassandra - トゥームストーンの制限に達したときの正確な動作

cassandra のログ (以下を参照) によると、存在するクエリが多すぎるため、クエリが中止されてtombstonesいます。これは、週に 1 回、カウンターが低すぎる行をクリーンアップ (削除) するために発生しています。これにより、数十万行が「削除」されます(そのようにtombstone. でマークされます)。

クリーンアップ プロセス中にノードがダウンしたために、このテーブルで削除された行が再表示されてもまったく問題はないので、gc grace time影響を受ける単一のテーブルの時間を 10 時間 (デフォルトの 10 日から短縮) に設定しました。廃棄された行は、比較的高速に完全に削除される可能性があります。

とにかく、tombstone_failure_threshold以下の例外を避けるために非常に高く設定する必要がありました. (10 万から 1 億に増加) 私の質問は、これは必要ですか? どのタイプのクエリが中止されるかはまったくわかりません。挿入、選択、削除?

一部の選択が中止されただけであれば、それほど大きな問題ではありません。しかし、それは、クエリが時期尚早に停止し、あまりにも多くの墓石が見つかる前に収集できたライブデータを返すという点で、中止が「制限付き」を意味すると想定しています。

もっと簡単に言うと、tombstone_failure_thresholdを超えるとどうなりますか?

言及するのを忘れました。Cassandra バージョンの実行2.0.4