問題タブ [datastax-java-driver]

私はカサンドラを評価しています。私は datastax ドライバーと CQL を使用しています。

更新ごとに名前が異なる、次の内部構造を持つデータを保存したいと思います。

したがって、時間は列キーであり、名前は行キーである必要があります。このテーブルの作成に使用する CQL ステートメントは次のとおりです。

クエリを簡単にするために、スキーマをこのようにしたいと思います。また、65000 行を超える更新を保存する必要がある場合もあります。そのため、cassandra の list/set/map データ型を使用することはできません。

名前/値のペアの数はさまざまですが、大量 (~1000) で、1 秒あたり少なくとも 1000 の幅の広い行の挿入を処理できる必要があります。

問題は次のとおりです。それぞれ 10000 個の名前と値のペアを 1000 行挿入する単純なベンチマークを作成しました。CQL と datastax ドライバーを使用するとパフォーマンスが非常に低下しますが、CQL を使用しないバージョン (astyanax を使用) は同じテスト クラスターで良好なパフォーマンスを示します。

この関連する質問を読みました。この質問の受け入れられた回答では、cassandra 2 で利用可能なバッチ準備ステートメントを使用して、新しいワイド行をアトミックかつ迅速に作成できる必要があることを示唆しています。

そのため、それらを使用してみましたが、それでもパフォーマンスが低下します (ローカルホストで実行されている小さな 3 ノード クラスターで 1 秒あたり 2 回の挿入)。明らかな何かが欠けていますか、それとも低レベルのthrift APIを使用する必要がありますか? astyanax で ColumnListMutation を使用して同じ挿入を実装しましたが、1 秒あたり約 30 回の挿入が行われました。

低レベルのthrift APIを使用する必要がある場合:

• それは実際に非推奨ですか、それとも低レベルであるため使用するのが不便ですか?

• Thrift API で作成されたテーブルを CQL でクエリできますか?

以下は、scala での自己完結型のコード例です。10000 列の幅の広い行を挿入するためのバッチ ステートメントを作成するだけで、挿入のパフォーマンスを繰り返し測定します。

BatchStatement のオプションと整合性レベルを試してみましたが、パフォーマンスが向上するものは何もありませんでした。

私が持っている唯一の説明は、準備されたステートメントで構成されるバッチにもかかわらず、エントリが行に 1 つずつ追加されるということです。

これは、本質的に同じことを 15 倍高速に実行する astyanax コード ( astyanax の例を変更したもの) です。これも非同期呼び出しを使用しないため、公正な比較であることに注意してください。これには、列ファミリーが既に存在している必要があります。なぜなら、私は astyanax を使用して列ファミリーを作成する方法をまだ理解しておらず、例には列ファミリーを作成するためのコードが含まれていなかったからです。

更新: cassandra-userメーリング リストでこのスレッドを見つけました。大きな幅の行の挿入を行う場合、CQL にパフォーマンス上の問題があるようです。この問題を追跡するためのチケットCASSANDRA-6737があります。

Update2: CASSANDRA-6737 に添付されているパッチを試してみたところ、このパッチで問題が完全に修正されていることが確認できました。これを迅速に修正してくれた DataStax の Sylvain Lebresne に感謝します。

DSE 3.2.1 を実行しており、datastax Java ドライバー cassandra-driver-core-1.0.5-dse.jar を使用しています。

DSE が稼働しており、リスナーが構成されていることを確認できます。

しかし、このドライバーを使用して接続することはできません。スカラコード:

この例外を取得する:

何か案は？このドライバーでポート 9160 または 9042 を使用する必要がありますか? ここから参照コード例を使用: http://www.datastax.com/documentation/developer/java-driver/1.0/java-driver/quick_start/qsSimpleClientCreate_t.html

TIA、JM。

Datastax Java Driver と JSP を使用しています。

Java では、このコードを使用できます。ResultSet と Row はどちらも Datastax Java ドライバーからのものです。

このコードで JSP を使用すると

このエラーが発生します

これまでのところ、ソリューションはそれらをリストとして送信しています。しかし、リスト全体を読むには 2 回かかります。とにかく、この ResultSet を送信して JSP で処理できますか?

CQL (またはさらに重要なのは、datastax Java ドライバー) で、「WHERE カウンター > 5」のように、カウンターの値を正確に照会できますか?

ありがとう、

DB 書き込みsession.executeAsync()の代わりに呼び出すことで、コードを高速化しようとしています。session.execute()

DB 接続がダウンしている可能性があるユースケースがあります。現在、execute()接続が失われた場合 (クラスター内で到達可能なホストがない場合) に、前の例では例外がスローされます。これらの例外をキャッチして、再試行するか、データを別の場所に保存することができます...

ではexecuteAsync()、このユースケースを満たす方法がないように見えます-返されたResultSetFutureオブジェクトにアクセスして結果を確認する必要があり、executeAsync()そもそも を使用する目的が無効になります...

DB 書き込みが失敗したことを他のコードに非同期的に通知する executeAsync() 呼び出しのどこかにリスナー (または類似のもの) を追加する方法はありますか?

これは適切ですか？データスタックス 1.0.2 Java 1.7.40

数ヶ月ぶりに以下の不具合が発生しました。Java ドライバを使用してクエリを開いて実行しようとするセッションは、特定のスレッドをハングさせます。この結果、この特定のスレッドは永久に待機し、スレッド ロックの問題が発生します。これは、アプリ サーバーの再起動を使用して解決されました。しかし、この種のドライバーの問題に手動で介入することはできません。誰かがこれについて考えを持っていますか?

sun.misc.Unsafe.park(ネイティブ メソッド) java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) java.util .concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptively(AbstractQueuedSynchronizer.java:905) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptively(AbstractQueuedSynchronizer.java:1217) com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture .java:292) com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116) com.google.common.util.concurrent.Uninterruptibles.getUninterruptively(Uninterruptibles.java:135) com.datastax.driver .core.ResultSetFuture.getUninterruptively(ResultSetFuture.java:181) com.datastax.driver.core.Session.実行(Session.java:111) com.datastax.driver.core.Session.execute(Session.java:80)

カサンドラでバッチステートメントがアトミックであるとはどういう意味ですか? 正確に言うと、ドキュメントは本質的に少し混乱します。クラスター内のノード全体でクエリがアトミックであることを意味しますか?

たとえば、100 個のクエリを含むバッチがあるとします。バッチの 40 番目のクエリが失敗した場合、バッチで実行された 39 のクエリはどうなりますか?

内部でバッチログが作成され、部分的なバッチの一貫性が維持されることを理解しています。残りの 39 エントリを削除し、バッチ クエリに必要なアトミックな性質を提供しますか。

MYSQL では、autocommit を false に設定しているため、ロールバックできます。そのような場合、cassandra はロールバックしますか?