Cassandra をデータベース システムとして使用する CMS のコードを書いています。
CMS の強みの 1 つは、CMS で変更されるデータに対して永続的に実行されるバックエンド コンピューターを使用して、あらゆる種類のものを事前に計算できることです。
たとえば、CMS は、ページが作成または変更されたことをリスト システムに通知します。リスト システムは、その情報を というテーブルに保存しますlist。その情報は、どのページを処理する必要があるかを示す 1 つのライナーにすぎません。
Column family: list
Row: concerned website (i.e. http://www.example.com/)
Column: full URI (i.e. http://www.example.com/this/page)
Value: true (because you need something for the column to exist)
ときどき (ほとんどの場合、単純なページ編集後 1 秒以内)、そのリスト バックエンド システムが起動し、特定のページが変更されたことを確認し、含まれている (または含まれていない) すべてのリストを更新することによって、そのページで作業を開始します。そのページを要素として。これにより、フロントエンドはリスト内の要素の数を即座に認識し、リストが必要なときに複雑なクエリを実行することなくリストを非常に迅速に読み取ることができます (多くの CMS が SQL を使用して行うこととは対照的です...)
実際には、listテーブルを TODO リストとして使用しています。私が取り組まなければならない一連のページ。そのため、フロントエンドはそのリストにページ参照を追加し、バックエンドはそれらの処理が完了するとそれらを削除します。その結果、テーブル内に非常に多くのトゥームストーンが作成される可能性がありlistます。現実世界の影響: トゥームストーン障害が発生し、システムがランダムな場所で障害を起こし始めました。リストが機能しなくなると、システム内の他の多くの機能が停止し、Web サイトが使用できなくなります。
Cassandra がその特定のテーブル (および他のいくつかのテーブル) の墓石を処理するのにかかる時間を短縮しましたが、期待どおりに Cassandra を使用しているかどうか疑問に思っています。この環境でこの種の TODO リストを処理するためのより良い方法はありますか?
補足として: TODO リストは、さまざまなバックエンド コンピューターから処理される可能性があります。小規模なシステムでは、リスト データに対して実行するバックエンドが 1 つしかない可能性が高く、数千人のユーザーがいる大規模なシステムでは、リストを処理するためだけに 2 つまたは 3 つのバックエンドを使用する可能性は低くありません。そのため、Cassandra にデータを保持することは、コンピューター間でデータをすばやく共有するのに非常に実用的です。