3 ms·
I'm not an expert on time series databases, but the main thing that I can imagine they do differently is data storage order. In SQL world, the physical order of
by andrewstuart2 11y ago
I'm not an expert on time series databases, but the main thing that I can imagine they do differently is data storage order. In SQL world, the physical order of the data is simply determined by the clustered index. If you were to want your data ordered by time, you'd make an index on a timestamp and cluster by that index [1].
Then if you want to get the most recent N entries, your SQL server is limited pretty much only by the disk read rate, because it's just reading pages in the order they're already stored physically on disk, rather than seeking based on a non-clustered index.
So that really just leaves the possibility of specialized caching or archiving logic as the primary benefit of a TSDB, as far as I can tell. To me, that's not likely worth the added complexity or maintenance costs until I'm processing a lot of transactions.
For the most part, though, that's because I already have a ton of SQL experience. And of course, I could be totally off-base, and I'd want to benchmark the two optimal solutions and see what the difference really is for a given use case.
[1] http://www.postgresql.org/docs/9.5/static/sql-cluster.html http://www.postgresql.org/docs/9.5/static/sql-cluster.html