elastic4s - Elasticsearch Scala Client

Elastic4s is a concise, idiomatic, reactive, type safe Scala client for Elasticsearch. The official Elasticsearch Java client can of course be used in Scala, but due to Java's syntax it is more verbose and it naturally doesn't support classes in the core Scala core library nor Scala idioms such as typeclass support.

Elastic4s's DSL allows you to construct your requests programatically, with syntactic and semantic errors manifested at compile time, and uses standard Scala futures to enable you to easily integrate into an asynchronous workflow. The aim of the DSL is that requests are written in a builder-like way, while staying broadly similar to the Java API or Rest API. Each request is an immutable object, so you can create requests and safely reuse them, or further copy them for derived requests. Because each request is strongly typed your IDE or editor can use the type information to show you what operations are available for any request type.

Elastic4s supports Scala collections so you don't have to do tedious conversions from your Scala domain classes into Java collections. It also allows you to index and read classes directly using typeclasses so you don't have to set fields or json documents manually. These typeclasses are generated using your favourite json library - modules exist for Jackson, Circe, Json4s, PlayJson and Spray Json. The client also uses standard Scala durations to avoid the use of strings or primitives for duration lengths.

Introduction

Elasticsearch (on the JVM) has two interfaces. One is the regular HTTP interface available on port 9200 (by default) and the other is a TCP interface on port 9300 (by default). Historically the Java API provided by Elasticsearch has always been TCP based with the rationale that it saves marshalling requests into JSON and is cluster aware and so can route requests to the correct node. Therefore elastic4s was also TCP based since it delegates requests to the underlying Java client.

Starting with elastic4s 5.2.x a new HTTP client has been added which relies on the Java REST client for connection management, but still uses the familiar elastic4s DSL to build the queries so you don't have to. As of version 5.4.x the HTTP client is now considered production ready after extensive testing on the 5.2 and 5.3 release chains.

Depending on which client you use, you will need to add either elastic-http or elastic-tcp dependencies to your build.

Release

Elastic4s is released for both Scala 2.11 and Scala 2.12. Scala 2.10 support has been dropped starting with the 5.0.x release train. For releases that are compatible with earlier versions of Elasticsearch, search maven central. For more information read Using Elastic4s in your project.

Starting from version 5.0.0, the underlying Elasticsearch TCP Java client has dependencies on Netty, Lucene and others that it does not bring in transitively. The elastic4s tcp client brings in the dependencies for you, but in case anything is missed, you would need to add it to your build yourself.

The second issue is that it uses Netty 4.1. However some popular projects such as Spark and Play currently use 4.0 and there is a breaking change between the two versions. Therefore if you bring in elastic4s tcp (or even just the elasticsearch Java TCP client) you will get NoSuchMethodExceptions if you try to use it with Play or Spark. I am unaware of a workaround at present, until Spark and Play update to the latest version, other than switching to the HTTP client.

The basic usage is that you create an instance of a client and then invoke the execute method with the requests you want to perform. The execute method is asynchronous and will return a standard Scala Future[T] (or use one of the Alternative executors) where T is the response type appropriate for your request type. For example a search request will return a response of type SearchResponse which contains the results of the search.

To create an instance of the HTTP client, use the HttpClient companion object methods. To create an instance of the TCP client, use the TcpClient companion object methods. Requests are the same for either client, but response classes may vary slightly as the HTTP response classes model the returned JSON whereas the TCP response classes wrap the Java client classes.

Requests are created using the elastic4s DSL. For example to create a search request, you would do:

search("index"/"type").query("findthistext")

The DSL methods are located in the ElasticDsl trait which needs to be imported or extended. Although the syntax is identical whether you use the HTTP or TCP client, you must import the appropriate trait (com.sksamuel.elastic4s.ElasticDsl for TCP or com.sksamuel.elastic4s.http.ElasticDsl for HTTP) depending on which client you are using.

Alternative Executors

The default Executor uses scala Futures to execute requests, but there are alternate Executors that can be used by adding appropriate imports. The imports will create an implicit Executor[F] and a Functor[F], where F is some effect type.

Example Application

An example is worth 1000 characters so here is a quick example of how to connect to a node with a client, create an index and index a one field document. Then we will search for that document using a simple text query.

