I think that in order for you to accomplish what it is you are trying to do, with the technologies you have chosen, you first really need to consider clearing your thoughts and removing your relational database thinking. I am not going to get real technical on this comment but rather gloss over a few points. I do not know how much time you've spent with elasticsearch, but I can tell you, it likes it much better when you play nice with it. It is sensitive.. It doesn't even like when you voice gets a bit loud. That being said, I think you will find that you can accomplish your goals by rewiring a few ways you think. I am going to try to keep this short. Im going to make a couple suggestions much like those of @dadoonet, which you should have been followed; embrace these freebies as the process of earning them is lengthy
Before I offer what I think will likely put you down a better path, consider the one you are on. You are trying to use techniques to retrieve data in a relational centric way on a storage engine that is an index. This is not a subtle difference and is a point that you must understand well in order to be able to efficiently work with it. Behind elastic search is an extremely fast and efficient indexing technology. No relational database that I know of could come close to touching it, when doing the things it does best. Much the same, I do not know of any non relational databases or index that can navigate relationally stored data the way relational db can.
You really should go ever that documentation, thoroughly, like 30 or 40 more times. Im pretty sure when I learned it, i had no less than 6 browser instances open for sorting the 80 or so open pages each had open on it. When you do this, pay really close attention to the way they write about the various aspects. Look for the function / methods / techniques that they talk about that elasticsearch and cassandra do really really well and then think on them with an out of the box, resourceful mind. Try and figure out how you can leverage one or more of your options ( which even the worst options are still like 12 timex faster than what your doing ) Keep in mind that sql has like 90k words ( maybe 30 that you use ) elastic search may have 100 maybe not even. It is much less of a task to thoroughly learn elasticsearch than it would just to become aware of all that sql.
The first and most important was the little gem that @dadoonet gave you in the beginning of this conversation regarding using the the parent / child relationship with caution. I would agree with him and add the little bit of, just forget that exists and use one of the other two "relational" means to store data. The way you have chose to store your "to be indexed data " is the slowest and least efficient as well as resource heavy way you can go about this task. I am sure there is a good reason for them having it in there, I have just not come across or heard about it.
Elasticsearch is an index. Take the idea of normalization and throw it out the window if your to work with the index. Accept that it is perfectly ok to have data, the same data, repeat its self across several models. Aside from going beyond reason and fighting scope, your not likely going to pay in the long run. The index will have no problem working with it, especially if your not exposing all of it and are working with in the meta of its models correctly.
Since your still feeling icky at the thought of denormalizing data ( and yes that means scribbling all over your domain and rearranging it so that it looks like a 4 year old with chewed up crayons designed it ) while your thinking of how your data is going to be used rather than how neatly you can store it, find a way to accept that sometimes you just need to do some of the processing in the code. If those domain objects were pulled from a relational db that layer would probably serve you up some nice arrays of data with some awesome caching levels to the the transient data bla bla bla... to get that effect for data that is relational, especially if your index is not designed with how the data is to be used but rather how to make the foot print small, your just going to have to create those arrays in the code your self.
The way this index stores data and in particular the way you are asking it to persist the index, being aware of and understanding the data is scoped and that the way you store the data determines its scope. The scoped data will impact what and how you use things or do not use them. You will write code differently because of the scoped nature of the persisted data. (ugh this is such a lengthy subject, with so many things that need to be gone over) I would be sure to touch on the scope of the child data in in relation to any data not in the relationship. It has strong benefits, but I never really found a need to leverage it, especially because of what it cost. You will find later that your likely going to be using a bunch of business logic and memory to further relate anything you would derive from it....
Learn to live and love aggregation and other tools that elasticsearch has and has specialized to very impressive level. Elasticsearh tends to go a little easier on ya and may even forgive you for you trying to cram relational data down its throat in a normalized way all while expecting a the index to persist it as such. Its just not how it works.
In all my years working with data, and model this or that..... the many years before OOP really was the main stream, I have never known a storage engine that was the end all be all that is perfect for persisting every imaginable type of data as well as accessing it. Expand the mind a bit and think of systems which may leverage relational databases for some aspects, indexes for other, in memory db / caches for other. Think on the ways you can leverage each tool you have so as to maintain a healthy balance of cost / gain in efficiency as well as time needed to implement the various aspect. Image things like persisting the results of data pulled from a relational database as entities of their own in one object to be indexed for analysis. Big data is big, maybe you cant store all the answers so you decide the analysis results could be offloaded to a schema less or nosql in mem db to hold on to, keeping the index a health size with no real cost in time to get it back out of mem.
Let go of all you know embrace the difference, it is after all why your using something different right? Because its different: RTFM Good luck to ya brother. Elasticsearch is fun to learn. They do some really cool things in very clever ways which is going to make you abetter programmer for the broadened exposure to mindsets beyond the borders of relational data.