tl;dr; This ^^^^ depends entirely on the details of your use case.
2nd: Elasticsearch’s (TSDS) can work well for metrics-type data, but there are trade-offs. If your main concerns are storage efficiency or high-throughput metric aggregation at large scale, purpose-built time-series databases may perform better.
That said, Elasticsearch does offer flexibility — for example, it allows combining time-series data with full-text search or geo-spatial queries. And if you're already using Elasticsearch for other types of data, using it for time series can simplify your stack.... Seems like this is you ...
Technically, yes (under some specific constraints) — but it’s probably not a great fit
According to Elastic's documentation:
Only use a TSDS if you typically add metrics data to Elasticsearch in near real-time and in
@timestamporder.
So I will back track a bit.....
If it’s just a one-time historical load, TSDS might work with some care. But if you plan to regularly index non-real-time or out-of-order data, TSDS is likely the wrong choice.
A regular data stream or manually managed time-based indices will probably be more flexible in that case. You might need to do some routing etc...
Soooo if we are going to help steer..... we would probably need a little more detail about the Actual use case, like....
- How much data (document count, size)?
- What’s the ingest rate?
- Are you doing an initial load plus ongoing ingestion, or just starting from scratch?
- Is the data mostly current, or is it often delayed or historical? How far out of order?
- Over what time range? Days, months, years? What distribution?
- Do you know time ranges ahead of time?
- Are you planning to delete or archive old data?
- Will documents be updated after indexing?
- What kind of queries or aggregations will you run?
My thoughts... others may have theirs....
All this said we probably won't be able to fully give you an answer (I doubt you expect one) but perhaps we might be able to keep you out of the trench 