importcom.sksamuel.elastic4s.RefreshPolicyimportcom.sksamuel.elastic4s.embedded.LocalNodeimportcom.sksamuel.elastic4s.http.search.SearchResponseimportcom.sksamuel.elastic4s.http.{RequestFailure, RequestSuccess}
objectArtistIndexextendsApp {
// spawn an embedded node for testingvallocalNode=LocalNode("mycluster", "/tmp/datapath")
// in this example we create a client attached to the embedded node, but// in a real application you would provide the HTTP address to the ElasticClient constructor.valclient= localNode.client(shutdownNodeOnClose =true)
// we must import the dslimportcom.sksamuel.elastic4s.http.ElasticDsl._// Next we create an index in advance ready to receive documents.// await is a helper method to make this operation synchronous instead of async// You would normally avoid doing this in a real program as it will block// the calling thread but is useful when testing
client.execute {
createIndex("artists").mappings(
mapping("modern").fields(
textField("name")
)
)
}.await
// Next we index a single document which is just the name of an Artist.// The RefreshPolicy.Immediate means that we want this document to flush to the disk immediately.// see the section on Eventual Consistency.
client.execute {
indexInto("artists"/"modern").fields("name"->"L.S. Lowry").refresh(RefreshPolicy.Immediate)
}.await
// now we can search for the document we just indexedvalresp= client.execute {
search("artists") query "lowry"
}.await
// resp is a Response[+U] ADT consisting of either a RequestFailure containing the// Elasticsearch error details, or a RequestSuccess[U] that depends on the type of request.// In this case it is a RequestSuccess[SearchResponse]
println("---- Search Results ----")
resp match {
casefailure: RequestFailure=> println("We failed "+ failure.error)
caseresults: RequestSuccess[SearchResponse] => println(results.result.hits.hits.toList)
caseresults: RequestSuccess[_] => println(results.result)
}
// Response also supports familiar combinators like map / flatMap / foreach:
resp foreach (search => println(s"There were ${search.totalHits} total hits"))
client.close()
}

Near Real-time search results

When you index a document in Elasticsearch, it is not normally immediately available to be searched, as a refresh has to happen to make it available for the search API. By default a refresh occurs every second but this can be increased if needed. Note that this impacts only the visibility of newly indexed documents when using the search API and has nothing to do with data consistency and durability. Another option, which you saw in the quick start guide, was to set the refresh policy to IMMEDIATE which will force a refresh straight after the index operation. You shouldn't use IMMEDIATE for heavy loads as you'll cause contention with Elasticsearch refreshing too often. It is also possible to use WAIT_UNTIL so that no refresh is forced, but the index request will return only after the new document is available for search.

For more in depth examples keep reading.

Syntax

Here is a list of the common requests and the syntax used to create them and whether they are supported by the TCP or HTTP client. If the HTTP client does not support them, you will need to fall back to the TCP, or use the Java client and build the JSON yourself. Or even better, raise a PR with the addition. For more details on each request click through to the readme page. For options that are not yet documented, refer to the Elasticsearch documentation asthe DSL closely mirrors the standard Java API / REST API.

Connecting to a Cluster

To connect to a stand alone elasticsearch cluster we use the methods on the HttpClient or TcpClient companion objects. For example, TcpClient.transport or HttpClient.apply. These methods accept an instance of ElasticsearchClientUri which specifies the host, port and cluster name of the cluster. The cluster name does not need to be specified if it is the default, which is "elasticsearch" but if you changed it you must specify it in the uri.

Please note that the TCP interface uses port 9300 and HTTP uses 9200 (unless of course you have changed these in your cluster).

Here is an example of connecting to a TCP cluster with the standard settings.

valclient=TcpClient.transport(ElasticsearchClientUri("host1", 9300))

For multiple nodes it's better to use the elasticsearch client uri connection string. This is in the format "elasticsearch://host1:port2,host2:port2,...?param=value&param2=value2". For example:

If you need to pass settings to the client, then you need to invoke transport with a settings object. For example to specify the cluster name (if you changed the default then you must specify the cluster name).

X-Pack-Security

Elastic4s also supports the xpack-security add on (TCP client only). To use this, add the elastic-xpack-security dependency to your build and create a client using the XPackElasticClient object instead of the ElasticClient object. Eg,

scala

val client = XPackElasticClient(settings, uri, <plugins>...)

If you are using SBT then you might need to add a resolver to the elasticsearch repo.

Embedded Node

A locally configured node and client can be created by including the elastic4s-embedded module. Then a local node can be started by invoking LocalNode() with the cluster name and data path. From the local node we can return a handle to the client by invoking the client function.

