問題タブ [astyanax]

現在、私はそのようにClusterContextを開始しています:

単一ノードの開発環境で実行されています。キースペース、列ファミリーなども作成したいので、ClusterContext を使用しています。

さらに KeyspaceContext も起動する必要がありますか? もしそうなら、どのような目的のために、または単一の ClusterContext でキースペース/列ファミリーの管理と読み取り/書き込みのシナリオに十分ですか?

KeyspaceContext を起動すると、接続プール モニターによると、2 つのホストが追加されてアクティブになっていることがわかります。単一の Cassandra ノードをシャットダウンしても、まだ 1 つがアクティブとしてマークされているため、混乱します。

ありがとう。

AWS に 3 ノードの cassandra クラスターがあります。これらのノードは cassandra 1.2.2 を実行しており、8 GB のメモリを搭載しています。デフォルトのヒープまたは GC 設定は変更していません。したがって、各ノードには 1.8GB のヒープ領域が割り当てられます。行は広いです。各行には約 260,000 列が格納されます。Astyanax を使用してデータを読み取っています。アプリケーションが同時に 10 行以上からそれぞれ 80,000 列を読み取ろうとすると、一部のノードがヒープ領域を使い果たし、OOM エラーで終了します。エラーメッセージは次のとおりです。

各列のデータは 50 バイト未満です。すべての列オーバーヘッド (列名 + メタデータ) を追加した後、100 バイトを超えてはなりません。したがって、それぞれ 10 行から 80,000 列を読み取るということは、80,000 * 10 * 100 = 80 MB のデータを読み取ることを意味します。サイズは大きいですが、1.8 GB ヒープを埋めるには十分ではありません。では、なぜヒープがいっぱいになるのだろうか。データ リクエストが大きすぎて妥当な時間を満たせない場合は、Cassandra が終了する代わりに TimeOutException を返すことを期待します。

簡単な解決策の 1 つは、ヒープ サイズを増やすことですが、それでは問題が見えなくなるだけです。80MB のデータを読み取っても、1.8GB のヒープがいっぱいになることはありません。

OOM 例外を防ぐために微調整できる他の Cassandra 設定はありますか?

Asytanaxを使用して列を複合するクエリの実行時に InvalidRequestException(Why:Too many bytes for comparison) を参照する

astyanax 1.56.37 と cassandra 1.2.5 を使用して正確な問題が発生しています

https://issues.apache.org/jira/browse/CASSANDRA-4377の修正が機能していません。再確認: この修正は 1.2.5 に含まれていますか?

私はastyanaの書き込み操作を試していて、そのためにcqlshを使用していました。単にクエリを使用すると、結果を取得できます

ただし、準備済みステートメントを使用して同じことを行うと、以下のエラーが発生します。

以下のエラーが表示されます

タイムスタンプをテーブルに保存しようとすると、間違っていると思います。しかし、準備済みステートメントにタイムスタンプを保存するのに適切なものは何も見つかりませんでした。データベース内のフィールドのデータ型は「timestamp」です。

4 ノードの Cassandra クラスターがあります。単一のノードは、AstyanaxContext の構築時に setSeeds(...) メソッドを介して提供される Astyanax 接続プールのシード ノードとして機能します。また、独自の接続プール監視実装もプラグインしました。これは、1 つのホスト (シード ノード) が追加されたことを示していますが、他の 3 つのノードは表示されていません。Astyanax のシード ノードを停止する場合 (たとえば、この特定のノードの nodetool を使用して thrift を無効にするなど)、Cassandra への Astyanax 要求はすべて失敗します。接続プールは、シード ノードを介してクラスターがどのように見えるかを学習し、シード ノードを常に起動して実行する必要はないと思いましたか?

NodeDiscoveryType として RING_DESCRIBE を使用し、ConnectionPoolType として TOKEN_AWARE を使用しています。

Astyanax 1.56.42を最新バージョンのDatastax Community (Apache Cassandra 1.2.6)で、2 ノードの Glassfish クラスターを備えた新しい 2 ノードの Cassandra クラスターで使用しています。新しいユーザーの書き込み中にいくつかの問題を発見しました。セッションエントリー。

私のキースペースの設定は次のとおりです。

次を使用して、ユーザーセッションテーブルに更新を行っています。

その後、このセッションを正確に読み取ろうとします。

この読み取りは時々失敗します (= 行が返されません)。「ときどき」とは、クラスターがほぼアイドル状態の場合でもまったく失敗しないことを意味します。ただし、UPDATE ステートメントで setConsistencyLevel-Attribute が「ALL」に設定されているにもかかわらず、負荷が高い場合は、より頻繁に実行されます。

興味深いのは、遅延がこの問題を「解決」することです。後で cqlsh で手動 SELECT を実行しようとすると、新しいセッションが表示されますが、2 番目のクエリには遅すぎます。

私は何を間違っていますか？これはバグですか？ConsistencyLevel.CL_ALL が意図したとおりに動作することを確認するにはどうすればよいですか?

（私の質問は、Cassandraの更新が一貫して機能しないことに何らかの形で関連していますが、私は何か違うことをしています。）

編集:私のキースペースは次を使用して設定されます:

編集 #2: すべてのクエリで整合性レベルを「ALL」に設定し、replication_factor を 1 に切り替えました。さらに、1 つの (アプリケーション サーバー) クライアントに切り替えて、これがクライアントとは関係がないことを確認しました。 -タイムスタンプ。読み取りと書き込みは同期して行われますが、問題はランダムに発生します。