para search elasticsearch
v1.41.3
Elasticsearch Plugin für Para
Para wurde als einfaches und modulares Back-End-Rahmen für Objektpersistenz und Abruf konzipiert. Mit dieser Anwendung kann Objekte direkt in einem Datenspeicher (NoSQL) oder einer relationalen Datenbank (RDBMS) gespeichert werden. Außerdem werden diese Objekte automatisch indiziert und durchsucht.
Mit diesem Plugin können Sie Elasticsearch als Suchmaschine für Para verwenden.
Search mit dem offiziellen Elasticsearch Java -Client/v1/_elasticsearch - Weiterlebt alle Anforderungen direkt an Elasticsearch (standardmäßig deaktiviert)| ES -Plugin -Version | Elasticsearch -Unterstützung | OpenSearch -Unterstützung |
|---|---|---|
1.40.0 und höher | 8.x und höher (mit Konfigurationsflag) | 1.0.0 und höher (mit Konfigurationsflag) |
1.39.0 und unten | bis zu 7.15.2 | 1.0.0 und höher |
Nach Version 1.40.0 ist ein Konfigurationsflag erforderlich, um zwischen den beiden verschiedenen Geschmacksrichtungen von Eleasticsearch zu zielen:
para.es.flavor = " elasticsearch "
# ==== OR ==== #
para.es.flavor = " opensearch " Die Standardoption hier ist elasticsearch .
Das Plugin befindet sich auf Maven Central. Hier ist der Maven -Snippet, der in Ihre pom.xml aufgenommen wird:
< dependency >
< groupId >com.erudika</ groupId >
< artifactId >para-search-elasticsearch</ artifactId >
< version >{see_green_version_badge_above}</ version >
</ dependency > Alternativ können Sie das Glas über die lib "Releases" para-xyzwar herunterladen. Para sucht nach Plugins in lib und nimmt das Elasticsearch -Plugin auf.
Hier finden Sie alle Konfigurationseigenschaften für dieses Plugin (diese gehen in Ihre 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 = falseSetzen Sie schließlich die Konfigurationseigenschaft:
para.search = "ElasticSearch"
Dies kann eine Java -Systemeigenschaft oder eine Teil einer Anwendung einer Datei application.conf auf dem Klassenpfad sein. Dies fordert Para an, die Elasticsearch -Implementierung anstelle des Standards (Lucene) zu verwenden.
Neuere Versionen von ES verwenden standardmäßig HTTPS und generieren beim ersten Start ein eindeutiges SSL -Zertifikat. Um eine erfolgreiche Verbindung zu haben, sollten Sie zuerst die generierte CA des ES -Servers zu Ihrem Java -Keystore hinzufügen, um anzugeben, dass Sie diesem Zertifikat vertrauen. Dies ist der Konsolenbefehl, um das zu tun:
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 Setzen Sie schließlich para.es.restclient_scheme = "https" .
Das Elasticsearch -Plugin unterstützt sowohl synchrone (Standard-) als auch asynchrone Indexierungsmodi. Für die synchrone Indexierung wird das Elasticsearch -Plugin eine einzige, blockierende Anforderung über den Client erstellen und auf eine Antwort warten. Dies bedeutet, dass jede Dokumentoperation (Index, Reindedex oder Löschen) eine neue Client -Anforderung aufruft. Für bestimmte Anwendungen kann dies im Elasticsearch -Cluster eine schwere Belastung induzieren. Der Vorteil der synchronen Indexierung ist jedoch das Ergebnis der Anforderung an die Client -Anwendung weitergegeben werden. Wenn die Einstellung para.es.fail_on_indexing_errors auf true festgelegt ist, werden synchrone Anforderungen, die zu einem Fehler führen, mit einem HTTP -Fehlercode an die Clientanwendung aus.
Der asynchrone Indexierungsmodus verwendet den Elasticsearch -BulkProcessor, um alle Anforderungen an den Elasticsearch -Cluster zu beenden. Wenn der asynchrone Modus aktiviert ist, werden alle Dokumentenanforderungen in den BulkProcessor eingespeist, wodurch gelegentlich die Anforderungen an den Cluster gespült werden. Es gibt mehrere konfigurierbare Parameter, um die Flush -Frequenz basierend auf Dokumentenanzahl, Gesamtdokumentgröße (MB) und Gesamtdauer (MS) zu steuern. Da Elasticsearch als nahezu Echtzeit-Suchmaschine konzipiert ist, wird der asynchrone Modus dringend empfohlen. Wenn Sie gelegentliche Dokumentenanfragen gelegentlich erstellen, werden die Last des Elasticsearch -Clusters verringert.
Der asynchrone Indexierungsmodus bietet auch eine ansprechende Funktion zum automatischen Wiederieren von fehlgeschlagenen Indexierungsanforderungen. Wenn Ihr Elasticsearch -Cluster unter starker Belastung steht, kann eine Anfrage zum Index neuer Dokumente abgelehnt werden. Mit der synchronen Indexierung fällt die Belastung in die Client -Anwendung, um die Indexierungsanforderung erneut auszuprobieren. Der Elasticsearch BulkProcessor bietet jedoch eine nützliche Funktion, um die Indexierungsanforderungen automatisch mit exponentieller Backoff zwischen den Wiederholungen erneut zu versorgen. Wenn die Indexanforderung mit einer EsRejectedExecutionException fehlschlägt, wird die Anforderung auf para.es.bulk.max_num_retries Times wiedergegeben. Auch wenn Ihr Anwendungsfall ein hohes Maß an Vertrauen in Bezug auf die Datenkonsistenz zwischen Ihrer Datenbank ( DAO ) und Index ( Search ) erfordert, wird empfohlen, die asynchrone Indexierung mit aktivierenden Wiederholungen zu verwenden. Wenn Sie es vorziehen möchten, eine asynchrone Indexierung zu verwenden, aber den BulkProcessor bei jeder Aufruf von Index/undedex/indexall/undedexall spülen lassen, aktiviert einfach para.es.bulk.flush_immediately . Wenn diese Option aktiviert ist, wird die Flush -Methode des BulkProcessors sofort nach dem Hinzufügen der Dokumente in die Anforderung aufgerufen. Diese Option ist auch nützlich, um Unit -Tests zu schreiben, bei denen Sie sicherstellen, dass die Dokumente sofort spülen.
Dieses Plugin verfügt über zwei Indizierungsmodi: normal und verschachtelt . Der verschachtelte Modus wurde nach V1.28 hinzugefügt, um vor einer möglichen Kartierungxplosion zu schützen, die auftritt, wenn viele Objekte mit vielen verschiedenen benutzerdefinierten Eigenschaften enthalten sind. Dies überlastet die Elasticsearch -Indexmetadaten und kann den gesamten Cluster zum Absturz bringen. Dieser Indexierungsmodus betrifft nur benutzerdefinierte Eigenschaften in Sysprop -Objekten.
Der alte "normale" Modus ist für die meisten Para -Bereitstellungen geeignet, mit nur wenigen Mietern oder einem einzelnen Mieter (eine App pro Server). In diesem Modus werden Para -Objekte ohne Änderung indiziert (alle Datentypen bleiben erhalten), dies könnte jedoch zu einer Mapping -Explosion führen.
Die verschachtelte Datenstruktur für diese beiden Indexierungsmodi ist unten dargestellt:
// 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"}..."
} }
}
Das Umschalten in den neuen verschachtelten Indexierungsmodus erfolgt mit der Konfigurationseigenschaft:
para.es.es.use_nested_custom_fields = true
Ein weiterer Vorteil bei der Verwendung des "verschachtelten" Modus ist die Unterstützung für verschachtelte Abfragen in Abfragebrägern. Dies ist eine wirklich nützliche Funktion, die zum Zeitpunkt des Schreibens dies in Elasticsearch noch nicht implementiert wurde (Issue Elastic/Elasticsearch#11322). Noch besser ist, dass Sie Objekte in verschachtelten Arrays mit punktgener Zeit abfragen können, z ?q=properties.nestedArray[2].key:value . Eine verschachtelte Abfrage für Abfrage -String wird festgestellt, wenn sie ein Feld mit properties.* . Beispiele für Abfragen von Abfragen: Abfragen:
/v1/search?q=term AND properties.owner.age:[* TO 34]
/v1/search?q=properties.owner.name:alice OR properties.owner.pets[1].name=whiskers
HINWEIS: Die Sortierung von verschachtelten Feldern funktioniert nur mit numerischen Daten. Zum Beispiel wird das Sortieren eines properties.year funktionieren, aber die Sortierung von properties.month Month nicht (nur für den "verschachtelten" Modus anwendbar).
Sie können die Elasticsearch -API direkt über /v1/_elasticsearch aufrufen. So setzen Sie es zu aktiven para.es.proxy_enabled = true . Dann müssen Sie angeben, dass der path dem Elasticsearch -API -Ressourcenpfad entspricht. Dies geschieht für jeden GET auf Elasticsearch, PUT , POST , PATCH oder DELETE . Der Endpunkt akzeptiert die Anforderung an /v1/_elasticsearch oder /v1/_elasticsearch/{path} wobei path ein URL-kodierter Pfadparameter ist. Fügen Sie dem Anforderungsweg keine Abfragungsparameter mit hinzu ? Geben Sie sie stattdessen als Parameterkarte über.
GET /v1/_elasticsearch/_search
GET /v1/_elasticsearch/mytype%2f_search
DELETE /v1/_elasticsearch/tweet%2f1
ParaClient Beispiel:
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" ))))); Wenn der path weggelassen wird, wird es standardmäßig _search ausfällt.
Das Antwortobjekt wird so transformiert, dass er mit Para -Clients kompatibel ist und Folgendes aussieht:
{
"page" : 0 ,
"totalHits" : 3 ,
"items" : [ { ... } ]
} Wenn Sie die Reaktion von RAW-Abfragen von Elasticsearch erhalten möchten, fügen Sie den Parameter getRawResponse=true dem Requst-Pfad und auch den URL-Coding hinzu:
GET /v1/_elasticsearch/mytype%2f_search%3FgetRawResponse%3Dtrue
Äquivalent kann das gleiche erfolgen, indem der Abfrageparameter mit ParaClient hinzugefügt wird:
MultivaluedHashMap<String, String> params = new MultivaluedHashMap<>();
params.putSingle("getRawRequest", "true");
paraClient.invokeGet("_elasticsearch/" + Utils.urlEncode("mytype/_search"), params);
Hinweis: Dieser Endpunkt erfordert eine Authentifizierung und nicht signierte Anforderungen sind nicht zulässig. Beachten Sie, dass alle Anfragen an Elasticsearch mit der App -Kennung vorangestellt sind. Wenn beispielsweise die App -ID "App: MyApp" lautet, dann wird Para Anforderungen an Elasticsearch unter http://eshost:9200/myapp/{path} .
Sie können den gesamten App -Index von Grund auf neu aufbauen, indem Sie POST /v1/_elasticsearch/reindex aufrufen. para.es.proxy_reindexing_enabled = true setzen Sie es zu aktivieren. Diese Operation führt ElasticSearchUtils.rebuildIndex() intern aus und gibt eine Antwort zurück, die die Anzahl der gefordexierten Objekte und die verstrichene Zeit angibt:
{
"reindexed": 154,
"tookMillis": 365
}
Darüber hinaus können Sie den Zielindex angeben, um sie zu rESINDEX in die Voraus erstellt worden sein:
POST /v1/_elasticsearch/reindex?destinationIndex=yourCustomIndex
Das Plugin unterstützt auch die Indexfreigabe, wobei der Root App -Index mit anderen Apps gemeinsam genutzt wird, die mit der Flag app.isSharingIndex = true erstellt werden. Diese Funktion ist mit para.es.root_index_sharing_enabled = true aktiviert und ist standardmäßig ausgeschaltet. Wenn der Stammindex mit aktivierter Freigabe erstellt wird, wird ein spezieller Alias erstellt, der ein Routing -Feld enthält, das alle Dokumente einer untergeordneten App an einen bestimmten Shard sendet und gleichzeitig die Gesamtisolation zwischen Apps bereitstellt. Dies ist nützlich, wenn es viele kleinere Apps mit jeweils nur ein paar hundert Dokumenten gibt, und wir möchten den Aufwand eines Index pro App vermeiden.
IndexBasedDAO wurde entfernt, weil es viele Probleme hatte.Apache 2.0
