Oh, I definitely understand what you’re getting at ... and you’re absolutely correct that your approach is proper.   (No, it isn’t original, but very few engineering solutions ever are.)

The obvious advantage of your approach is that the “terabytes of data” do not have to be moved, copied, or duplicated.   The database, and/or hash-tables or what-have-you, serves as a convenient index into this “enormous data source,”

Actually, when “inconveniently-massive amounts of data” are involved, this sort of approach is actually ... fairly typical.   You do not have to move data into, say, “an SQL database,” in order to effectively use “an SQL database” to index it.   The only design-concern is that you need to take care that the [SQL database ...] index doesn’t duplicate the content that it is meant to index.   (This might, for instance, mean that the index is, by-design, ‘uncertain.’)   You must also ensure that the external-index(es) ... whatever (it is) | (they are) ... remains “current-enough to be both ‘useful’ and ‘not misleading.’”