If shutdownNodeOnClose is true, then once close is called on the client, the local node will be stopped. Otherwise you will manage the lifecycle of the local node yourself (stopping it before exiting the process).

Create Index

All documents in Elasticsearch are stored in an index. We do not need to tell Elasticsearch in advance what an index will look like (eg what fields it will contain) as Elasticsearch will adapt the index dynamically as more documents are added, but we must at least create the index first.

To create an index called "places" that is fully dynamic we can simply use:

client.execute { createIndex("places") }

We can optionally set the number of shards and / or replicas

client.execute { createIndex("places") shards 3 replicas 2 }

Sometimes we want to specify the properties of the fields in the index in advance. This allows us to manually set the type of the field (where Elasticsearch might infer something else) or set the analyzer used, or multiple other options

Then Elasticsearch is configured with those mappings for those fields only. It is still fully dynamic and other fields will be created as needed with default options. Only the fields specified will have their type preset.

Analyzers

Analyzers control how Elasticsearch parses the fields for indexing. For example, you might decide that you want whitespace to be important, so that "band of brothers" is indexed as a single "word" rather than the default which is to split on whitespace. There are many advanced options available in analayzers. Elasticsearch also allows us to create custom analyzers. For more details read about the DSL support for analyzers.

Indexing

To index a document we need to specify the index and type and optionally we can set an id. If we don't include an id then elasticsearch will generate one for us. We must also include at least one field. Fields are specified as standard tuples.

There are many additional options we can set such as routing, version, parent, timestamp and op type. See official documentation for additional options, all of which exist in the DSL as keywords that reflect their name in the official API.

Indexing Typeclass

Sometimes it is useful to index directly from your domain model, and not have to create maps of fields inline. For this elastic4s provides the Indexable typeclass. Simply provide an implicit instance of Indexable[T] in scope for any class T that you wish to index, and then you can use doc(t) on the index request. For example:

Some people prefer to write typeclasses manually for the types they need to support. Other people like to just have it done automagically. For those people, elastic4s provides extensions for the well known Scala Json libraries that can be used to generate Json generically.

Simply add the import for your chosen library below and then with those implicits in scope, you can now pass any type you like to doc and an Indexable will be derived automatically.

HitReader Typeclass

By default Elasticsearch search responses contain an array of SearchHit instances which contain things like the id, index, type, version, etc as well as the document source as a string or map. Elastic4s provides a means to convert these back to meaningful domain types quite easily using the HitReader[T] typeclass.

Provide an implementation of this typeclass, as an in scope implicit, for whatever type you wish to marshall search responses into, and then you can call to[T] or safeTo[T] on the response. The difference between to and safeTo is that to will drop any errors and just return successful conversions, whereas safeTo returns a sequence of Either[Throwable, T].

This is basically the inverse of the Indexable typeclass. And just like Indexable, the json modules provide implementations out of the box for any types. The imports are the same as for the Indexable typeclasses.

As a bonus feature of the Jackson implementation, if your domain object has fields called _timestamp, _id, _type, _index, or _version then those special fields will be automatically populated as well.

Highlighting

Elasticsearch can annotate results to show which part of the results matched the queries by using highlighting. Just think when you're in google and you see the snippets underneath your results - that's what highlighting does.

We can use this very easily, just add a highlighting definition to your search request, where you set the field or fields to be highlighted. Viz:

All very straightforward. There are many options you can use to tweak the results. In the example above I have simply set the snippets to be taken from the field called "body" and to have max length 20. You can set the number of fragments to return, seperate queries to generate them and other things. See the elasticsearch page on highlighting for more info.

Get

Sometimes we don't want to search and want to retrieve a document directly from the index by id. In this example we are retrieving the document with id 'coldplay' from the bands/rock index and type.

client.execute {
get("coldplay").from("bands"/"rock")
}

We can get multiple documents at once too. Notice the following multiget wrapping block.

Deleting

In the rare case that we become tired of a band we might want to remove them. Naturally we wouldn't want to remove Chris Martin and boys so we're going to remove U2 instead. We think they're a little past their best (controversial). This operation assumes the id of the document is "u2".

client.execute {
delete("u2").from("bands/rock")
}

We can take this a step further by deleting by a query rather than id. In this example we're deleting all bands where their type is pop.

Bulk Operations

