@linlma As @dadoonet mentioned in your earlier (Join on ElasticSearch) post, you may want to take a step back from thinking that you need to "join" documents to accomplish your goal. Instead, consider a "join" as one of many ways to relate one set of information to another. Parent/child relationships are a way to relate documents, as are nested documents.
Here is another suggestion to consider. Again, as @dadoonet mentioned earlier, relational databases (like MySQL, MSSQL, Oracle, etc.) and document stores (like Elasticsearch) model (structure) data differently. One major difference that I find helpful to remember is that in relational databases, we strive to normalize (eliminate duplications in) our data. In document stores, we often de-normalize (duplicate) our data. Referencing your earlier post, if you want to relate customers and orders, you could have a "customer" document type that has a nested property (AKA nested type) of "orders". The "orders" property will be an array of objects (a list of maps) that describe orders. This will allow your application to display all of the orders that a customer has placed on a page. If you also want your application to display a list of all of the orders it has received, then you could have a separate "order" document type. Notice that you will have duplicated data in your nested "customer.orders" property and in your "order" documents. This is my understanding of how NoSQL and document-based data stores like Elasticsearch are properly used. Our team received a recommendation similar to this one from an Elastic consultant.