101–110 of 143 posts
I'm very glad to see that they have carried themselves far, and I am excited for what's next for the company. Congrats!
Earlier quoted context omitted.
One of our active community members took over the effort to merge PostgreSQL/TimescaleDB support into telegraf here, so hopefully that can make progress: https://github.com/influxdata/telegraf/pull/8651
Yeah, I saw that. I guess I'm a just a little disappointed that nobody at the TimescaleDB team saw through the process. But I understand if you have higher priorities. I still wonder what other people are using to feed information into TimescaleDB. I'm wondering if I should switch to a different approach, such as using Telegraf but routing the data to something else that will push data into TimescaleDB.
Don't want this to come across as overly defensive, but was under PR review for 3+ years by Influx with little progress (first submitted in November 2017) and during that period I think we did something like 2 significant rewrites. Became a bit of a moving target against telegraf that became harder to prioritize.
Earlier quoted context omitted.
Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ y…
Lately, I've been studying machine learning, from point zero, with a focus on time series analysis. Two months in already completed a course on Python and another book on Pandas, several hundreds of hours later in the fourth chapter in a book I paid for on deep learning and time series analysis they provided me with the most important information I needed: there is no evidence deep learning works better than traditio…
remeber that you are in a unique position where you know the ML application and specialized pSQL to implement it.
The market is paying big bucks for people that have either of those skills. If you are making less than 300k/y (at the very least), move out now ;)
I guess this is an unpopular opinion, but I’ve found InfluxDB to be superb for being trivial to get going in a high performance way. I have never touched InfluxDB Cloud - always just InfluxDB either as an arbitrary process or container. Examples of where I’ve found InfluxDB to be more pleasant: * InfluxDB has way better documentation on functions. For example, look up moving average by time (not points) on TimescaleD…
Most developers are already familiar with Postgres or at least SQL.
The tooling around Postgres is basically universal.
There's huge value in an option that is literally just "install this Postgres extension and everything works and gets out of your way".
We use TimescaleDB for a handful of products. In several cases we literally just updated a DSN to point a product at TimescaleDB instead of an existing database and the project Just Worked(TM) except hundreds of times faster.
And some of those that we developed on TimescaleDB natively, it was more or less the same thing... give a team TimescaleDB and they're basically productive immediately. There's no learning and integrating new libraries and query languages, no time from ops finding new and exciting problems to solve in hosting and scaling the DB, etc.
We get all this with all the functionality and strong guarantees that Postgres provides.
Earlier quoted context omitted.
For background, I haven't used TimescaleDB before, but I've done some pretty advanced ORM work to vertically shard PG tables in Rails and I know PG pretty well, so I'm quite curious about TimescaleDB. > * Even though most of their code licensed under Apache license, some code is under their proprietary license. I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "d…
> > * Even though most of their code licensed under Apache license, some code is under their proprietary license. > I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. "yeah, go ahead, infringe that copyright and host a internal/for-direct-clients on…
Earlier quoted context omitted.
Lately, I've been studying machine learning, from point zero, with a focus on time series analysis. Two months in already completed a course on Python and another book on Pandas, several hundreds of hours later in the fourth chapter in a book I paid for on deep learning and time series analysis they provided me with the most important information I needed: there is no evidence deep learning works better than traditio…
> Since started I learned that I don't need machine learning and that I can do the calculations inside PostgreSQL sometimes orders of magnitude faster than in Python. remeber that you are in a unique position where you know the ML application and specialized pSQL to implement it. The market is paying big bucks for people that have either of those skills. If you are making less than 300k/y (at the very least), move ou…
Earlier quoted context omitted.
Hi, I am a hydrologist. Would love to hear about what you have done using TimeScaleDB
We used historical flow meter readings (started out with 15 minute intervals but it worked much better with a higher frequency) and used that to train Recurrent Neural Networks (RNN's) to predict where areas were likely to flood. I was the devops lead on it for the prototype, not the data scientist unfortunately so can't give you the in's and outs but can tell you that we used tensorflow together with pandas/df/times…
msaharia[a]iitd.ac.in
Earlier quoted context omitted.
> > * Even though most of their code licensed under Apache license, some code is under their proprietary license. > I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar. "yeah, go ahead, infringe that copyright and host a internal/for-direct-clients on…
We did work carefully with IP counsel to make sure this type of thing is pretty buttoned-up and expressly permitted: https://www.timescale.com/legal/licenses#section-2-1-grant
Earlier quoted context omitted.
We used historical flow meter readings (started out with 15 minute intervals but it worked much better with a higher frequency) and used that to train Recurrent Neural Networks (RNN's) to predict where areas were likely to flood. I was the devops lead on it for the prototype, not the data scientist unfortunately so can't give you the in's and outs but can tell you that we used tensorflow together with pandas/df/times…
That is awesome. I work in flood forecasting and previously worked in NCAR/NASA. If you would be so kind, feel free to share any white papers, links etc to the project you are referring to. msaharia[a]iitd.ac.in
The main difficulty was getting access to the data (and ensuring it was valid, as with all ML projects), lucking we managed to get that from several sources (councils, water companies etc). The flow data was in TimescaleDB, pandas dataframes so we could use varying levels of frequency of data and we used HDF5 iirc as well (detail is hazy, it was a few years back now). We did demo it to the Met Office here in the UK too. They were interested but already had their own thing cooking up so the project never really got out of prototype, but it was making accurate predictions. I think there were some other areas that might turn out to be flaky over time using this method (such as rapid changes to catchment areas) but that could maybe be factored in someway with more thought on the model and verification on a larger set/timeframes. Feel free to hit me up if you want any more detail on the tech side, but don't ask me about stats, maths fu I ain't :)
joel [at] smashthesystems.com