cevian

9 ms·

61.
by cevian 9y ago
Hi, you've posted this notion that partitioning a column store by time would yield the same result as TimescaleDB a few times, so thought we'd jump in and clear things up. We fully agree that column stores have their place, partic
62.
by cevian 9y ago
That's not always true. There are tons of cases where time-series data gets corrected later. It is true that time-series is INSERT-mostly but UPDATES do happen.
63.
by cevian 9y ago
We've had some clients try this, find consistency issues between elastic nodes or postgres and elastic and start using TimescaleDB as a way to simplify the stack and application. But obviously YMMV and this is highly dependent on your
64.
by cevian 9y ago
Yeah, to underscore some differences more completely, timescale has: - Full indexing and secondary index support. - Support for transactional semantics - Support for living along side relational data - including foreign keys to the relation
65.
by cevian 9y ago
I have to say that a sentiment similar to this is why we built Timescale as a Postgres extension and not started a new database from scratch. We didn't want a new shiny thing just for kicks but rather a product focused on solving a par
66.
by cevian 9y ago
One more thing: If this is the kind of thing that excites you, please come join us: http://www.timescale.com/careers . We have open positions in engineering (core database, R&D, customer success and Frontend) as well as
67.
by cevian 9y ago
Clickhouse is a very cool project but is more analytical than OLTP. Percona had a nice writeup[1] (the comparison to mysql is especially apt -- note the lack of real-time updates and deletes in Clickhouse). [1] https://www.percon
68.
by cevian 9y ago
A lot of time-series data has complex relations and cross-correlations that make it unsuitable for column stores. Take for example a device that reports temperature and humidity. You may want to enforce foreign key relations between devices
69.
by cevian 9y ago
Timescale | New York, NY | Stockholm, Sweden | ONSITE | FULL-TIME Time-series data is everywhere, and the powerful time-series database we are developing (TimescaleDB) is a key building block across a range of industries: IoT, DevOps, monit
70.
Choose PostgreSQL for IoT(blog.timescale.com)
12 points by cevian 9y ago|0 comments
71.
by cevian 9y ago
TimescaleDB is actually a lot better for backfilled/out-of-order data then a lot of NoSQL options. This is because in TimescaleDB data is fundamentally organized by data time instead of insert time (as it is for LSM trees, for instance
72.
by cevian 9y ago
Hey, Not sure if this is part of the question but if you are querying the event data by something other than time (like a property of the event itself -- maybe the program return code in your example) than prometheus requires a full table s
73.
by cevian 9y ago
(TimescaleDB developer here) Yeah, so on-disk compression is one area where we aren't as competitive with NoSQL column stores. However, two things to note: 1) Often many of those column-oriented DBs, based on LSM trees, actually need t
74.
Time-series data: Why (and how) to use a relational database instead of NoSQL(blog.timescale.com)
28 points by cevian 9y ago|17 comments
75.
by cevian 10y ago
Vacuuming has traditionally been a problem with large table sizes. In TimescaleDB we break up the tables so that they are smaller. That, combined with the new freeze map feature in Postgres (since PG 9.6: http://rhaas.blogspot.jp
76.
by cevian 10y ago
Ah, sounds like you are again thinking about bitemporal reasoning over relational data. We are not really built for that use case. Instead of focusing on fundamentally relational data such as people or jobs (which you are free to store alo
77.
by cevian 10y ago
I think these are good points about cstore_fdw and real-time analysis (although we don't have personal experience with this). The usual thing that prevents indexes from scaling with large data is that inserts slow down as soon as the i
78.
by cevian 10y ago
We actually really like (and use) Postgres inheritance. Our extensions add functionality specifically geared for time-series workloads. Namely, we add: - Automatic table-sizing. This includes dynamically creating new tables for new data, cl
79.
by cevian 10y ago
This is a great usage idea and something that should be fairly easy once we support close and update triggers (on our list of todos)
80.
by cevian 10y ago
One more thing to add: Postgres index usage via index-only-scans go a long way to mitigating performance issues of wide rows (although, admittedly not disk-space issues). This allows good performance on columnar rollups.
81.
by cevian 10y ago
Yes we distribute the child tables among the cluster. Our default distribution mode uses "sticky" partitioning where a partition prefers to stay on the same node. This allows you to control data colocation via the partition key. O
82.
by cevian 10y ago
Hi elvinyung, we have three cases (1) chunks from the same hypertable are effectively UNIONized (not JOIN) when collecting results. (2) If JOINING 2 hypertables we have an upcoming feature of allowing the user to specify two hypertables as