問題タブ [datastax-startup]

DSE 4.8.7 を使用すると、Solr によってインデックス付けされている cassandra テーブルに、1 秒あたり約 1,000 レコードを挿入できます。2 ～ 3 ノード (5 ノード クラスタ内) で次のメッセージがログに表示されるまで、しばらくの間 (おそらく 30 ～ 60 分) スループットは問題ありません。

この時点で、挿入スループットは 2 ～ 10 レコード/秒に低下します。ノードを再起動すると問題が解決します。クラスター内のすべてのノードで、OS 負荷と IO の両方が低くなっています。また、nodetool の統計を見ると、保留中のタスクはありません。

この質問は、(a) これがまだ問題であるように見え、(b) その質問についてコメントできないため、意図的に行っています。

今日、開発ノードの 1 つを DSE 4.8.0 から 4.8.7 にアップグレードしましたが、system.log にこれらのエラーが大量に記録されています。これが発生する理由と解決方法についての洞察はありますか?

WARN [main_development.skus Index WorkPool scheduler thread-0] 2016-05-18 13:51:11,037 WorkPool.java:672 - Listener com.datastax.bdp.search.solr.AbstractSolrSecondaryIndex$SSIIndexPoolListener@1d132e91 failed for pool main_development.skus Index with exception: SolrCore 'main_development.skus' is not available due to init failure: Unique key fields must not be tokenized. Problematic type: text_en_splitting_tight{class=org.apache.solr.schema.TextField,analyzer=org.apache.solr.analysis.TokenizerChain,args={autoGeneratePhraseQueries=true, positionIncrementGap=100, class=solr.TextField}} for field: sku org.apache.solr.common.SolrException: SolrCore 'main_development.skus' is not available due to init failure: Unique key fields must not be tokenized. Problematic type: text_en_splitting_tight{class=org.apache.solr.schema.TextField,analyzer=org.apache.solr.analysis.TokenizerChain,args={autoGeneratePhraseQueries=true, positionIncrementGap=100, class=solr.TextField}} for field: sku at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:742) ~[solr-uber-with-auth_2.0-4.10.3.1.1021.jar:na] at com.datastax.bdp.search.solr.core.CassandraCoreContainer.getCore(CassandraCoreContainer.java:170) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.AbstractSolrSecondaryIndex.getCore(AbstractSolrSecondaryIndex.java:550) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.AbstractSolrSecondaryIndex$SSIIndexPoolListener.onBackPressure(AbstractSolrSecondaryIndex.java:1461) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.concurrent.WorkPool.onBackPressure(WorkPool.java:668) [dse-core-4.8.7.jar:4.8.7] at com.datastax.bdp.concurrent.WorkPool.access$300(WorkPool.java:57) [dse-core-4.8.7.jar:4.8.7] at com.datastax.bdp.concurrent.WorkPool$BackPressureTask.run(WorkPool.java:694) [dse-core-4.8.7.jar:4.8.7] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_92] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_92] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_92] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_92] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_92] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_92] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92] Caused by: org.apache.solr.common.SolrException: Unique key fields must not be tokenized. Problematic type: text_en_splitting_tight{class=org.apache.solr.schema.TextField,analyzer=org.apache.solr.analysis.TokenizerChain,args={autoGeneratePhraseQueries=true, positionIncrementGap=100, class=solr.TextField}} for field: sku at com.datastax.bdp.search.solr.core.CassandraCoreContainer.load(CassandraCoreContainer.java:236) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.core.SolrCoreResourceManager.loadCore(SolrCoreResourceManager.java:257) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.AbstractSolrSecondaryIndex$4.run(AbstractSolrSecondaryIndex.java:1011) ~[dse-search-4.8.7.jar:4.8.7] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_92] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_92] ... 3 common frames omitted Caused by: com.datastax.bdp.search.solr.CassandraIndexSchema$ValidationException: Unique key fields must not be tokenized. Problematic type: text_en_splitting_tight{class=org.apache.solr.schema.TextField,analyzer=org.apache.solr.analysis.TokenizerChain,args={autoGeneratePhraseQueries=true, positionIncrementGap=100, class=solr.TextField}} for field: sku at com.datastax.bdp.search.solr.CassandraIndexSchema.validateUniqueKey(CassandraIndexSchema.java:479) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.CassandraIndexSchema.validate(CassandraIndexSchema.java:123) ~[dse-search-4.8.7.jar:4.8.7] at com.datastax.bdp.search.solr.core.CassandraCoreContainer.load(CassandraCoreContainer.java:232) ~[dse-search-4.8.7.jar:4.8.7] ... 7 common frames omitted

次のプロセスを使用して、PHP 用の datastax cassandra ドライバー拡張機能をインストールしました。

• インストールされる依存関係: automake cmake gcc gcc-c++ git libtool openssl-devel wget gmp gmp-devel boost php-devel pcre-devel git libuv gmp
• ソースからコンパイルして cpp-driver をインストール
• ソースからインストールされた PHP Datastax cassandra ドライバー
• /etc/php.ini ファイルに拡張機能を追加

Cassandra クラスターに接続するために php ファイルを実行しようとすると、次のエラーが発生します。

代わりにバイナリを使用して再度インストールしようとしましたが、まだ同じ問題に直面しています。

ldd の出力は次のとおりです。

ご協力いただきありがとうございます。

Cassandra ログに予期しないエラーが記録されています。根本的な原因をまだ追跡できていません。どのコンポーネントが Netty を利用していますか、またはこの問題はよく知られていますか? (情報が見つかりませんでした)

OpsCenter のベスト プラクティス サービスから次の情報を受け取りましたが、その理由は何ですか?

次のテーブルには過度に大きなパーティションがあります:

