0

だから、solr 4.0を使って

1 つのサブエンティティ (1:N 関係) を持つエンティティのかなりストレートなセットアップがあります。

インポートするデータは mysql サーバー上にあります

メイン テーブルには約 3,000 万件のレコードがあり、サブ テーブルには約 500 万件のレコードがあります (ほとんどの親エンティティにはサブ エンティティがなく、残りのエンティティには通常 1 が 1 つあります)。

かなりひどいインデックス作成 (インポート) のパフォーマンスに遭遇しています。毎秒約 80 個のエンティティ (ドキュメント)。したがって、このテーブルにインデックスを付けるには、理論的には数日かかります。

たとえば、最初の 1000 個のエンティティにインデックスを付けるように指示すると、実際には 1000 個以上のクエリが SQL に発行されます。また、データソースのbatchSizeプロパティを設定しようとしましたが、うまくいきません...-1しか機能しません(そうでない場合はメモリ不足の例外)。

これを最適化するために何ができるか本当にわかりません.mysql用の適切なデータインポーターはありませんか?

4

2 に答える 2

1

サブエンティティクエリが少なくともキャッシュされるように、CachedSqlEntityProcessorを使用できます...

于 2012-09-24T15:12:18.370 に答える
0

cachedEntity アプローチは別の問題で私を助けたと思いましたが、ネストされたエンティティを使用することは、通常、ただ行っているだけではないことがわかりました。

「ルート」エンティティごとにサブ エンティティ クエリを起動するロジックは、まったく機能しません。

ルート エンティティとサブ エンティティの両方を単一の行としてフェッチし、それに応じてフィールドにマップする SQL JOIN にステートメントを書き直したところ、パフォーマンスが大幅に向上しました。

于 2012-09-27T16:13:40.710 に答える