mfreed

25 ms·

1. 181.▲
   by mfreed 7y ago

   One thing to add: The Timescale Cloud does allow you to do is create asynchronous read replicas across different clouds and regions (with a couple clicks). You can then "fork" a read replica (at any point in time) and make it a
2. 182.▲
   by mfreed 7y ago

   Thanks, @bdarnell! We at TimescaleDB spent a lot of time thinking about how to best express this dividing line in a manner concretely understandable by engineers. Glad to see others starting to take a similar approach.
3. 183.▲
   by mfreed 7y ago

   (Timescale cofounder here) Hey, just wanted to clarify: the vast majority of TimescaleDB code is Apache2, and you can easily compile (and we ourselves build & distribute) Apache2-only binaries. When we announced a new license in Decembe
4. 184.▲
   by mfreed 8y ago

   Hi @ddorian43, Timescale person here. I assume the question is asking more about TimescaleDB, rather than an HA solution that is shard-aware in is View management? We're in the process of building our own scale-out clustering solution
5. 185.▲
   by mfreed 8y ago

   Thanks for the great summary, manigandham. We're actively working on the scale-out version of TimescaleDB that will allow you to transparently shard hypertables across many servers. Hope to announce more specifics in the next several
6. 186.▲
   by mfreed 8y ago

   This is not the case. TimescaleDB has full support for storing JSON data (inherited from postgres), including with indexes, so you do not need to fully pre-define your schema for these types of applications. In fact, we added support for
7. 187.▲
   by mfreed 8y ago

   TimescaleDB clustering is currently limited to a single primary with multiple read-only replicas (which provide both HA failover and scaling concurrent reads). So the limitation here is the storage capacity available for the nodes, and so t
8. 188.▲
   by mfreed 8y ago

   We have not observed any effects on relational table performance. Basically, TimescaleDB code in on-path for each parsed query, but if the query does not specify a hypertable, we just let the query "fall through" to Postgres&#x27
9. 189.▲
   by mfreed 8y ago

   TimescaleDB | New York City, Stockholm, Remote Time-series data is everywhere, and Timescale is helping developers and companies make sense of it. We build an open-source time-series database, engineered up from PostgreSQL, that supports f
10. 190.▲
    by mfreed 8y ago

    Hi @neslinesli93, it's quite easy: (1) Call create_hypertable with default indexes off (include an argument of `create_default_indexes => FALSE`) [1] (2) Then just use a standard CREATE INDEX command on the hypertable at any time.
11. 191.▲
    TimescaleDB vs. InfluxDB: built differently for time-series data(blog.timescale.com)

    178 points by mfreed 8y ago|46 comments
12. 192.▲
    by mfreed 8y ago

    Pretty much, except I'd use our data retention mechanisms instead of #2 (directly deleting the rows), as it's much more efficient. So to review: 1) Create a "raw" and "rollup" table. Define the rollup table wi
13. 193.▲
    by mfreed 8y ago

    Realize that you might have just been asking about data retention policies, rather than continuous rollups (which is what the github issue is about). If so, data retention policies are easy with TimescaleDB: http://docs.timescale
14. 194.▲
    by mfreed 8y ago

    Hi, thanks for the question about rollups. Timescale indeed enables you to do rollups, much like the functionality you describe. (Right now these are scheduled via a crontab, but in-DB scheduling is in the works.) But unlike InfluxDB (at
15. 195.▲
    by mfreed 9y ago

    “my issue is the marketing spin where you claim to be better than everything else” I’m sorry that was your impression and it’s certainly not our intent to mislead, although I’m not really sure why/where you think we claimed this. Inde
16. 196.▲
    by mfreed 9y ago

    This is especially important if you are also dealing with metadata that you don't want to always denormalize into your time-series tables. If you don't insert it transactionally, you can also lose referential integrity between yo
17. 197.▲
    by mfreed 9y ago

    Thanks for the comments, and it sounds like you want a deeper dive as to some of the design decisions around TimescaleDB. What might be useful to start is two of our technical blog posts around how we design internal partitioning [1], as we
18. 198.▲
    by mfreed 9y ago

    Thanks for the detailed comments. Let me try to answer a couple of them. - We don't bypass the Postgres I/O in general, but have rewritten a lot of the insert path as it relates to managing inserts across many chunks (child table
19. 199.▲
    by mfreed 9y ago

    Influx is a NoSQL, non-relational database, written from scratch, that optimizes for properties like higher compression and column scans for specific label sets. While it supports something SQL-ish, the query language is fairly limited, an
20. 200.▲
    Timescale raises $16M from Benchmark, NEA, Two Sigma Ventures(blog.timescale.com)

    121 points by mfreed 9y ago|56 comments
21. 201.▲
    by mfreed 9y ago

    TimescaleDB person here. Thanks for the call-out. For those who don't know, TimescaleDB is a extension to Postgres that makes it easy to use and scale for time-series data. It works with both PG9.6 and PG10. Some folks might be inter
22. 202.▲
    by mfreed 9y ago

    There are some confusions in that post -- perhaps understandable, as trying to deduce things from code review alone is tricky -- but Grisha and I have been communicating and hopefully it'll be updated. Overall like the conclusion thoug
23. 203.▲
    by mfreed 9y ago

    I think the broader point is that Tgres is generally focused on computing regular aggregations. Once you do that aggregation, you lose significant information about the relation between data collected at the same time, which eliminates you
24. 204.▲
    by mfreed 9y ago

    Looking at the tables we used for recent benchmarking comparing Postgres vs. Timescale ( https://blog.timescale.com/timescaledb-vs-6a696248104e ): PG 100M rows: 30.98GB (1 table) TS 100M rows: 30.93GB (1 hypertable, 6 chunks
25. 205.▲
    by mfreed 9y ago

    There's not really any meaningful extra size for Timescale compared to standard Postgres. I mean, there's a little extra information about each chunk (table name, its constraints, triggers, etc), and we cache this information in m
26. 206.▲
    by mfreed 9y ago

    A common approach we find for storing devops-related time-series data (as you'd find with influx), is to not denormalize the "labels" or "tag set" into the main metrics table. This obviously saves significant space
27. 207.▲
    by mfreed 9y ago

    Well...sorta. Postgres/Timescale have pretty rich support for JSON these days (and its more efficient "binary" JSONB), so there are a whole range of options you can do that make it feel much more schema-less than before. In
28. 208.▲
    by mfreed 9y ago

    If the viz tool can speak to Postgres, it works with Timescale. Tableau, Superset, SQLPad, Mode, Plot.ly, etc. We internally use Grafana through a REST interface to a timescale backend. (And in fact, that's how we visualize the Prome
29. 209.▲
    by mfreed 9y ago

    Currently support 9.6 query parallelization. Also considering extending with some of our own methods on chunks as well. (Timescale supports multiple disks either through RAID or tablespaces. Unlike PG, you can add multiple tablespaces to
30. 210.▲
    by mfreed 9y ago

    Basically just looks like a postgres database on the admin side. Replication works (we aren't munging with the WAL), docs for backup/restore ( http://docs.timescale.com/api#backup ), and you can just use pgAdmin.