I need to build this b2b commerce where the prices for each product is different for every logged in customer. One of the functionalities is, the customer should be able to filter and sort the list of products by price.
From what I've read so far, storing the prices into the product index could be quite a performance penalty.
Generally speaking in the context of a e-commerce site and especially with price scenarios like the one I mentioned before or discounts per customer etc where the data shouldn't be in the same index is quite difficult and honestly I couldn't find much around the internet.
How would you go about this on how I should tackle this kind of scenarios? I would appreciate a hint on this.
That could be a use case, sure. In my particular use case the price for each customer comes from an ERP so there is no base price for the products hence base price is 0.
If it helps the prices come in the following format: customer_id - product_id - price - percentage_discount
Then I would probably flatten the data and store product information with price for each customer. It will be easy to update and query and should not take up much space even if data this way is duplicated.
That would make sense given that I need to sort using the price.
What if I had 1000 customers? That would be a lot of data and would be more difficult to update all these prices for a given customer.
I know of course the answer would come by testing a variety of solutions and then compare the search performance but since I am new to ES I'm trying to find what would be the thinking process with those kind of relationships.
I found a very good article explaining the pros and cons regarding the right data modeling when we are dealing with relationships but it would be nice to chat about it. Unfortunately there aren't many real world example out there from what I have seen.
No, I mean a document per product and customer without nested documents. This means that you will have 200 documents for each product if you have 200 customers but it aligns well with the feed you get from the ERP system.
Hm, yes that looks interesting. Performance wise it would be pretty fast since each document would be completely flat and using the customer id as a filter would also cache the results. Sorting by price would be pretty easy since the price attribute would be level 0 in the document.
Thanks for your suggestions. I'll mark this as a solution to this thread.
Please for anyone else feel free to share your opinions on this!
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.