I'm doing research for deploying elasticsearch for production. This is
really new to me, but I couldn't find much in google.
We need to search sales in elasticsearch.
- Sale has bunch of payments, products, and 1 user.
- Sale has huge amount of data per day.
- Product object in sale might get updated few times a day, such field like
name, price..etc.
Sale: { // very high write
payments: {
payment: {
id:123,
payment_type: "visa"
...
},
products: {
product: { // this will get update few time per day
id: 12345,
name: "yellow jacket",
...
},
user: { // this will change once a while
id: 111,
firstname: "kevin",
...
}
}
What is the best way to design this for fast search? I read that there are
three ways of doing so:
- have everything you need in a document, but you'll have to update all
the document if anything changes. - have only searchable terms in the document. do second query if you need
more detail information. - have only entity id in the inner objects. very small amount of update is
needed since foreign key id don't really change much, but still have to do
two query each time to get detail information.
I understand this is largely depends on the usage and environments, but is
there some kind of best practice for Sale indexes ? I couldn't find any
real world elasticsearch schema that I can reference. I really want to see
how other people do it. I'm sure this problem been solve before.
Can someone please give me their thoughts on this?
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e3dae07f-f6c4-4e0e-86ed-b3c9ab063617%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.