I would like to use Elasticsearch services for an ecommerce search engine.
Situation:
I found a limitation, I checked search engine based on Lucene like style services (eg:Algolia, Solr & Elasticsearch)) and we have to update a JSON directly to the indices and retrieve that information directly to the frontend.
Research:
If you support a dozen of countries, you can add the price for each country to your records, and then select which one to display in your front-end once the whole record is retrieved.
For example, you would have within your records {"price_FR": "15€", "price_US": "15$", ...}, and choose in your front-end logic which price to display depending on the country of your customer.
My question:
if an ecommerce platform wants to display product prices with modifications based on: - VAT for a country. - any price modification based on a particular customer avoiding to store a json in the index with static values?
more particularly, how do we have to manage the index or response technically to perform that operation in a manner more typical of sql procedures? mainly to replicate sql functionalities of price calculations. I mean options like:
in sql you have the price, and then you perform calculations like: if country x then price * vat_country. = new price.
Or a different approach where the application
avoid indexing the price information in elasticsearch and retrieve the information from elasticsearch but including the price from the mysql registry.
Thank you so much David. Yes, it was one of the approaches I include in the
post. Taking some advices I read eg: modules scriptings https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-fields.html
and the main idea was to explore new features and the possibility to apply
those features to new developments particularly in ecommerce. To see new
ways to use elasticsearch, not only as a json document storage like in the
first approach. More using calculations or similar.
any guideline is welcome!. best regards,
I'm misreading your post probably as I'm missing that it was one of your approaches.
Whatever. I think it's the best way to handle that.
For sure you can compute something on the fly but in that case, just do that on the frontend if it's only for display reasons.
If you want to be able to search for it or sort or aggregate on those computed values, I think it's better to pre-compute that at index time. You can use ingest node feature if you wish.
Then it will be much more efficient when you query elasticsearch.
You told that it's for a eCommerce website. I would expect as a end user the fastest response times as possible. So I'd probably compute that before indexation instead of on the fly.
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.