Fork me on GitHub
#datahike
<
2021-03-06
>
jjttjj21:03:48

@ramblurr I've found that datalog engines aren't designed for time series and thus not a good fit. You can make it work for small datasets if you want to. But datalog really shines for querying complex relations among entities. Timeseries typically are not really concerned with entities or relations but rather the change of some entity's attributes over time. Datalog (or at least the Clojure engines I'm familiar with) typically don't have a notion of "arrays". You will have to represent your ordered data points in a home rolled linked list or I guess leaning on history features, neither of which will be efficient [Note: Asami has [some notion of arrays](https://github.com/threatgrid/asami/wiki/Entity-Structure#arrays) but I have not investigated this yet. It seems they are just internal linked lists so I still don't think they'll be efficient for time oriented querying] A common thing you'll want to do in time series analysis is jsut get a "slice", a subset of time. This will be trivial to do efficiently in anything that resembles a "sorted map on disk" but not in datalog. Another thing you'll want to do is windowing and aggregation of the data points. Again, not what datalog is designed for. I might be wrong on this but I believe datalog engines will store each [e a v] pair multiple times internally, and this is usually not what you want for a large number of time series points Overall I think if there are relational aspects to your data, keep that in a datalog store, then just use IDs from there in a separate timeseries store.