para search elasticsearch v5
v1.36.1
Elasticsearch 5.x plugin para parágrafo
Este projeto está preter
O PARA foi projetado como uma estrutura de back-end simples e modular para persistência e recuperação de objetos. Ele permite que seu aplicativo armazene objetos diretamente em um armazenamento de dados (NOSQL) ou qualquer banco de dados relacional (RDBMS) e também indexa automaticamente esses objetos e os torna pesquisáveis.
Este plug -in permite que você use o Elasticsearch como mecanismo de pesquisa para o para e é compatível apenas com a versão 5.x do Elasticsearch .
Search e suporta o cliente de transporteDAO para que você possa usar o Elasticsearch como um banco de dados (evite na produção!)/v1/_elasticsearch - retransmite todas as solicitações diretamente para o Elasticsearch (desativado por padrão) O plugin está no Maven Central. Aqui está o snippet maven a ser incluído no seu pom.xml :
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch-v5</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency > Como alternativa, você pode baixar o jar na guia "Lançamentos" acima, coloque-o em uma pasta lib ao lado do arquivo de guerra do servidor para-xyzwar . O Para procurará plugins dentro lib e pegará o plug -in Elasticsearch.
Aqui estão todas as propriedades de configuração deste plug -in (elas entram no seu 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 = 9200Finalmente, defina a propriedade Config:
para.search = "ElasticSearch"
Isso pode ser uma propriedade do sistema Java ou parte de um arquivo application.conf no ClassPath. Isso diz ao Pará para usar a implementação do Elasticsearch em vez do padrão (Lucene).
O plug -in Elasticsearch suporta modos de indexação síncrona (padrão) e assíncrona. Para indexação síncrona, o plug -in Elasticsearch fará uma única solicitação de bloqueio através do cliente e aguardará uma resposta. Isso significa que cada operação de documento (índice, reindex ou exclusão) chama uma nova solicitação do cliente. Para determinadas aplicações, isso pode induzir carga pesada no cluster Elasticsearch. A vantagem da indexação síncrona, no entanto, é o resultado da solicitação pode ser comunicada de volta ao aplicativo do cliente. Se a configuração para.es.fail_on_indexing_errors estiver definida como true , solicitações síncronas que resultam em um erro se propagam de volta ao aplicativo cliente com um código de erro HTTP.
O modo de indexação assíncrona usa o elasticsearch BulkProcessor para em lote todas as solicitações ao cluster Elasticsearch. Se o modo assíncrono estiver ativado, todas as solicitações de documentos serão alimentadas no processador de volume, que liberarão as solicitações no cluster de vez em quando. Existem vários parâmetros configuráveis para controlar a frequência de descarga com base na contagem de documentos, tamanho total do documento (MB) e duração total (MS). Como o Elasticsearch é projetado como um mecanismo de pesquisa quase em tempo real, o modo assíncrono é altamente recomendado. Fazer lotes ocasionais e maiores de solicitações de documentos ajudará a reduzir a carga no cluster Elasticsearch.
O modo de indexação assíncrona também oferece um recurso atraente para repetir automaticamente as solicitações de indexação com falha. Se o seu cluster Elasticsearch estiver sob carga pesada, é possível que uma solicitação para indexar novos documentos possa ser rejeitada. Com a indexação síncrona, a carga cai no aplicativo cliente para tentar a solicitação de indexação novamente. O BulkProcessor do Elasticsearch, no entanto, oferece um recurso útil para repetir automaticamente solicitações de indexação automaticamente com o retorno exponencial entre as tentativas. Se a solicitação de índice falhar com uma EsRejectedExecutionException , a solicitação será julgada para para.es.bulk.max_num_retries Times. Mesmo que o seu caso de uso exija um alto grau de confiança em relação à consistência dos dados entre o seu DAO e a pesquisa, ainda é recomendável usar indexação assíncrona com tentativas ativadas. Se você preferir usar a indexação assíncrona, mas fizer com que o processor da massa seja liberado em todas as invocação de índice/UNIndex/indexall/UnIndexall, simplesmente habilitou para.es.bulk.flush_immediately . Quando esta opção estiver ativada, o método de descarga do BulkProcessor será chamado imediatamente após a adição dos documentos na solicitação. Esta opção também é útil para gravar testes de unidade, onde você deseja garantir que os documentos funcionem prontamente.
Este plug -in possui dois modos de indexação: normal e aninhado . O modo aninhado foi adicionado após a v1.28 para proteger contra uma possível explosão de mapeamento que acontece quando há muitos objetos com muitas propriedades personalizadas diferentes. Isso sobrecarrega os metadados do índice Elasticsearch e pode travar todo o cluster. Esse modo de indexação afeta apenas as propriedades personalizadas em objetos Sysprop .
O antigo modo "normal" é adequado para a maioria das implantações do PARA, com apenas alguns inquilinos ou um único inquilino (um aplicativo por servidor). Nesse modo, os objetos PARA são indexados sem modificação (todos os tipos de dados são preservados), mas isso pode levar a uma explosão de mapeamento.
A estrutura de dados aninhada para esses dois modos de indexação é mostrada abaixo:
// 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"}..."
} }
}
A mudança para o novo modo de indexação aninhada é feita com a propriedade de configuração:
para.es.es.use_nested_custom_fields = true
Outro benefício, ao usar o modo "aninhado", é o suporte para consultas aninhadas em cadeias de consultas. Esse é um recurso realmente útil que, no momento em que escrevia isso, ainda não foi implementado no Elasticsearch (emissão de elasticidade/elasticsearch#11322). Melhor ainda, você pode consultar objetos dentro de matrizes aninhadas com precisão Pinpoint, por exemplo ?q=properties.nestedArray[2].key:value . Uma consulta de sequência de consulta aninhada é detectada se contiver um campo com properties.* . Exemplos de consultas de string de consulta:
/v1/search?q=term AND properties.owner.age:[* TO 34]
/v1/search?q=properties.owner.name:alice OR properties.owner.pets[1].name=whiskers
Nota: A classificação em campos aninhados funciona apenas com dados numéricos. Por exemplo, a classificação em um campo properties.year O ano funcionará, mas a classificação no properties.month não (aplicável apenas ao modo "aninhado").
Você pode chamar diretamente a API Elasticsearch através do /v1/_elasticsearch . Para ativar, defina para.es.proxy_enabled = true primeiro. Em seguida, você deve especificar o parâmetro path corresponde ao caminho de recurso da API Elasticsearch. Isso é feito para cada solicitação GET , PUT , POST , PATCH ou DELETE para Elasticsearch. O endpoint aceita a solicitação para /v1/_elasticsearch ou /v1/_elasticsearch/{path} onde path é um parâmetro de caminho codificado por URL. Não adicione parâmetros de consulta ao caminho de solicitação ? , em vez disso, passe -os como um mapa de parâmetro.
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
Exemplo 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" ))))); Se o parâmetro path for omitido, ele padronizará para _search .
O objeto de resposta será transformado para ser compatível com os clientes do Para se parece com o seguinte:
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} Se você deseja obter a resposta de consulta bruta do Elasticsearch, adicione o parâmetro getRawResponse=true ao caminho de requst e também o URL-Encode:
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
Equivalentemente, o mesmo pode ser feito adicionando o parâmetro de consulta usando ParaClient :
MultivaluedHashMap<String, String> params = new MultivaluedHashMap<>();
params.putSingle("getRawRequest", "true");
paraClient.invokeGet("_elasticsearch/" + Utils.urlEncode("mytype/_search"), params);
Nota: Este terminal requer autenticação e solicitações não assinadas não são permitidas. Lembre -se de que todas as solicitações para o Elasticsearch são prefixadas com o identificador de aplicativos. Por exemplo, se o ID do aplicativo for "App: MyApp, o para solicitações proxy para o Elasticsearch em http://eshost:9200/myapp/{path} .
Você pode reconstruir o índice de aplicativos inteiro do zero chamando POST /v1/_elasticsearch/reindex . Para ativar, defina para.es.proxy_reindexing_enabled = true primeiro. Esta operação executa ElasticSearchUtils.rebuildIndex() internamente e retorna uma resposta indicando o número de objetos reindexados e o tempo decorrido:
{
"reindexed": 154,
"tookMillis": 365
}
Além disso, você pode especificar o índice de destino para o Reindex, que deve ter sido criado com antecedência:
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
O plug -in também suporta compartilhamento de índices, pelo qual o índice de aplicativos root é compartilhado com outros aplicativos criados com o flag app.isSharingIndex = true . Esse recurso é ativado com para.es.root_index_sharing_enabled = true e está desativado por padrão. Quando o índice raiz é criado com o compartilhamento ativado, um alias especial é criado para ele que contém um campo de roteamento que envia todos os documentos de um aplicativo infantil para um Shard específico, fornecendo isolamento total entre os aplicativos. Isso é útil quando há muitos aplicativos menores com apenas algumas centenas de documentos cada e queremos evitar a sobrecarga de um índice por aplicativo.
Apache 2.0
