Cassandraやその他のNoSQLデータベースの永続性の詳細については、NoSQLとは何かをチェックしてください。
永続性の意味を理解することは、さまざまなデータストアシステムを評価する上で重要です。 最新のほとんどのアプリケーションでは、データストアの重要性を考えると、十分な情報に基づいた選択を行うことは、大幅なダウンタイムやデータの損失を意味する可能性があります。 この記事では、永続性とデータストアの設計アプローチについて説明し、Cassandraのコンテキストでこれらの背景をいくつか提供します。
永続性とは、”原因が取り除かれた後の効果の継続”です。 コンピュータシステムにデータを格納するという文脈では、これは、データが作成されたプロセスが終了した後にデータが存続することを意味します。 言い換えると、データストアが永続的であると見なされるためには、不揮発性ストレージに書き込む必要があります。
データストアに永続性が必要な場合は、データストアが取ることができる4人の設計アプローチと、これらの設計が永続性を提供する方法（または場合）も理:
-
memcachesやScalarisなどの純粋なインメモリ、永続性はまったくありません
-
Oracle CoherenceやRedisなどの定期的なスナップショットを使用したメモリ内
-
MySQL ISAMやMongoDBなどの更新インプレース書き込みによるディスクベース
-
すべての従来のOLTPデータベース（Oracle、SQL Serverなど）など、Commitlogベース)
メモリ内のアプローチは、比較的小さなデータセットに制限されるというコストで、驚異的な速度を達成することができます。 アクティブな部分だけではなく、datset全体をメモリに収める必要があるシステムは、キャッシュには問題ありませんが、他のほとんどのアプリケーションには適していません。 データはメモリ内にのみ存在するため、プロセスの終了後も存続しません。 そのため、これらのタイプのデータストアは永続的とはみなされません。
インメモリシステムに永続性を追加する最も簡単な方法は、設定可能な間隔でディスクへの定期的なスナップショットを使用することです。 したがって、その間隔の更新分まで失う可能性があります。
Update-in-placeおよびcommitlogベースのシステムはすぐに不揮発性メモリに保存しますが、commitlogベースの永続性のみが、成功がクライアントに返される前にすべての書き込み
Cassandraはコミットログベースの永続性設計を実装していますが、同時に調整可能なレベルの耐久性を提供します。 これにより、安全性と性能の間に適切なトレードオフが何であるかを決定することができます。 書き込み操作ごとに、その更新がメモリにバッファされるのを待つか、単一のマシン上のディスクに書き込むか、複数のマシン上のディスクに書 または、ネットワークから完全に逆シリアル化される直前に受信を確認して、できるだけ早く書き込みを受け入れることを選択できます。
一日の終わりに、あなたのデータのための適切なパフォーマンス/耐久性のトレードオフが何であるかを知っているのはあなただけです。 データストアテクノロジに関する情報に基づいた決定を下すことは、このトレードオフに対処するために重要です。 Cassandraはこのような調整可能性を提供するため、耐久性のあるパフォーマンスの高いデータストアが必要なシステムにとっては論理的な選択です。