fabrikam.data_example_by_minute (177 mb) fabrikam.data_example_by_second (637 mb)

幅の広いパーティションを分割するようにデータを改造することを検討してください。

Windows Server 2012 で datastax-community-64bit_2.2.6 と DevCenter-1.4.1-win-x86 を使用しています (問題が発生していないように見える古い Win Server 2008 で同じセットアップを使用しています)。

一貫性のない読み取りで非常に奇妙な動作をしている時系列テーブルがあります。丸一日のデータがありますが、次のスクリーンショットに示すように、コードと DevCenter の両方を介してクエリを実行すると、1 日の数時間分のデータが読み込まれません:::

devcenter ルックアップ::: https://drive.google.com/file/d/0B_e9YTMgramiSTFqUGFPYVB3bkk

ご覧のとおり - 7 時から 8 時までは直接ロードできません - 9 時から 10 時までは可能です。>= と < を使用しながら 7-8 時間だけを読み込むことは可能です (一番上の選択)。これは問題をさらに混乱させます。

私たちのアプリケーションでは、Cassandra からデータがロードされていないため、1 日の多くの時間が不明 (? の付いたアイコン) として表示されます....次のスクリーンショットを参照してください::

申請に不足している時間::: http://drive.google.com/open?id=0B_e9YTMgramiTUxfNTlJYlVwUEU

緑色のアイコンが付いている時間は、DevCenter でクエリできる時間と同じです (9 ～ 10 時間は図 2 にあったため)。残りの時間はそうではありません。これをさらに不可解なものにしているのは、すべての時間のポイントが含まれるトレンド グラフに同じデータをロードするという事実です。

誰もがこのようなことを経験したことがありますか？....一部の時間のデータは常に Cassandra から選択できるようですが、他の時間には問題があります:/ ...もちろん、すべてのデータは同じ方法で挿入されます!!

現在、Cassandra と Spark のプロバイダーとして datastax enteprise を評価しています。AWS に Datastax クラスターをデプロイすることを検討しています。

次の質問があります。

1) Datastax on EC2インストール マニュアルのステップ 1 で、正しい AMI イメージを選択する必要があります。現在、7 つのイメージがあります。どちらが正しいですか: (DataStax Auto-Clustering AMI 2.5.1-pv、DataStax Auto-Clustering AMI 2.6.3-1204-pv、DataStax Auto-Clustering AMI 2.6.3-1404-pv....)

2) クラスターを立ち上げた瞬間に、aws インスタンスに対してのみ支払いますか、それとも Datastax Enterprise ライセンス料も支払いますか? 30 日間のエンタープライズ無料試用版があることは知っていますが、インストール プロセスのどこにも無料試用版を要求できるステップがありませんか? 月単位で (作成したインスタンス タイプに基づいて) クラスターのコストを計算するために使用できるオンライン計算機はありますか?

3) インストール プロセスのステップ 3インスタンスの詳細の構成で、インスタンスとノードという用語を混同しています。それらの違いは何ですか？選択するとどうなりますか:

a) 1 インスタンス、 --totalnodes 3 (ユーザー データ内)

b) 3 つのインスタンス、--tatalnodes 3

c) 1 インスタンス、 --totalnodes 0 --analyticsnodes 3

d) 3 つのインスタンス、 --totalnodes 0 --analyticsnodes 3

4) 3 つの cassandra ノードのそれぞれに Spark があるユース ケースに関心があります。ユーザー データの構成は適切です か? --totalnodes 0 --analyticsnodes 3 この 場合、cassandra のみを含む 0 ノードと、Cassandra と Spark を含む 3 つのノードを使用することになりますか? その場合、指定する必要があるインスタンスの数はいくつですか?

5) インストール プロセスAdd Storageのステップ 4 で、インスタンスにストレージを追加するよう求められます。しかし、なぜこのストレージが必要なのでしょうか? m3.largeなどのインスタンス タイプを選択するとき、インスタンスに32 GB の SSD ストレージがあることは既にわかっていますが、これは何ですか?

回答ありがとうございます。これらの質問を送信できるメーリング リストがあれば、それをいただければ幸いです。

アプリケーションで Datastax の DSE Search を使用したいと考えています。すべてのノードに Cassandra があり、半分のノードに SOLR があります。

1 つの SOLR インスタンスに接続できます

SOLR クラウドへの接続と同様の負荷分散とフェイルオーバーを実現するために、SOLR に接続したいと考えています。

DSE Searchでこのようなことは可能ですか?

ソーシャル ネットワークに Datastax Cassandra を使用しており、必要なテーブルを設計/データ モデリングしていますが、混乱しており、いくつかのテーブルを設計する方法がわからず、いくつかの小さな問題があります。

クエリごとに理解したように、異なるテーブルが必要です。たとえば、ユーザー A はユーザー C と B をフォローしています。

現在、Cassandra には次のテーブルがありますposts_by_user。

そして、ユーザーのフォロワーに応じたテーブルがありuser_timeline、フォロワーユーザーが最初の Web ページにアクセスしたときに、テーブルからデータベースから投稿を取得するという名前のテーブルに投稿の情報を挿入しuser_timelineます。

そして、ここにuser_timeline表があります：

まず、このデータ モデリングは、フォロー ベース (フォロワー、フォロー アクション) ソーシャル ネットワークに対して正しいですか?

ご覧のとおり、両方のテーブル( user_timeline、posts_by_user)にいいねの数があり、1 人のユーザーに 1000 人のフォロワーがいるとします。各いいねアクションによって、1000 行すべてuser_timelineと 1 行を更新する必要があります。 posts_by_users; そして、これは論理的ではありません！

次に、私の 2 番目の質問は、どうあるべきかということです。（お気に入りの）テーブルはどうあるべきですか？