Elasticsearch is fast. Roundtrips are not. Sometimes we want to wrestle every last inch of performance and a useful way to do this is to batch up requests. Elastic has guessed our wishes and created the bulk API. To do this we simply wrap index, delete and update requests using the bulk keyword and pass to the execute method in the client.

A single HTTP or TCP request is now needed for 4 operations. In addition Elasticsearch can now optimize the requests, by combinging inserts or using aggressive caching.

The example above uses simple documents just for clarity of reading; the usual optional settings can still be used. See more information on the Bulk.

Json Output

It can be useful to see the json output of requests in case you wish to tinker with the request in a REST client or your browser. It can be much easier to tweak a complicated query when you have the instant feedback of the HTTP interface.

Elastic4s makes it easy to get this json where possible. Simply invoke the show method on the client with a request to get back a json string. Eg:

Not all requests have a json body. For example get-by-id is modelled purely by http query parameters, there is no json body to output. And some requests aren't supported by the show method - you will get an implicit not found error during compliation if that is the case

Also, as a reminder, the TCP client does not send JSON to the nodes, it uses a binary protocol, so the provided JSON should be used as a debugging tool only. For the HTTP client the output is exactly what is sent.

Synchronous Operations

All operations are normally asynchronous. Sometimes though you might want to block - for example when doing snapshots or when creating the initial index. You can call .await on any operation to block until the result is ready. This is especially useful when testing.

Search Iterator

Sometimes you may wish to iterate over all the results in a search, without worrying too much about handling futures, and re-requesting via a scroll. The SearchIterator will do this for you, although it will block between requests. A search iterator is just an implementation of scala.collection.Iterator backed by elasticsearch queries.

To create one, use the iterate method on the companion object, passing in the http client, and a search request to execute. The search request must specify a keep alive value (which is used by elasticsearch for scrolling).

For instance, in the above we are bringing back all documents in the index, 50 results at a time, marshalled into instances of MyType using the implicit HitReader (see the section on HitReaders). If you want just the raw elasticsearch Hit object, then use SearchIterator.hits

Note: Whenever the results in a particular batch have been iterated on, the SearchIterator will then execute another query for the next batch and block waiting on that query. So if you are looking for a pure non blocking solution, consider the reactive streams implementation. However, if you just want a quick and simple way to iterate over some data without bringing back all the results at once SearchIterator is perfect.

DSL Completeness

As it stands the Scala DSL covers all of the common operations - index, create, delete, delete by query, search, validate, percolate, update, explain, get, and bulk operations. There is good support for the various settings for each of these - more so than the Java client provides in the sense that more settings are provided in a type safe manner.

However there are settings and operations (mostly admin / cluster related) that the DSL does not yet cover (pull requests welcome!). In these cases it is necessary to drop back to the Java API. This can be done by calling .java on the client object to get the underlying java elastic client,

This way you can still access everything the normal Java client covers in the cases where the Scala DSL is missing a construct, or where there is no need to provide a DSL.

Elastic Reactive Streams

Elastic4s has an implementation of the reactive streams api for both publishing and subscribing that is built using Akka. To use this, you need to add a dependency on the elastic4s-streams module.

There are two things you can do with the reactive streams implementation. You can create an elastic subscriber, and have that stream data from some publisher into elasticsearch. Or you can create an elastic publisher and have documents streamed out to subscribers.

Now you can add subscribers to this publisher. They can of course be any type that adheres to the reactive-streams api, so you could stream out to a mongo database, or a filesystem, or whatever custom type you want.

publisher.subscribe(someSubscriber)

If you just want to stream out an entire index then you can use the overloaded form:

val publisher = client.publisher("index1", keepAlive = "1m")

Subscription

An elastic subcriber can be created that will stream a request to elasticsearch for each item produced by a publisher. The subscriber can create index, update, or delete requests, so is a good way to synchronize datasets.

import ReactiveElastic._

And make sure you have an Akka Actor System in implicit scope.

implicit val system = ActorSystem()

Then create a subscriber, specifying the following parameters:

A type parameter that is the type of object that the publisher will provide

How many documents should be included per index batch (10-100 is usually good)

How many concurrent batches should be in flight (usually around the number of cores)

An optional ResponseListener that will be notified for each item that was successfully acknowledged by the es cluster

An optional function that will be called once the subscriber has received all data. Defaults to a no-op

An optional function to call if the subscriber encouters an error. Defaults to a no-op.

