para search elasticsearch
v1.41.3
Plugin Elasticsearch pour par.
Para a été conçu comme un cadre arrière simple et modulaire pour la persistance et la récupération des objets. Il permet à votre application de stocker des objets directement dans un magasin de données (NOSQL) ou dans toute base de données relationnelle (RDBM) et il index automatiquement ces objets et les rend consultables.
Ce plugin vous permet d'utiliser Elasticsearch comme moteur de recherche pour par.
Search para à l'aide du client officiel de Java Elasticsearch/v1/_elasticsearch - relaie toutes les demandes directement à Elasticsearch (désactivé par défaut)| Version du plugin ES | Support Elasticsearch | Support Opeensearch |
|---|---|---|
1.40.0 et plus | 8.x et supérieur (avec indicateur de configuration) | 1.0.0 et supérieur (avec indicateur de configuration) |
1.39.0 et moins | Jusqu'à 7.15.2 | 1.0.0 et plus |
Après la version 1.40.0 un drapeau de configuration est nécessaire pour le destiné entre les deux saveurs différentes de EleasticSearch:
para.es.flavor = " elasticsearch "
# ==== OR ==== #
para.es.flavor = " opensearch " L'option par défaut ici est elasticsearch .
Le plugin est sur Maven Central. Voici l'extrait Maven à inclure dans votre pom.xml :
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency > Alternativement, vous pouvez télécharger le pot à partir de l'onglet "Releases" ci-dessus, mettez-le dans un dossier lib aux côtés du fichier de guerre du serveur para-xyzwar . Para recherchera des plugins à l'intérieur lib et ramassera le plugin Elasticsearch.
Voici toutes les propriétés de configuration de ce plugin (celles-ci vont dans votre application.conf ):
# ES flavor - elasticsearch or opensearch
para.es.flavor = " elasticsearch "
# 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.restclient_scheme = " http "
para.es.restclient_host = " localhost "
para.es.restclient_port = 9200
# context path of elasticsearch e.g. /es
para.es.restclient_context_path = " "
para.es.sign_requests_to_aws = false
para.es.aws_region = " eu-west-1 "
para.es.fail_on_indexing_errors = false
para.es.track_total_hits = 10000
# if login and password are filled then add for each request
# the Authorization header with basic auth
para.es.basic_auth_login = " "
para.es.basic_auth_password = " "
# 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.proxy_reindexing_enabled = falseEnfin, définissez la propriété de configuration:
para.search = "ElasticSearch"
Il peut s'agir d'une propriété système Java ou d'une partie d'un fichier application.conf sur le chemin de classe. Cela indique à Para d'utiliser l'implémentation Elasticsearch au lieu de la valeur par défaut (Lucene).
Les versions plus récentes de l'ES utilisent HTTPS par défaut et génèrent un certificat SSL unique lors du premier démarrage. Pour avoir une connexion réussie, vous devez d'abord ajouter le CA généré du serveur ES à votre clé de clé Java, indiquant que vous faites confiance à ce certificat. Ceci est la commande de la console pour ce faire:
echo -n |
openssl s_client -connect localhost:9200 |
sed -ne ' /-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p ' > ./ca_elasticsearch.cer &&
keytool -import -alias saelk -file ca_elasticsearch.cer -keystore ${JAVA_HOME} /lib/security/cacerts -storepass changeit Enfin, définissez para.es.restclient_scheme = "https" .
Le plugin Elasticsearch prend en charge les modes d'indexation synchrones (par défaut) et asynchrones. Pour l'indexation synchrone, le plugin Elasticsearch fera une seule demande de blocage via le client et attendra une réponse. Cela signifie que chaque opération de document (index, reindex ou supprimer) invoque une nouvelle demande client. Pour certaines applications, cela peut induire une forte charge sur le cluster Elasticsearch. L'avantage de l'indexation synchrone, cependant, est le résultat de la demande peut être communiquée à l'application client. Si le réglage para.es.fail_on_indexing_errors est défini sur true , des demandes synchrones qui se traduisent par une erreur se propageont à l'application client avec un code d'erreur HTTP.
Le mode d'indexation asynchrone utilise le BulkProcessor BulkProcessor Elasticsearch pour par elle-même toutes les demandes au cluster ElasticSearch. Si le mode asynchrone est activé, toutes les demandes de document seront introduites dans leprocesseur bulk, ce qui rincera les demandes au cluster à l'occasion. Il existe plusieurs paramètres configurables pour contrôler la fréquence de chasse en fonction du nombre de documents, de la taille totale du document (MB) et de la durée totale (MS). Étant donné qu'Elasticsearch est conçu comme un moteur de recherche en temps quasi réel, le mode asynchrone est fortement recommandé. La fabrication de lots de demandes de documents occasionnels et plus importants aidera à réduire la charge sur le cluster Elasticsearch.
Le mode d'indexation asynchrone propose également une fonctionnalité attrayante pour réessayer automatiquement les demandes d'indexation ratées. Si votre cluster Elasticsearch est sous une charge lourde, il est possible qu'une demande d'indexation de nouveaux documents puisse être rejetée. Avec l'indexation synchrone, le fardeau incombe à l'application client pour réessayer la demande d'indexation. Le BulkProcessor Elasticsearch, cependant, propose une fonctionnalité utile pour réessayer automatiquement les demandes d'indexation avec un revers exponentiel entre les tentatives. Si la demande d'index échoue avec un EsRejectedExecutionException , la demande sera remise à para.es.bulk.max_num_retries . Même si votre cas d'utilisation exige un degré élevé de confiance en ce qui concerne la cohérence des données entre votre base de données ( DAO ) et l'index ( Search ), il est toujours recommandé d'utiliser l'indexation asynchrone avec des tentatives activées. Si vous préférez utiliser l'indexation asynchrone, mais que le BulkProcessor a rincé à chaque invocation de l'index / unindex / indexall / unindexall, a simplement activé para.es.bulk.flush_immediately . Lorsque cette option est activée, la méthode Flush du BulkProcessor sera appelée immédiatement après avoir ajouté les documents dans la demande. Cette option est également utile pour rédiger des tests unitaires où vous souhaitez vous assurer que les documents rincent rapidement.
Ce plugin a deux modes d'indexation: normal et imbriqué . Le mode imbriqué a été ajouté après V1.28 pour se protéger contre une éventuelle explosion de cartographie qui se produit lorsqu'il y a beaucoup d'objets avec de nombreuses propriétés personnalisées différentes. Cela surcharge les métadonnées de l'index Elasticsearch et peut écraser l'ensemble du cluster. Ce mode d'indexation affecte uniquement les propriétés personnalisées dans les objets Sysprop .
L'ancien mode "normal" convient à la plupart des déploiements de paragraphe, avec seulement quelques locataires ou un seul locataire (une application par serveur). Dans ce mode, les objets para sont indexés sans modification (tous les types de données sont conservés) mais cela pourrait conduire à une explosion de cartographie.
La structure de données imbriquée pour ces deux modes d'indexation est illustrée ci-dessous:
// 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"}..."
} }
}
Le passage au nouveau mode d'indexation imbriqué se fait avec la propriété de configuration:
para.es.es.use_nested_custom_fields = true
Un autre avantage, lors de l'utilisation du mode "imbriqué", est la prise en charge des requêtes imbriquées dans les chaînes de requête. Il s'agit d'une fonctionnalité vraiment utile qui, au moment de la rédaction, n'a pas encore été implémentée dans Elasticsearch (Issue Elastic / Elasticsearch # 11322). Encore mieux, vous pouvez interroger des objets dans des tableaux imbriqués avec une précision PINPOINT, par exemple ?q=properties.nestedArray[2].key:value . Une requête de chaîne de requête imbriquée est détectée si elle contient un champ avec properties.* . Exemples de requêtes de chaîne de requête:
/v1/search?q=term AND properties.owner.age:[* TO 34]
/v1/search?q=properties.owner.name:alice OR properties.owner.pets[1].name=whiskers
Remarque: Le tri sur les champs imbriqués fonctionne uniquement avec les données numériques. Par exemple, le tri sur properties.month properties.year d'un champ.
Vous pouvez appeler directement l'API ElasticSearch via /v1/_elasticsearch . Pour l'activer, définissez para.es.proxy_enabled = true d'abord. Ensuite, vous devez spécifier le paramètre path correspond au chemin de ressource API ElasticSearch. Ceci est fait pour chaque GET , PUT , POST , PATCH ou DELETE la demande à Elasticsearch. Le point de terminaison accepte la demande à /v1/_elasticsearch ou /v1/_elasticsearch/{path} où path est un paramètre de chemin codé par URL. N'ajoutez pas de paramètres de requête au chemin de demande avec ? Au lieu de cela, passez-les en tant que carte des paramètres.
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
Exemple 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 le paramètre path est omis, il est par défaut à _search .
L'objet de réponse sera transformé pour être compatible avec les clients para et ressemble à ceci:
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} Si vous souhaitez obtenir la réponse de la requête brute de ElasticSearch, ajoutez le paramètre getRawResponse=true au chemin de requste et également encode URL:
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
De manière équivalente, la même chose peut être effectuée en ajoutant le paramètre de requête en utilisant ParaClient :
MultivaluedHashMap<String, String> params = new MultivaluedHashMap<>();
params.putSingle("getRawRequest", "true");
paraClient.invokeGet("_elasticsearch/" + Utils.urlEncode("mytype/_search"), params);
Remarque: Ce point de terminaison nécessite l'authentification et les demandes non signées ne sont pas autorisées. Gardez à l'esprit que toutes les demandes à Elasticsearch sont préfixées avec l'identifiant de l'application. Par exemple, si l'ID de l'application est "App: MyApp, alors para sera proxy demandes à Elasticsearch sur http://eshost:9200/myapp/{path} .
Vous pouvez reconstruire l'index de l'application à partir de zéro en appelant POST /v1/_elasticsearch/reindex . Pour l'activer, définissez para.es.proxy_reindexing_enabled = true d'abord. Cette opération exécute ElasticSearchUtils.rebuildIndex() en interne et renvoie une réponse indiquant le nombre d'objets réindexés et le temps écoulé:
{
"reindexed": 154,
"tookMillis": 365
}
De plus, vous pouvez spécifier l'index de destination pour réindexer, qui doit avoir été créé à l'avance:
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
Le plugin prend également en charge le partage d'index, par lequel l'index de l'application racine est partagé avec d'autres applications qui sont créées avec l' app.isSharingIndex = true . Cette fonctionnalité est activée avec para.es.root_index_sharing_enabled = true et elle est désactivée par défaut. Lorsque l'indice de racine est créé avec le partage activé, un alias spécial est créé pour celui-ci qui contient un champ de routage qui envoie tous les documents d'une application enfant à un éclat particulier, tout en fournissant une isolation totale entre les applications. Ceci est utile lorsqu'il y a beaucoup d'applications plus petites avec seulement quelques centaines de documents chacune et que nous voulons éviter les frais généraux d'un indice par application.
IndexBasedDAO basé auparavant a été supprimé car il a eu beaucoup de problèmes.Apache 2.0
