elasticsearchは異なる身体データで重複IDを許可しています

私は現在、2.0の互換性があるようにelasticsearchデータを移行しようとしています（フィールド名にドットはありません）。elasticsearchは異なる身体データで重複IDを許可しています

1ノードのクラスタ内にあるデータ（バッチ内）を実行し、フィールドの名前を変更し、バルクAPIを使用してドキュメントを再インデックスするプログラムを作成しました。

いくつかの点ですべてがうまくいかず、カウントダウンする必要があるにもかかわらず、クエリから戻ってくるドキュメントの総数（「ugpraded」）は変更されません。

当初私はそれが機能していないと思った。ドキュメントを選択してそれが変更されているかどうかを確認するためにクエリを実行すると、ドキュメントが機能していることがわかります。

しかし、ドキュメント内の特定のフィールドのドキュメントをクエリすると、同じIDを持つ2つの結果が得られます。結果の1つにアップグレードされたフィールドがあり、もう1つはアップグレードされていません。私は、彼らが別の破片から来ていることを確認することができ、さらに検査で

：

{ 
    "took" : 2, 
    "timed_out" : false, 
    "_shards" : { 
    "total" : 5, 
    "successful" : 5, 
    "failed" : 0 
    }, 
    "hits" : { 
    "total" : 2, 
    "max_score" : 19.059433, 
    "hits" : [ { 
     "_shard" : 0, 
     "_node" : "FxbpjCyQRzKfA9QvBbSsmA", 
     "_index" : "status", 
     "_type" : "status", 
     "_id" : "http://static.photosite.com/80018335.jpg", 
     "_version" : 2, 
     "_score" : 19.059433, 
     "_source":{"url":"http://static.photosite.com/80018335.jpg","metadata":{"url.path":["http://www.photosite.com/80018335"],"source":["http://www.photosite.com/80018335"],"longitude":["104.507755"],"latitude":["21.601669"]}}, 
     ... 
    }, { 
     "_shard" : 3, 
     "_node" : "FxbpjCyQRzKfA9QvBbSsmA", 
     "_index" : "status", 
     "_type" : "status", 
     "_id" : "http://static.photosite.com/80018335.jpg", 
     "_version" : 27, 
     "_score" : 17.607681, 
     "_source":{"url":"http://static.photosite.com/80018335.jpg","metadata":{"url_path":["http://www.photosite.com/80018335"],"source":["http://www.photosite.com/80018335"],"longitude":["104.507755"],"latitude":["21.601669"]}}, 
     ...  
    } 
}

どのように私はこれを防ぐことができますか？

elasticsearchバージョン：1.7.3

クエリ：文書を書くための

{ 
    "bool" : { 
    "must" : { 
     "wildcard" : { 
     "metadata.url.path" : "*" 
     } 
    }, 
    "must_not" : { 
     "wildcard" : { 
     "metadata.url_path" : "*" 
     } 
    } 
    } 
}

コード：

 BulkRequestBuilder bulkRequest = destinationConnection.getClient().prepareBulk(); 
     for(Map<String, Object> doc : batch.getDocs()){ 
      XContentBuilder builder; 
      try { 
       builder = XContentFactory.jsonBuilder().startObject(); 
       for(Map.Entry<String, Object> mapEntry : doc.entrySet()){ 
        if(!mapEntry.getKey().equals("id")){ 
         builder.field(mapEntry.getKey(), mapEntry.getValue()); 
        } 
       } 
       builder.endObject(); 
      } catch (IOException e) { 
       throw new DocumentBuilderException("Error building request to move items to new parent!", e); 
      } 

      bulkRequest.add(destinationConnection.getClient().prepareIndex(destinationIndex, destinationType, (String) doc.get("id")).setSource(builder).request()); 

     } 
     // Tried with and without setRefresh 
     BulkResponse response = bulkRequest.setRefresh(true).execute().actionGet(); 
     for(BulkItemResponse itemResponse : response.getItems()){ 
      if(itemResponse.isFailed()){ 
       LOG.error("Updating item: {} failed: {}", itemResponse.getFailure().getId(), itemResponse.getFailureMessage()); 
      } 
     }

更新
それができますリフレッシュ/クエリ速度？

プログラムは5000個のドキュメントバッチを処理するように設定されており、スクロールクエリを使用していないため、そのクエリから戻ってくる結果の総数が5000回繰り返されることが予想されます。

実際には、これは起こっていません。最終的には全ての反復と同じになるまで、各反復を設定し、集計結果から削除文書の量が減少し、削減：

10:43:42.220 INFO : Fetching another batch 
10:43:51.701 INFO : Found 9260992 matching documents. Processing 5000... 
10:43:51.794 INFO : Total remaining: 9260992 
10:43:51.813 INFO : Writing batch of 5000 items 
10:43:57.261 INFO : Fetching another batch 
10:44:06.136 INFO : Found 9258661 matching documents. Processing 5000... 
10:44:06.154 INFO : Total remaining: 9258661 
10:44:06.158 INFO : Writing batch of 5000 items 
10:44:11.369 INFO : Fetching another batch 
10:44:19.790 INFO : Found 9256813 matching documents. Processing 5000... 
10:44:19.804 INFO : Total remaining: 9256813 
10:44:19.807 INFO : Writing batch of 5000 items 
10:44:22.684 INFO : Fetching another batch 
10:44:31.182 INFO : Found 9255697 matching documents. Processing 5000... 
10:44:31.193 INFO : Total remaining: 9255697 
10:44:31.196 INFO : Writing batch of 5000 items 
10:44:33.852 INFO : Fetching another batch 
10:44:42.394 INFO : Found 9255115 matching documents. Processing 5000... 
10:44:42.406 INFO : Total remaining: 9255115 
10:44:42.409 INFO : Writing batch of 5000 items 
10:44:45.152 INFO : Fetching another batch 
10:44:51.473 INFO : Found 9254744 matching documents. Processing 5000... 
10:44:51.483 INFO : Total remaining: 9254744 
10:44:51.486 INFO : Writing batch of 5000 items 
10:44:53.853 INFO : Fetching another batch 
10:44:59.966 INFO : Found 9254551 matching documents. Processing 5000... 
10:44:59.978 INFO : Total remaining: 9254551 
10:44:59.981 INFO : Writing batch of 5000 items 
10:45:02.446 INFO : Fetching another batch 
10:45:07.773 INFO : Found 9254445 matching documents. Processing 5000... 
10:45:07.787 INFO : Total remaining: 9254445 
10:45:07.791 INFO : Writing batch of 5000 items 
10:45:10.237 INFO : Fetching another batch 
10:45:15.679 INFO : Found 9254384 matching documents. Processing 5000... 
10:45:15.703 INFO : Total remaining: 9254384 
10:45:15.712 INFO : Writing batch of 5000 items 
10:45:18.078 INFO : Fetching another batch 
10:45:23.660 INFO : Found 9254359 matching documents. Processing 5000... 
10:45:23.712 INFO : Total remaining: 9254359 
10:45:23.725 INFO : Writing batch of 5000 items 
10:45:26.520 INFO : Fetching another batch 
10:45:31.895 INFO : Found 9254343 matching documents. Processing 5000... 
10:45:31.905 INFO : Total remaining: 9254343 
10:45:31.908 INFO : Writing batch of 5000 items 
10:45:34.279 INFO : Fetching another batch 
10:45:40.121 INFO : Found 9254333 matching documents. Processing 5000... 
10:45:40.136 INFO : Total remaining: 9254333 
10:45:40.139 INFO : Writing batch of 5000 items 
10:45:42.381 INFO : Fetching another batch 
10:45:47.798 INFO : Found 9254325 matching documents. Processing 5000... 
10:45:47.823 INFO : Total remaining: 9254325 
10:45:47.833 INFO : Writing batch of 5000 items 
10:45:50.370 INFO : Fetching another batch 
10:45:57.105 INFO : Found 9254321 matching documents. Processing 5000... 
10:45:57.117 INFO : Total remaining: 9254321 
10:45:57.121 INFO : Writing batch of 5000 items 
10:45:59.459 INFO : Fetching another batch

文書の重複が最初からはびこっているかのように見えます。

クラスタの正常性ステータスが緑色の2ノードクラスタを試したところ、同じことが起こりました。

次に複製を行わない単一のノードを試してみます。

更新：
ここの前/バルクプロセッサリスナーデータの後の例である：（BulkResponseは全く障害を示さなかった）後

Item(id=http://static.photosite.com/20160123_093502.jpg, index=status, type=status, op_type=INDEX, version=-3, parent=null, routing=null)

：

Item(id=http://static.photosite.com/20160123_093502.jpg, index=status, type=status, op_type=index, version=22)

前

メモの内容：

01また、このスニペットによって明らかにされていない文書バージョン

で

親
なしルーティング
大規模なジャンプはbeforeBulk要求内の各項目はafterBulk要求に成功IndexRequestとして表されることはありません詳細（つまり、欠落しているものはありません）。私は最初の負のバージョンはそれとは何かを持っているかもしれないと考えて

アップデート2

：https://discuss.elastic.co/t/negative-version-number-on-snapshot-restore-from-s3-bucket/56642

アップデート3

私はちょうど私が照会するとことを発見しましたカールを使用しているドキュメントは、バージョンが正である、すなわち：
1. スナップショットを復元します。
2. カールを使用して文書を照会し、バージョンは、Java APIを使用して文書の2
3. クエリ、バージョンがあるさ-1
4. 再インデックスドキュメントが重複（別のシャードに書かれた同じIDを持つ新しい文書）を引き起こします
ここでは何が起こっているのですか？

出典

2016-07-27 ndtreviv

これは奇妙で不可能なように見えます... ESバージョンとそれを返したクエリは何ですか？ –

@AndreiStefan私は、右知っている！私は要求された詳細で質問を更新しました。 – ndtreviv

バルクプロセッサリスナーを登録し、beforeBulkとafterBulk情報をログに記録できますか？ – geneqew

要約：
私はばかです。

詳細：
私はhow elasticsearch routes documents to shardsを学習することで、今日始めました。あなたはそれが時にインデックス上書きしない限りroutingは、文書の_idで、デフォルトでは shard = hash(routing) % number_of_primary_shards

：

それは、次のforumulaを使用していることが判明しました。

誰も私がルーティングを行っていると言いましたが、私はそうではないことを断言しました。 それは問題でした！

私はデータのスナップショットを復元しました。私がアップグレードしようとしていたインデックスのデータは、もともとはstormcrawlerというプログラムによって書かれました。

stormcrawler ルーティングを使用してこれらのドキュメントのインデックスを作成しますが、ルーティングを使用して再インデックスを作成していないため、異なるシャード上に重複が発生していました。

もう一度、elasticsearchのルールと私は吸う。

私はこれを無駄にした皆のために申し訳ありません。私は今、暗い部屋に横たわり、泣きそうになります。

出典

2016-07-29 09:44:51 ndtreviv

elasticsearchは異なる身体データで重複IDを許可しています

答えて

関連する問題