In addition there should be a further implicit in scope of type RequestBuilder[T] that will accept objects of T (the type produced by your publisher) and build an index, update, or delete request suitable for dispatchin to elasticsearch.

implicitvalbuilder=newRequestBuilder[SomeType] {
importElasticDsl._// the request returned doesn't have to be an index - it can be anything supported by the bulk apidefrequest(t: T):BulkCompatibleRequest= index into "index"/"type" fields ....
}

Building and Testing

This project is built with SBT. So to build

sbt compile

And to test

sbt test

For the tests to work you will need to run a local elastic instance on port 9200. One easy way of doing this is to use docker: docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -e "path.repo=/tmp" docker.elastic.co/elasticsearch/elasticsearch-oss:6.1.2 replacing that 6.1.2 with whatever version is current.

6.1.0

Wrapping apache client errors in JavaRestClientExceptionWrapper so we know which client caused them #1165

Added AggReader derivation for Circe module

Fixed completion suggestion option #1173

Add multi criteria order in term aggregation #1172

Added sum bucket agg for http. #1164

Add ExecutionContext param to execute (with default value) #1167

Stored scripts fix #1162

6.0.4

Added to[T] and safeTo[T] on aggregations #1156

Added _shard, _node, and _routing to search hit #1160

java.lang.NullPointerException in ElasticError.parse #1159

6.0.3

Added track_total_hits option to searches

Added get segment to http api

6.0.2

Added snapshots and repositories to the http api

6.0.1

Added document exists api #1155

Fix partitioned terms aggregation (fixes #1153)

6.0.0

HTTP Client should now be the first choice client. The TCP Client has been deprecated as it will be removed in version 7 of elasticsearch itself. See https://www.elastic.co/blog/elasticsearch-5-6-0-released. Specifically, HTTP client will become the official way for Java applications to communicate with Elasticsearch, replacing the Transport Client, which will be removed in Elasticsearch 7.0..

HTTP Client no longer has a dependency on the main elasticsearch jars - no more version clashes (netty!) and a hugely reduced footprint.

HTTP operations now return Either[RequestFailure, RequestSuccess[U]] for better error handling. Each of RequestFailure and RequestSuccess contain the http status code, the full json response body, and any http headers, in addition to either the error details or the request resposne type.

Deprecated implicit conversion of a tuple to an index/type has been removed. So instead of "index" -> "type", you should use "index" / "type", which has been the default since 2.4.0. Or even better, don't use the type at all anymore, see point above.

The String field type has been removed, which has been deprecated since 5.0.0. Use textField or keywordField.

Added doc values to search requests

Reworked the HTTP aggregation response API to support better types and subaggs

disableCoord has been removed from bool and common term queries

Added getIndex request type

getAliases is now overloaded to accept seq of Index and Alias objects to make it clearer how it works. The existing getAlias is deprecated.

date_range, and extended_stats aggregations have been implemented for the http client

1.6.2

Added show typeclasses for search, create index, into into, validate, count, and percolate to allow easy debugging of the json of requests.

1.5.15

Added matched_fields and highlight filter to highlighter

1.6.1

Added IterableSearch for iterating over a scroll

Enhanced multiget dsl to include routing, version and field options

Added rich result for GetAliasResponse

Added context queries to suggestions

Breaking change: Changed syntax of suggestions to be clearer and allow for type safe results

Allow setting analyzer by name on matchphraseprefix

Added singleMethodSyntax variant, eg indexInto(index) rather than index into index

Added re-write to validate

Added filter support to alias (previously only the java client filters were supported)

Added cluster settings api

Added field stats api

Addd docValuesFormat to timestamp mapping

Added matched_fields and highlight filter to highlighter

Supported stopwords_list in filter

Reworked testkit to allow more configuration over the creating of the test clients

Used By

Barclays Bank

HSBC

Shazaam

Graphflow

Hotel Urbano

Immobilien Scout

Deutsche Bank

Goldman Sachs

HMRC

Canal+

AOE

Starmind

Raise a PR to add your company here

YourKit supports open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of YourKit Java Profiler and YourKit .NET Profiler, innovative and intelligent tools for profiling Java and .NET applications.

Contributions

Contributions to elastic4s are always welcome. Good ways to contribute include:

Raising bugs and feature requests

Fixing bugs and enhancing the DSL

Improving the performance of elastic4s

Adding to the documentation

License

This software is licensed under the Apache 2 license, quoted below.
Copyright 2013-2016 Stephen Samuel
Licensed under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations under
the License.