4 スレッドで数十万行を生成するアプリを実装しています。各スレッドは、cassandra への個別の接続を開きます。
テーブルのすべての項目には一意のハッシュ識別子 (文字列) がありますが、主キーは uuid です。
アイテムが永続化されるプロセスは次のとおりです。
1) アイテムが作成され、そのハッシュが計算されます。2) 次に、ハッシュのルックアップが 2 番目のテーブルで実行されます。このテーブルは、アイテムの uuid に応じてハッシュをペアにします。3) ハッシュ - uuid ペアが見つかった場合、アイテム uuid のルックアップが実行され (最初のテーブルが再び)、アイテムが存在する必要があるため (「ハッシュ - uuid」ペアが見つかったため)、アイテムはからロードされます。 cassandra を JPA に変換し、その後更新されます。「hash - uuid」のペアが見つからない場合、対応するテーブルに新しいアイテムが作成され、新しい「hash - uuid」のペアも保存されます。
データ生成には 2 つのステップがあります。最初のステップは空のテーブルで実行され、最初のデータセットが生成されます。ステップ nr. ではエラーは発生しません。3、「hash - uuid」のペアが見つからないため、更新は行われません。
2 番目のステップでは、アルゴリズム全体が再度実行されますが、既にデータが入力されたデータ テーブルに対して実行されます。このステップでは、対応する uuid (主キー) によるデータ項目の読み取り中にランダム エラーが発生します。サーバーが完全なテキスト データを返さない場合があります (適切な JSON 文字列はテーブルに格納されますが、不完全な JSON 文字列はアプリケーションに取得されます)。 ）。
同じアルゴリズムが休止状態とmysqlで機能し、postgresqlでも機能したため、私のアルゴリズムが正しいことは完全に確信しています（ただし、より高速な書き込みが必要なので、cassandraで遊んでいます）。
私は 16 GB の RAM を搭載した macbook pro を使用しています。cassandra での作業には、Kundera ライブラリ (JPA をサポート) を使用しています。cassandra については、datastax 2.0.4 バージョンと、Apache サイトから直接ダウンロードした 2.0.7 バージョンを試しました。クラスターはありません。外部 SSD ドライブで、私のマシンでローカルに実行されているインスタンスは 1 つだけです。Kundera は CQL v3 を使用しています。
この動作がどのように発生する可能性があるか、誰にも考えがありますか? datastax cassandra ドライバーまたは Kundera にバグはありますか? または、cassandra の使い方が間違っているので、データベースをこのように使用するべきではありませんか? または、私が忘れている可能性のある設定の微調整はありますか?
カサンドラ構成ファイルで変更したのはすべてのタイムアウトだけです。これは、デフォルト値であまりにも多くの TimeoutExceptions を取得していたためです (タイムアウトは主キーの検索中に発生しました)。