Given the size of your data it is important that you go through this guide and really optimize your mappings. make sure you are using exactly the mappings you need to be able to search (not necessarily the default mappings), do not index fields you do not need to search on and enable
best_compression. Once you have done this, index perhaps 20 million documents and check how much space that takes up on disk.
When it comes to indexing and sharding it is important to know that querying 1 index with 1000 shards is basically the same as querying 1000 indices each with 1 shard. As you have queries that will have to target all your data, these will be the slowest and most resource demanding ones. As you need to support concurrent queries you generally want your shards to be as large as possible. Having one parent per index will give you a shard size of less than 4GB, which is quite small. You are therefore probably better off having a single index with a reasonably large number of primary shards. When indexing you should use routing, as this allows queries targeting a single father to be as efficient as possible and minimize resource usage.
If we assume improved mappings reduce the index size by 40% each father will on average take up 2.4GB on disk (primary shards). This gives a total size of primary shards of 360TB, which is a lot. With a shard size of 50GB, this means 7200 primary shards. If we add a replica shard for resiliency that is 720TB total storage and 14400 shards. If we assume a single node can serve 4TB of data and maintain query latencies and throughput, that gives you a cluster size of 180 data nodes.
These are just assumptions, and the total data size as well as how much data a node can hold and handle will depend on your data, queries and hardware. You need to benchmark to an accurate estimate as a small change can make a big difference. For this I recommend the following resources: