para search elasticsearch v5
v1.36.1
elasticsearch 5.xパラ用プラグイン
このプロジェクトは廃止されており、維持されなくなります。
Paraは、オブジェクトの持続性と検索のためのシンプルでモジュールのバックエンドフレームワークとして設計されました。アプリケーションはオブジェクトをデータストア（NOSQL）またはリレーショナルデータベース（RDBMS）に直接保存できます。また、これらのオブジェクトを自動的にインデックスを作成し、検索可能にします。
このプラグインを使用すると、ElasticSearchをパラの検索エンジンとして使用でき、 5.xバージョンのElasticSearchとのみ互換性があります。
Searchインターフェイスを実装し、トランスポートクライアントをサポートしますDAOインターフェイスを実装して、ElasticSearchをデータベースとして使用できるようにします（生産中は避けてください！）/v1/_elasticsearchすべてのリクエストをElasticSearch（デフォルトで無効）に直接リレーするプラグインはMaven Centralにあります。 pom.xmlに含めるMavenスニペットは次のとおりです。
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch-v5</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency >または、上記の「リリース」タブからJARをダウンロードして、サーバーWARファイルのpara-xyzwarと一緒にlibフォルダーに入れます。 Paraは、 lib内のプラグインを探し、ElasticSearchプラグインをピックアップします。
このプラグインのすべての構成プロパティを次に示します（これらはapplication.conf内に移動します）：
# enable this to bypass the DB and read all data straight from ES
para.read_from_index = false
para.es.shards = 5
para.es.replicas = 0
para.es.dir = " data "
para.es.auto_expand_replicas = " 0-1 "
para.es.use_transportclient = false
para.es.transportclient_host = " localhost "
para.es.transportclient_port = 9300
para.es.fail_on_indexing_errors = false
# asynchronous settings
para.es.async_enabled = false
para.es.bulk.size_limit_mb = 5
para.es.bulk.action_limit = 1000
para.es.bulk.concurrent_requests = 1
para.es.bulk.flush_interval_ms = 5000
para.es.bulk.backoff_initial_delay_ms = 50
para.es.bulk.max_num_retries = 8
para.es.bulk.flush_immediately = false
# proxy settings
para.es.proxy_enabled = false
para.es.proxy_path = " _elasticsearch "
para.es.restclient_scheme = " http "
para.es.restclient_host = " localhost "
para.es.restclient_port = 9200最後に、構成プロパティを設定します。
para.search = "ElasticSearch"
これは、JavaシステムプロパティまたはClassPathのapplication.confファイルの一部である可能性があります。これにより、パラは、デフォルト（Lucene）の代わりにElasticSearchの実装を使用するように指示されます。
ElasticSearchプラグインは、同期（デフォルト）と非同期インデックスモードの両方をサポートしています。同期インデックスの場合、ElasticSearchプラグインは、クライアントを介して単一のブロッキングリクエストを行い、応答を待ちます。これは、各ドキュメント操作（インデックス、リネックス、または削除）が新しいクライアントリクエストを呼び出すことを意味します。特定のアプリケーションでは、これによりElasticSearchクラスターに大量の負荷を誘発する可能性があります。ただし、同期インデックスの利点は、リクエストの結果をクライアントアプリケーションに伝えることができます。設定para.es.fail_on_indexing_errorsがtrueに設定されている場合、エラーになる結果の同期リクエストは、HTTPエラーコードを使用してクライアントアプリケーションに戻ります。
非同期インデックスモードは、すべての要求をElasticSearchクラスターにバッチするためにElasticSearch BulkProcessorを使用します。非同期モードが有効になっている場合、すべてのドキュメントリクエストがバルクプロセッサに供給され、リクエストがクラスターにフラッシュされる場合があります。ドキュメント数、総文書サイズ（MB）、および総持続時間（MS）に基づいてフラッシュ周波数を制御するためのいくつかの構成可能なパラメーターがあります。 ElasticSearchは近いリアルタイム検索エンジンとして設計されているため、非同期モードを強くお勧めします。ドキュメントリクエストを時々大きくするバッチを作成すると、ElasticSearchクラスターの負荷が減少するのに役立ちます。
非同期インデックスモードは、失敗したインデックスリクエストを自動的に再試行するための魅力的な機能も提供します。 ElasticSearchクラスターが重い負荷にさらされている場合、新しいドキュメントのインデックスをインデックスするリクエストが拒否される可能性があります。同期インデックスを使用すると、クライアントアプリケーションに負担がかかります。ただし、ElasticSearch BulkProcessorは、RETRIES間の指数バックオフを使用して、インデックスリクエストを自動的に再試行する便利な機能を提供します。インデックスリクエストがEsRejectedExecutionExceptionで失敗した場合、リクエストはpara.es.bulk.max_num_retries timesに再試行されます。ユースケースがDAOと検索の間のデータの一貫性に関して高度な信頼を要求したとしても、RETRIESを有効にして非同期インデックスを使用することをお勧めします。非同期インデックスを使用することを好むが、index/unindex/indexall/unindexallのすべての呼び出しにかさばりのあるものをフラッシュする場合は、単純に有効になりpara.es.bulk.flush_immediatelyた。このオプションが有効になっている場合、要求にドキュメントを追加した直後に、BulkProcessorのフラッシュメソッドが呼び出されます。このオプションは、ドキュメントが迅速にフラッシュするようにしたいユニットテストを作成するのにも役立ちます。
このプラグインには、通常とネストされた2つのインデックスモードがあります。ネストされたモードは、v1.28の後に追加され、爆発のマッピングの可能性から保護され、多くの異なるカスタムプロパティがあるオブジェクトがたくさんある場合に発生します。これにより、ElasticSearchインデックスメタデータが過負荷になり、クラスター全体がクラッシュする可能性があります。このインデックスモードは、 Syspropオブジェクトのカスタムプロパティのみに影響します。
古い「通常の」モードは、ほとんどのパラの展開に適しており、ほんの数人のテナントまたは1人のテナント（サーバーごとに1つのアプリ）があります。このモードでは、パラオブジェクトは変更なしでインデックス化されます（すべてのデータ型は保存されています）が、これにより爆発がマッピングされる可能性があります。
これら2つのインデックスモードのネストされたデータ構造を以下に示します。
// NORMAL MODE // NESTED MODE
{ {
"id": "123", "id": "123",
"appid": "para", "appid": "para",
"type": "custom", "type": "custom",
"properties": { "properties": [
"key1": "value1", {"k": "key1", "v": "value1"},
"key2": { {"k": "key2-subkey1", "v": "subValue1"},
"subkey1": "subValue1" {"k": "numericKey3", "vn": 5}
}, ],
"numericKey3": 5 "_properties": "{"key1":"value1"}..."
} }
}
新しいネストされたインデックスモードに切り替えることは、構成プロパティで行われます。
para.es.es.use_nested_custom_fields = true
「ネストされた」モードを使用する場合のもう1つの利点は、クエリ文字列のネストされたクエリのサポートです。これは非常に便利な機能であり、これを書いている時点で、ElasticSearch（Issue Elastic/Elasticsearch＃11322）にまだ実装されていません。さらに良いことに、ピンポイントの精度でネストされたアレイ内のオブジェクト?q=properties.nestedArray[2].key:valueクエリできます。ネストされたクエリ文字列クエリは、プレフィックスproperties.* 。クエリ文字列クエリの例：
/v1/search?q=term AND properties.owner.age:[* TO 34]
/v1/search?q=properties.owner.name:alice OR properties.owner.pets[1].name=whiskers
注：ネストされたフィールドでのソートは、数値データでのみ機能します。たとえば、フィールドproperties.yearのソート。YEARは機能しますが、 properties.monthでソートすることはありません（「ネストされた」モードにのみ適用されます）。
/v1/_elasticsearchを介してElasticSearch APIを直接呼び出すことができます。有効にするにはpara.es.proxy_enabled = true firstを設定します。次に、 pathパラメーターがElasticSearch APIリソースパスに対応することを指定する必要があります。これは、ElasticSearchへのリクエストGET 、 PUT 、 POST 、 PATCH 、またはDELETEたびに行われます。エンドポイントは/v1/_elasticsearchまたは/v1/_elasticsearch/{path}のいずれかのいずれかのリクエストを受け入れます。ここで、 pathはURLエンコードパスパラメーターです。リクエストパスにクエリパラメーターを追加しないでください? 、代わりに、パラメーターマップとして渡します。
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
ParaClient例：
Response get = paraClient . invokeGet ( "_elasticsearch/" + Utils . urlEncode ( "tweet/_search" ), params );
Response post = paraClient . invokePost ( "_elasticsearch/_count" ,
Entity . json ( Collections . singletonMap ( "query" ,
Collections . singletonMap ( "term" ,
Collections . singletonMap ( "type" , "cat" ))))); pathパラメーターが省略されている場合、デフォルトは_searchになります。
応答オブジェクトは、パラクライアントと互換性があるように変換されます。
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} elasticsearchから生のクエリ応答を取得する場合は、パラメーターgetRawResponse=trueにrequstパスに追加し、url-encodeを追加します。
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
同等に、 ParaClientを使用してクエリパラメーターを追加することで同じことができます。
MultivaluedHashMap<String, String> params = new MultivaluedHashMap<>();
params.putSingle("getRawRequest", "true");
paraClient.invokeGet("_elasticsearch/" + Utils.urlEncode("mytype/_search"), params);
注：このエンドポイントでは認証が必要であり、署名されていないリクエストは許可されていません。 ElasticSearchへのすべての要求には、アプリ識別子が付いていることに注意してください。たとえば、アプリIDが「アプリ：myApp：myApp、paraがhttp://eshost:9200/myapp/{path}でElasticsearchにプロキシリクエストします。
POST /v1/_elasticsearch/reindexを呼び出すことにより、アプリのインデックス全体をゼロから再構築できます。有効にするにはpara.es.proxy_reindexing_enabled = true firstを設定します。この操作は、 ElasticSearchUtils.rebuildIndex()を内部的に実行し、再インネックスされたオブジェクトの数と経過時間を示す応答を返します。
{
"reindexed": 154,
"tookMillis": 365
}
さらに、Reindexに宛先インデックスを指定することができます。これは事前に作成されている必要があります。
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
プラグインはインデックス共有もサポートしています。これにより、Root App Indexは、Flag app.isSharingIndex = trueで作成された他のアプリと共有されます。この機能はpara.es.root_index_sharing_enabled = trueで有効になり、デフォルトでオフになっています。 Root Indexが共有を有効にして作成されると、アプリ間の完全な分離を提供しながら、子供アプリのすべてのドキュメントを特定のシャードに送信するルーティングフィールドを含む特別なエイリアスが作成されます。これは、それぞれ数百のドキュメントを備えた小さなアプリがたくさんある場合に役立ち、アプリごとに1つのインデックスのオーバーヘッドを避けたいと考えています。
Apache 2.0
