4 ms·
I'm not sure what your point is. Time-series describes the data, not the database. You can store timeseries data in Postgres if you want to (and optionally add
by manigandham 7y ago
I'm not sure what your point is. Time-series describes the data, not the database.
You can store timeseries data in Postgres if you want to (and optionally adding extensions like Timescale). You can store it in key/value like Redis or Cassandra. You can store it in bigtable. You can store it in MongoDB. Obviously different scenarios require different solutions.
KDB is a relational database with row and columnstore with features for time series and advanced numerical analytics along with a programming language. KDB is a thing because of those abilities, whether you use it for time-series data or not.
- shakkhar 7y agoIt is very deceptive to say that you can _store_ timeseries data in "Postgres ... Redis or Cassandra" so the nature of the data should not be used to categorize databases. You can "store" data in /dev/null if you never have to do anything with the data. > I'm not sure what your point is. My point is very simple - there is a category of databases widely accepted as "timeseries database", and they deserve a place in any conversation about "types of databases".
- manigandham 7y agoWhat category? The examples you used are formally relational databases. We can certainly talk about common use-cases for certain specific database vendors and products but that's not the same as the underlying type. For example, here's Pinterest handling time-series data on Hbase: https://medium.com/pinterest-engineering/pinalyticsdb-a-time-series-database-on-top-of-hbase-946f236bb29a https://medium.com/pinterest-engineering/pinalyticsdb-a-time... There's a big difference and muddying the definitions with marketing jargon ends up causing too much confusion in this industry.