Hey @Denis_Stogniy ,
Thanks for raising this, I can probably shed a bit of light on this, but it also makes sense to open a case if you’d like some deeper analysis.
Regarding the performance on the “federated collection” (i.e. targeting archived and cluster data together), you should expect to see lower performance than connecting directly to your cluster but the degree of the performance impact is based on the type of query and how you optimized the archive.
One example would be a “streaming query”, something like a “find()”. We’ll start returning data as soon as the underlying storage returns it, so data coming back from the cluster will be immediately returned to you, and then data coming from the archive will be next (most likely). There will be a minor increase in latency as the data has to go from the cluster to the federated endpoint but it should be minimal.
On the other hand, a “blocking query” like a “sort” that requires all relevant data from the cluster and the archive to be brought together is going to be as slow as the slowest tier of storage queried which will most likely be the archive and that can be significantly slower than your cluster.
The last piece to remember is that when you setup Online Archive you select “Query Fields”. Queries that utilize those fields will have improved performance on the archival data, so a “find” on a field that was identified as a query field should perform better than a find on a field that was not identified as a query field.
I’m the PM for Online Archive and am happy to discuss further if it’s helpful, you can reach me at email@example.com.