para search elasticsearch v5
v1.36.1
Elasticsearch 5.x complemento para para
Este proyecto está en desuso y ya no se mantendrá. Utilice el último complemento para Elasticsearch
Para fue diseñado como un marco de fondo simple y modular para la persistencia y recuperación de objetos. Permite que su aplicación almacene objetos directamente en un almacén de datos (NoSQL) o cualquier base de datos relacional (RDBMS) y también indexa automáticamente esos objetos y los hace buscar.
Este complemento le permite usar ElasticSearch como motor de búsqueda para el para y solo es compatible con la versión 5.x de Elasticsearch .
Search y admite el cliente de transporteDAO para que pueda usar ElasticSearch como una base de datos (¡evite en producción!)/v1/_elasticsearch : transmite todas las solicitudes directamente a Elasticsearch (deshabilitado de forma predeterminada) El complemento está en Maven Central. Aquí está el fragmento Maven para incluir en su pom.xml :
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch-v5</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency > Alternativamente, puede descargar el JAR de la pestaña "Libraciones" arriba, colóquelo en una carpeta lib junto con el archivo de guerra del servidor para-xyzwar . Para buscará complementos dentro de lib y recogerá el complemento Elasticsearch.
Estas son todas las propiedades de configuración para este complemento (estas van dentro de su 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, configure la propiedad de configuración:
para.search = "ElasticSearch"
Esta podría ser una propiedad del sistema Java o parte de un archivo application.conf en el classpath. Esto le dice a PARA que use la implementación de ElasticSearch en lugar de la predeterminada (Lucene).
El complemento ElasticSearch admite modos de indexación sincrónicos (predeterminados) y asincrónicos. Para la indexación síncrona, el complemento Elasticsearch hará una sola solicitud de bloqueo a través del cliente y esperará una respuesta. Esto significa que cada operación de documento (índice, reindex o eliminar) invoca una nueva solicitud del cliente. Para ciertas aplicaciones, esto puede inducir una carga pesada en el clúster Elasticsearch. Sin embargo, la ventaja de la indexación sincrónica es el resultado de la solicitud se puede comunicar nuevamente a la aplicación del cliente. Si la configuración para.es.fail_on_indexing_errors se establece en true , las solicitudes sincrónicas que resultan en un error se propagarán a la aplicación del cliente con un código de error HTTP.
El modo de indexación asíncrona utiliza el bulkprocessor Elasticsearch para un montón de todas las solicitudes al clúster Elasticsearch. Si el modo asíncrono está habilitado, todas las solicitudes de documentos se alimentarán en el bulkprocessor, que en ocasiones descargará las solicitudes al clúster. Hay varios parámetros configurables para controlar la frecuencia de descarga basada en el recuento de documentos, el tamaño total del documento (MB) y la duración total (MS). Dado que ElasticSearch está diseñado como un motor de búsqueda casi en tiempo real, el modo asíncrono es muy recomendable. Hacer lotes ocasionales y más grandes de solicitudes de documentos ayudará a reducir la carga en el clúster Elasticsearch.
El modo de indexación asincrónica también ofrece una característica atractiva para volver a intentar automáticamente las solicitudes de indexación fallidas. Si su clúster ElasticSearch está bajo una carga pesada, es posible que se pueda rechazar una solicitud para indexar nuevos documentos. Con la indexación síncrona, la carga recae en la aplicación del cliente para probar la solicitud de indexación nuevamente. Sin embargo, el bulkprocessor Elasticsearch ofrece una característica útil para volver a intentar automáticamente las solicitudes de indexación con retroceso exponencial entre reintentos. Si la solicitud de índice falla con un EsRejectedExecutionException , la solicitud se volverá a tomar a para.es.bulk.max_num_retries Times. Incluso si su caso de uso exige un alto grado de confianza con respecto a la consistencia de los datos entre su DAO y la búsqueda, aún se recomienda utilizar la indexación asíncrona con reintentos habilitados. Si prefiere usar la indexación asíncrona pero el bulkprocessor se enjuague en cada invocación de índice/unidex/indexall/unindexall, simplemente habilitó para.es.bulk.flush_immediately . Cuando esta opción está habilitada, se llamará al método de descarga del bulkprocessor inmediatamente después de agregar los documentos en la solicitud. Esta opción también es útil para escribir pruebas unitarias donde desea asegurar que los documentos descarguen rápidamente.
Este complemento tiene dos modos de indexación: normales y anidados . El modo anidado se agregó después de V1.28 para proteger contra una posible explosión de mapeo que ocurre cuando hay muchos objetos con muchas propiedades personalizadas diferentes en ellos. Esto sobrecarga los metadatos del índice Elasticsearch y puede bloquear todo el clúster. Este modo de indexación solo afecta las propiedades personalizadas en los objetos Sysprop .
El antiguo modo "normal" es adecuado para la mayoría de las implementaciones para, con solo unos pocos inquilinos o un solo inquilino (una aplicación por servidor). En este modo, los objetos PARA se indexan sin modificación (se conservan todos los tipos de datos) pero esto podría conducir a una explosión de mapeo.
La estructura de datos anidada para estos dos modos de indexación se muestra a continuación:
// 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"}..."
} }
}
El cambio al nuevo modo de indexación anidada se realiza con la propiedad de configuración:
para.es.es.use_nested_custom_fields = true
Otro beneficio, cuando se usa el modo "anidado", es el soporte para consultas anidadas en las cadenas de consultas. Esta es una característica realmente útil que, al momento de escribir esto, aún no se ha implementado en Elasticsearch (emisión elastic/elasticsearch#11322). Aún mejor, puede consultar objetos dentro de matrices anidadas con precisión punta, por ejemplo ?q=properties.nestedArray[2].key:value . Se detecta una consulta de cadena de consulta anidada si contiene un campo con properties.* . Ejemplos de consultas de cadena 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: La clasificación en campos anidados solo funciona con datos numéricos. Por ejemplo, la clasificación en properties.month properties.year de un campo.
Puede llamar directamente a la API de Elasticsearch a través de /v1/_elasticsearch . Para habilitarlo establecer para.es.proxy_enabled = true primero. Entonces debe especificar que el parámetro path corresponde a la ruta de recursos de la API de ElasticSearch. Esto se hace para cada solicitud GET , PUT , POST , PATCH o DELETE a Elasticsearch. El punto final acepta solicitud a /v1/_elasticsearch o /v1/_elasticsearch/{path} donde path es un parámetro de ruta codificado por URL. ¿No agregue los parámetros de consulta a la ruta de solicitud ? , en cambio, paselos como un mapa de parámetros.
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
Ejemplo 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" ))))); Si se omite el parámetro path , es predeterminado a _search .
El objeto de respuesta se transformará para ser compatible con los clientes para y se ve así:
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} Si desea obtener la respuesta de consulta sin procesar de ElasticSearch, agregue el parámetro getRawResponse=true a la ruta Requst y también la url-endode:
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
De manera equivalente, lo mismo se puede hacer agregando el 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 punto final requiere autenticación y no se permiten solicitudes sin firmar. Tenga en cuenta que todas las solicitudes a ElasticSearch tienen el prefijo del identificador de la aplicación. Por ejemplo, si la identificación de la aplicación es "Aplicación: MyApp, entonces PARA proxyará solicitudes a ElasticSearch en http://eshost:9200/myapp/{path} .
Puede reconstruir todo el índice de aplicaciones desde cero llamando POST /v1/_elasticsearch/reindex . Para habilitarlo, establecer para.es.proxy_reindexing_enabled = true primero. Esta operación ejecuta ElasticSearchUtils.rebuildIndex() internamente, y devuelve una respuesta que indica el número de objetos reindexados y el tiempo transcurrido:
{
"reindexed": 154,
"tookMillis": 365
}
Además, puede especificar el índice de destino para reindex en, que debe haberse creado de antemano:
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
El complemento también admite el intercambio de índices, por el cual el índice de aplicaciones raíz se comparte con otras aplicaciones que se crean con el indicador app.isSharingIndex = true . Esta característica está habilitada con para.es.root_index_sharing_enabled = true y está apagado de forma predeterminada. Cuando el índice raíz se crea con el intercambio habilitado, se crea un alias especial para ello que contiene un campo de enrutamiento que envía todos los documentos de una aplicación infantil a un fragmento particular, al tiempo que proporciona un aislamiento total entre aplicaciones. Esto es útil cuando hay muchas aplicaciones más pequeñas con solo unos pocos cientos de documentos cada una y queremos evitar la sobrecarga de un índice por aplicación.
Apache 2.0
