The Future of Attachments for Elasticsearch and .NET

For a long time, Elasticsearch has supported the indexing of attachments through the mapper-attachments plugin. Installing this plugin has provided the capability to index Word documents, PDFs as well as many other text-based document attachments, extracting the content from each file including metadata such as content type, author and keywords and making it searchable in Elasticsearch.

The Not Too Distant Past

Working with the mapper-attachments plugin has historically been a slightly awkward affair with NEST, the official .NET Elasticsearch high level client. From NEST 2.3.3 onwards, we've introduced an Attachment type to make working with attachments a much smoother experience. In this post, we'll walk through some typical use cases in working with the plugin and the Attachment type with Elasticsearch 5.0, and provide an introduction to the ingest-attachment processor plugin, one of the processors available in the suite of processors for the ingest node. Since the mapper-attachments plugin is deprecated in 5.0 and will be removed in 6.0, the ingest-attachment processor plugin is the recommended way to index attachments in Elasticsearch 5.0.

Installation

To get started with indexing attachments, the first step is to install the mapper-attachments plugin. For the purposes of this post, I'm going to use Elasticsearch 5.0. As with all plugins in Elasticsearch, installation is handled by calling the elasticsearch-plugin.bat script within the Elasticsearch bin directory

elasticsearch-plugin.bat install mapper-attachments

After successfully installing the plugin, it will be available to use when the node is started, or shutdown and restarted. If you're using the plugin with a version of Elasticsearch prior to 2.2, a specific version of the mapper-attachments plugin will be needed; consult the legacy documentation to understand which version needs to be installed for your environment.

Document Definition and Mapping

Once the plugin is installed and our node is running, we're all ready to index our first attachment. To keep things simple, we'll use a simple Word document saved in .docx format whose content contains the following

The connection settings use a neat feature of the NEST client that allows a POCO type to be associated with a particular index name; that is, when a Document type is specified as the generic type to be indexed, searched, etc., NEST will use the inferred index name specified on connection settings if no index name is specified on the request. Document type names can also be inferred in this way if you want to use a different type name to the camel cased POCO name that NEST will infer from the POCO name by default.

The mapping for the Document type defines a custom analyzer for the Path property that uses the path_hierarchy tokenizer to provide search across path hierarchies. Since this example is running on Windows, the tokenizer uses the \ character as the path delimiter. Additionally, the _all field has been disabled within the mapping as it is not needed in our example. Finally, the metadata fields that we are interested in are mapped for the attachment type.

After the create index request is executed, the index will be created. The mapping for the Document type can be inspected with the following

var mappingResponse = client.GetMapping<Document>();

This returns the following, demonstrating that the mapping has been created as expected

Using NEST, a document field within Elasticsearch can be referenced using a member access lambda expression against the respective POCO type property name. The search result returned for the query is as follows

Since all of the fields in the attachment have store enabled in the mapping, the extracted metadata field values can be returned as above using the stored_fields parameter on the search request. Setting the content field with store enabled in the mapping is useful in scenarios where you want to retrieve the extracted content or perform highlighting on it.

The Attachment type within NEST takes care of accessing the correct values from the fields property in the response, based on member access lambda expressions on the properties of the Attachment type.

Explicit Metadata fields

The mapper-attachments plugin also allows explicit metadata fields to be sent at index time, along with the base64 encoded attachment. This can be useful in cases where you don't want to rely on a metadata value extracted from the attachment. For example, we may be indexing Microsoft Word documents in both the older .doc and newer .docx formats and wish to explicitly control the content type for the latter to align it with the content type of the former. The NEST Attachment type can handle this for us

The document _source with explicit metadata fields now contains two properties, _content and _content_type, the names used when explicit metadata fields are sent for both content and content type, respectively.

Again, the Attachment type takes care of deserializing the source of an attachment into an Attachment instance, with properties set to those explicitly specified in the source.

Gotchas

Whilst the mapper-attachment plugin works well, there are some gotchas to be aware of. For example, if no attachment fields are mapped with store enabled and a document is indexed only with the base64 encoded attachment sent, then a search query to return metadata fields using the stored_fields parameter will return the original base64 encoded attachment as the value for each requested field. One can exclude the original base64 encoded content from the _source document using source exclude feature to mitigate this.

The Future

As previously mentioned, the mapper-attachments plugin is deprecated for Elasticsearch 5.0 and will be removed in 6.0. But fear not however for the future is bright! The ingest-attachment processor plugin, part of the ingest node in Elasticsearch 5.0, replaces the mapper-attachments plugin, providing a more predictable experience over its predecessor. Since the extraction process now happens before indexing of the document takes place within an index request, the extracted metadata fields are now stored in the source field and returned with the rest of the source document in a search request. Let's see an example.

Installation

Similarly to the mapper-attachments plugin, installation of the ingest-attachment plugin is handled by calling the elasticsearch-plugin.bat script within the Elasticsearch bin directory

elasticsearch-plugin.bat install ingest-attachment

Again, start or restart your node after installing this plugin. Now, with at least one ingest node in the Elasticsearch cluster, we're ready to start working with attachments.

Mappings and Pipelines

Mapping with ingest-attachment is a little different compared to how attachments need to be mapped with mapper-attachments plugin. Gone is the need to map the attachment using the bespoke attachment type and instead, we can specify the field that we are going to send the base64 encoded attachment to Elasticsearch in, along with an object mapping that will receive the extracted attachment metadata from the ingest-attachment processor pipeline.

With a slightly updated POCO, the mapping now looks like the following

The mapping uses the text field to map all of the string properties so that they are analyzed. In fact, we can take advantage of a feature within NEST known as automapping to simplify this mapping further; Automapping will infer the document mapping to send to Elasticsearch based on the types of the properties on the POCO. The simpler mapping is

The attachment processor configuration allows control over which properties to extract, extracting all properties by default. A remove processor is also added to the ingest pipeline to remove and hence not store the base64 encoded attachment sent in the content field; since the file exists on a file share already and the extracted content will be indexed into the content field of the attachment field, keeping the original attachment content around in Elasticsearch is superfluous to our use case. In fact, we could simplify this example further by sending the base64 encoded attachment as the value of the attachment field to Elasticsearch instead of using the content field, still specifying the attachment as the target field as before, and removing the content field altogether. A series of blog posts will be diving deeper into ingest node and pipelines if you're eager for more details and use cases; for a teaser, take a look at Ingesting and Exploring Scientific Papers with the ingest-attachment processor plugin and our Elasticsearch as a service offering, Elastic Cloud.

Indexing and Searching in the Brave New World

We're now ready to roll with indexing our attachment! The base64 encoded attachment is now passed in the Content field on the Document POCO and the id of the pipeline to use is also specified on the request.

For this to all work, our Elasticsearch cluster needs to have at least one ingest node in it and, if you need to process lots of attachments, it is recommended to have dedicated ingest nodes since the extraction process can be a resource intensive operation.

All of the extracted metadata from the attachment appears within the _source field under the attachment field and the NEST Attachment type takes care of correctly deserializing this into an Attachment instance on our Document POCO.