The index you have is optimal for your query, so if your collection gets much larger, the query still should return relatively quick (with caveat of data size vs. hardware capabilities, of course).
I see you have two indexes: the mandatory
_id index and the compound index. The compound index itself is 3MB, which is a bit less than 10% of the collection size.
As with most things in computing, it is a balancing act. If you feel that returning queries quickly in a large collection is worth the space tradeoff, then I encourage you to keep the compound index. Case in point, your first screenshot shows that in a collection of 268k documents, the query returned in just 5ms. For most use cases, this space vs. speed tradeoff is worth it.
However, if you feel that you can tolerate much slower query response time and if space is much more important to you, then dropping the index is an option.
Another option is to create an index only on
sensorId, so your query won’t be totally unindexed.
All three options have advantages & disadvantages, so it’s up to you to choose which option is “best” for your use case.
Having said that, be aware that as your collection gets larger, scanning unnecessary documents to return a query will have other side effect as well, such as pushing your working set off memory and could possibly make everything slower (since irrelevant documents are constantly being paged into memory to be examined, only to be thrown out again).