NoSQL（Cassandra）でクライアント認証ソリューションを実装する方法は？

Question

私は現在NoSQLソリューションでWebアプリケーションの認証を実装する方法を考えています。私がここで遭遇する問題は、おそらくNoSQLのソリューション（Cassandra、MongoDBなど）のほとんどが書き込みを遅らせるということです。例えば、ノードAに書き込むが、書き込みがノードBに同時に現れることは保証されない。これは、NoSQLソリューションの背後にあるアプローチと論理的です。

ここでは、2次読み取りを行わないというアイデアがあります（すべてがマスターになります）。これはおそらくMongoDB（あなたが実際にマスターを持っているところ）では動作しますが、Cassandra（すべてのノードが等しい）では動作しません。しかし、私たちのアプリケーションは世界中のいくつかの独立したポイントで動作しますので、マルチマスター機能が必要です。

現時点では、私はデータを更新できるカサンドラのソリューションを認識しておらず、その後の読み取り（すべてのノード）に変更があることを確認しています。では、認証要求（読み取り）が複数のノードに並行して出現するNoSQLソリューションの上に、どのように認証を構築することができますか？

ありがとうございました！アパッチカサンドラの点で

Answer 1

：

• http://wiki.apache.org/cassandra/API#ConsistencyLevel

ConsistencyLevelは、あなたのスキーマ定義に基づいて行動を読み取りと書き込みの両方を制御する列挙型です。異なる一貫性レベルは、書き込み操作または読み取り操作を行っているかどうかによって、異なる意味を持ちます。 W + R> ReplicationFactorの場合、Wは書込み時にブロックするノードの数であり、Rは読取り時にブロックする数であり、強く一貫性のある動作になります。すなわち、読者は常に最新の書き込みを見るでしょう。これらのうち、最も興味深いのは、QUORUMの読み書きを行うことです。これにより、ReplicationFactorの半分までのノード障害が発生しても可用性を維持できるようになります。もちろん、待ち時間が一貫性よりも重要であれば、一方または両方の値を小さくすることができます。

これはアプリケーション側で管理されます。具体的には、Cassandraの実装をどのように設計するか、Cassandraノード全体のレプリケーションファクタ、およびアプリケーションが読取り/書込み時にどのように動作するかが問題になります。

書き込み

• ANY：書き込みがHintedHandoffの受信者を含む、少なくとも1のノードに書き込まれていることを確認してください。
• 1：クライアントに応答する前に、書き込みが少なくとも1つのレプリカのコミットログとメモリテーブルに書き込まれていることを確認してください。
• QUORUM：クライアントに応答する前に書き込みがN/2 + 1個のレプリカに書き込まれていることを確認してください。
• LOCAL_QUORUMは：書き込みがローカルデータセンタ内で、/ 2 + 1のノードに書き込まれたことを確認し
• EACH_QUORUM（NetworkTopologyStrategyが必要）：書き込みが各データセンター内/ 2 + 1のノードに書き込まれたことを確認し（必要
• ALL：クライアントに応答する前に、すべてのN個のレプリカに書き込みが書き込まれていることを確認します。応答しないレプリカがあれば、操作は失敗します。

読む

• ANY：サポートされていません。代わりにONEが必要なのかもしれません。
• ONE：応答する最初のレプリカから返されたレコードを返します。 ConsistencyLevel.ONEが使用されている場合、一貫性チェックはバックグラウンドスレッドで常に行われ、一貫性の問題を修正します。これは、最初の読み取りが古い値を取得しても、後続の呼び出しで正しいデータが得られることを意味します。
• QUORUM（これはReadRepairと呼ばれている）：すべてのレプリカを照会し、それがレプリカの少なくとも大部分を持っていたら、最新のタイムスタンプを持つレコードを返します（N/2 + 1）が報告されました。再度、残りのレプリカはバックグラウンドでチェックされます。
• LOCAL_QUORUM：ローカルデータセンター内のレプリカの大半は答えた後、最新のタイムスタンプを持つレコードを返します。
• EACH_QUORUM：各データセンター内のレプリカの大半は答えた後、最新のタイムスタンプを持つレコードを返します。
• ALL：すべてのレプリカを照会し、すべてのレプリカが応答したら、最新のタイムスタンプでレコードを戻します。応答しないレプリカがあれば、操作は失敗します。要件をカバーするためのアプローチだろう