The "proper" thing to do is to make a data model and then run the aggregations on the fly for your searches in tstats. Accelerate the data model and hopefully it will not be too bad.
The other solution is actually to use summary indexing, but to make all the fields you are interested in indexed fields with props and transforms. By making them indexed fields you can still use tstats against the index. In your search query, instead of from datamodel=blah you'd do from index=blah. This still comes with all the problems that tscollect has (data lag causing incorrect data namely), but on the plus side you get the retention policies of indexes and if summary indexing is configured properly it will go out and store the data on your indexers. ,The best you could probably do is to actually do those aggregations on the accelerated data model and not expect them to already be done. That is set up your data model to have the fields and run a tstats on the accelerated model by search_id. It is not pretty, but what you want is only possible in data model acceleration if splunk allowed base search data models to be accelerated which it does not.
The other thing you could do is migrate to summary indexing. You can then make all of the fields you care about in your summary index, indexed fields. The result of this is equivalent to making your own tsidx namespace. You can actually still run tstats against that index. Instead of from datamodel=blah, you do from index=blah. The storage technology is the same and it should work with almost the same performance. However the same problems you would have with tscollect (such as data lag causing incorrect data) still exist, whereas they will not in the accelerated data model with aggregations on the fly.
