2016-07-30 7 views
2

elasticsearchに、エラーが発生しても次のレコードを処理することがOKであることを知らせるパラメータがありますか?例えば、これは正しく動作します。バルクAPIの構文エラー

DELETE /test 

PUT /test 

PUT /_bulk 
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" }} 
{ "field1" : "value1" } 
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } } 
{ "field1" : "value3" } 

get /test/type1/_search 

構文エラーの場合は、その行をスキップして次の行を読み込むことをお勧めします。以下のケースでは、私は、ID 1が原因一括更新が運用エラーで停止しませんが、発生している問題が原因であるElasticsearch 2

PUT /_bulk 
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" }} 
{ "field1" : "value1" } { 
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } } 
{ "field1" : "value3" } 
+0

エラーが発生した場合に一括停止しますか?私の知るところでは、単一のリクエストが失敗した場合には、何もエラーをスローまたはスローしません。 –

+0

上記のコードを実行すると、クローズされていない{両方のレコードが失敗したために表示されます。私は2番目の記録が合格することを期待していましたが。 – shantanuo

+0

閉じられていない括弧を残している場合、その文書が終了すると、バルクAPIは理解できません。バルクは、リクエストで渡されたエラーではなく、内部エラーに対するエラー処理を持っています。 –

答えて

2

ライン上の{余分に失敗した場合でも、ID 3を挿入しますプログラマにエラーがあります。問題は、リクエストに構文エラーがある場合、Elasticsearchがリクエストを解析する方法がないことです。一括更新の文書から - Why the funny format?

Elasticsearchは、生の要求を受信したネットワークバッファに最大に達し、直接データを読み出します。これは改行文字を使用して、各要求を処理するシャードを決定するために小さなアクション/メタデータ行を識別して解析します。

これらの生のリクエストは、正しいシャードに直接転送されます。データの冗長コピーはなく、無駄なデータ構造はありません。要求プロセス全体は、可能な限り小さなメモリ量で処理されます。

どこかに構文エラーがあると、アクション/要求行を特定できません。

+0

私はそれが操作上のエラーを渡すようにプログラマーのエラーを渡すことを期待しています。私は膨大な量のログデータをインポートしようとしています。私の場合、できるだけ多くのデータをインポートし、データの整合性は問題になりません。 – shantanuo