Hi there, currently my company is looking at migrating from a hosted ES installation (with custom PHP integration) to Enterprise App Search. Primarily for the UI (analytics, ease of tuning, non-developer exposure etc.) that App Search provides. I have some questions that I've been unable to find answers to by searching.
Currently we use a PHP library to connect/index/query etc. our ES install. We make use of things like fuzziness, CSV/PDF ingestion, phrase queries, function score queries, manipulating boost and score modes etc. Are all these things possible in App Search?
When using App Search UI to say, change the boosting of a field, how does that actually work under the hood? How is this actually applied when searching in our app (e.g. using GitHub - elastic/app-search-php: Elastic App Search Official PHP Client) (rather than the App Search UI)? Does it auto-magically merge with whatever we use in the API request? Does one overwrite the other?
Lastly, anyone done this before? Understand it's likely a big undertaking but looking for any gotcha's or tips from anyone that's done similar. Particularly around migrating indexes/setup and backend code (in this case PHP) library from one to another. I have reservations about being able to replicate our current tuned result-sets post-migrate. E.g. searching for "termA" post-migrate is likely not (at least initially, until we manually tune?) to show the same "page 1" results as what is currently shown.
Hi @SMB !
Thanks for investigating Elastic App Search. You've got a lot of good questions here, I'll try to address them one at a time.
The key purpose of Elastic App Search is to abstract a lot of this away from you, so that you focus less on the implementation details of how to achieve relevance, and more on specifying what is relevant. For example, you wouldn't specify fuzziness, or have to try to bake it both phrase queries and multi-match queries, or try to tune the perfect function scoring. App search simplifies this by allowing you to tune your relevance just in terms of "weights" and "boosts". No two search engines are exactly the same, but you should find that App Search's approach to relevance meets expectations for "relevant search."
This is not currently baked into App Search - you'd need to use another tool to first convert your CSV/PDF data into JSON.
Good question. Weights and Boosts provided at query time override any engine-level weights/boosts. If a weight/boost is not provided for a field in your query, the engine-level weight/boost will be used. See search fields with weights.
Most of our customers! Hopefully someone from the "community" will also chime in with their experience, but rest assured that a major goal of App Search is to allow you to spend less time on trying to be "Elasticsearch Experts" - perfectly crafting your mappings and queries - and to spend more time elsewhere.
I think you might be very excited to read about our Curations feature. This will allow you to be able to specify exactly which result sets you want to display for specific queries your customers commonly search for. Obviously, this isn't a substitute for doing good relevance tuning on your engine, but it's a great way to make sure that your "80%" use case is covered perfectly.
Good luck with your migration, and don't hesitate to reach out here or with Elastic Support if you need help!
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.
Understand it's likely a big undertaking but looking for any gotcha's or tips from anyone that's done similar. Particularly around migrating indexes/setup and backend code (in this case PHP) library from one to another. I have reservations about being able to replicate our current tuned result-sets post-migrate. E.g. searching for "termA" post-migrate is likely not (at least initially, until we manually tune?) to show the same "page 1" results as what is currently shown.