2

Cassandra が自分のアプリケーションにどの程度適しているかを判断しようとしています。将来的にどの程度のスケーリングが必要になるかは不明であり、急速に発生する可能性があります。私は C* Summit 2013 のさまざまなセグメントを見てきました。

具体的には、Spotify のバックエンド開発者である Axel Liljencrantz 氏は、モデルで同じ行を何度も更新する必要がある場合、時間の経過とともに Cassandra のパフォーマンスが低下することが予想されると 述べています。

私のモデル要件は、さまざまな実際の要件/ステータス ポイントを満たすため、値が数か月にわたって変化する、既知のフィールドを持つ "ドキュメント ストア" のようなタイプです。保存されているさまざまな種類のドキュメントに対して、さまざまなクエリとカウントを実行する必要があります。

したがって、すべてのドキュメントが通常、修正された履歴データのままになるまでの既知の平均寿命が同じである場合、これを軽減する適切な方法はありますか?

バージョン番号を保存し、情報が更新されたときにドキュメント全体を新しい行に書き換えることで、これを回避するのは考えにくいですか?

4

1 に答える 1

10

モデルで同じ行を何度も更新する必要がある場合、時間の経過とともに Cassandra のパフォーマンスが低下することが予想されます。

--> これは、同じ行が数十の SSTable にまたがっているためです (SizeTiered Compaction)。それを軽減できる Cassandra で利用可能な新しい Leveled Compaction があります。詳細はこちら

私のモデル要件は、さまざまな現実の要件/ステータス ポイントを満たすため、値が数か月にわたって変化する、既知のフィールドを持つ "ドキュメント ストア" のようなタイプです。

ドキュメントに「既知のフィールド」がある場合、テーブルごとに決まった量の「列」があります。更新は頻繁に行われますが、これは「widerow」ではないため、問題ではありません (上記のように Leveled Compaction を選択した場合)。

通常、すべてのドキュメントが修正されたままになるまでの既知の平均寿命が同じである場合

ドキュメントが最終的な不変バージョンの数か月前に非常に頻繁に変更される場合は、頻繁な更新をサポートするように構成された列ファミリーに最初に保存できます。それらが最終的になった後、安定して読み取り効率が高くなるように構成された別の列ファミリーにそれらを移動します

于 2013-09-15T11:27:32.113 に答える