161–170 of 176 posts
Earlier quoted context omitted.
Also Druid, HBase, Vertipaq (engine behind PowerBI), Redshift, Azure SQL DW, etc Columnar compression is a really interesting engineering problem
ClickHouse is another favourite
Earlier quoted context omitted.
Also Druid, HBase, Vertipaq (engine behind PowerBI), Redshift, Azure SQL DW, etc Columnar compression is a really interesting engineering problem
memsql (which was in there for new sql).
The document completely overlooks Columnar databases, which are focused on analytics and are much faster than (most, not all) general-purpose DBMSes. See: https://en.wikipedia.org/wiki/Column-oriented_DBMS and https://www.slideshare.net/arangodb/introduction-to-column-o... or get: http://www.nowpublishers.com/article/Details/DBS-024 Examples: * MonetDB * SAP Hana * Actian Vector (formerly Vectorwise) * Oracle In-Memo…
They are much faster for analytical queries, not for transactional ones. If they were overall faster they would be the default relational databases.
Earlier quoted context omitted.
I know very, very little about any of this, but would this be akin to entity component systems in video games? Forgive me if I'm way off.
Sorry, I don't know what "entity component systems" are. If you mean saving the same component for all entities, rather than saving a bag of components for each of the entities, then sort of.
Earlier quoted context omitted.
Those are still relational databases, just with column-oriented/column-store tables. I don't see how the storage layer changes the database type. For example, MemSQL has both rowstores and columnstores. Postgres 12 has pluggable storage with column-store (zedstore).
> I don't see how the storage layer changes the database type. It does, because it leads to other types of optimization. LittleTable [0], for example, keeps adjacent data in time domain adjacent in disk. So querying large amount of data that are close to each other is efficient even on slow (spinning) disk. Vertica [1] does column compression which allows it to work with denormalized data (common in analytics workloa…
Stored is an implementation detail. Optimizations are improvements to performance. Neither affects the fundamental data model, which in relational databases is relational algebra over tuple-sets.
Earlier quoted context omitted.
Time-series is more about a specific use-case about data that has a primary time component (like sensor metrics). You can store it in any database, although the common ones are usually some sort of key/value or relational with specific features for time-based queries. Hbase/Bigtable/DynamoDB/Cassandra are key/value. InfluxDB is key/value. Timescale is an extension to Postgres.
If you could store timeseries data "in any database", kdb wouldn't be a thing. Just go and ask a quant trader replace his kdb instance with postgres. (Be prepared to be laughed out of the room.)
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.
Earlier quoted context omitted.
If you could store timeseries data "in any database", kdb wouldn't be a thing. Just go and ask a quant trader replace his kdb instance with postgres. (Be prepared to be laughed out of the room.)
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 wi…
> 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".
Earlier quoted context omitted.
> I don't see how the storage layer changes the database type. It does, because it leads to other types of optimization. LittleTable [0], for example, keeps adjacent data in time domain adjacent in disk. So querying large amount of data that are close to each other is efficient even on slow (spinning) disk. Vertica [1] does column compression which allows it to work with denormalized data (common in analytics workloa…
The underlying database type hasn't changed. LittleTable is a relational database (it's the first sentence in the paper). Vertica is also a relational database. Stored is an implementation detail. Optimizations are improvements to performance. Neither affects the fundamental data model, which in relational databases is relational algebra over tuple-sets.
The top TS databases are more than just storage too. You need a query language that can exploit the ordering column-oriented gives you that the row-oriented relational doesn't.
On the lower end (eg, Timescale db) trying to fit a timeseries model on a row-oriented architecture which is a poor fit.
All of them are in fact graph databases, they just didn't realize about it and got lost giving the implementation the category of design for many reasons specific to the context in which they were created. I think we should think more often as mathematicians and a little bit less as "hackers"
Earlier quoted context omitted.
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 wi…
It 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 an…
For example, here's Pinterest handling time-series data on Hbase: 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.