I'm currently learning AppSearch so that I can use it for a certain project.
So far so good, but I've hit a wall. One thing I know is that AppSearch indexes
documents to elasticsearch. But I find AppSearch to be more opinionated in terms
of how flexible you'll be with the documents. For context sake, my use case is as below.
We index different products using AppSearch because it does a lot of the hard work for us in the background when creating mappings and documents into elasticsearch. But you cannot run more advanced queries through appsearch like you would with elasticsearch.
Consider a query like this that is meant to find documents that are like the document with _id: xxxxx from a certain _index: xxxxxxx:
App Search in its current state is built in such a way that the underlying Elasticsearch indexes are not meant to be queried directly. So you'll definitely run into challenges going this direction.
What sort of Advanced Queries are you trying to run?
Any query from aggregations to the likes of more_like_this. Which I see Appsearch does not support yet.
But if it were possible to expose just the engine_id, and the id of the document as indexed in elasticsearch wouldn't that enable a whole range of possibilities for inter-operating elasticsearch and appsearch? As one can easily reference the document in elasticsearch for other use cases that are currently not available via appsearch.
And your answer brings me to another question, what strategies can we use to have these data indexed by appsearch and still be reusable to query them directly using elasticsearch?
Do we feed them to both elasticsearch and appsearch when indexing? like one specifically for search (appsearch) and the other for other direct query uses (elasticsearch)?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.