#postgresql #extension #timescaledb #Data #TimeSeries

- https://github.com/timescale/timescaledb

```
CREATE EXTENSION IF NOT EXISTS timescaledb

ATTENTION:
WELCOME TO
_____ _ _ ____________
|_ _(_) | | | _ \ ___ \
| | _ _ __ ___ ___ ___ ___ __ _| | ___| | | | |_/ /
| | | | _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \
| | | | | | | | | __/\__ \ (_| (_| | | __/ |/ /| |_/ /
|_| |_|_| |_| |_|\___||___/\___\__,_|_|\___|___/ \____/
Running version 2.11.1
For more information on TimescaleDB, please visit the following links:

1. Getting started: https://docs.timescale.com/timescaledb/latest/getting-started
2. API reference documentation: https://docs.timescale.com/api/latest
3. How TimescaleDB is designed: https://docs.timescale.com/timescaledb/latest/overview/core-concepts

Note: TimescaleDB collects anonymous reports to better understand and assist our users.
For more information and how to disable, please see our docs https://docs.timescale.com/timescaledb/latest/how-to-guides/configuration/telemetry.

CREATE EXTENSION
```

Today has been an interesting one:
- fixing up orphaned servers after a #Puppet CA expiration
- talking #Zabbix with friends and colleagues for the first time in a few years
- building a #Solaris 11 server back from the ground up and starting to integrate it into our Puppet Enterprise environment
- reading up on the current state of #TimescaleDB as it relates to Zabbix
- reading up on the current state of #VoxPupuli’s Zabbix Puppet module
- revisiting my old Zabbix Agent module

@dave would something like #TimescaleDB, which is basically #PostgreSQL with some extra stuff, help with the deletes issue of the PI episode data? My thinking is that since podcast episode releases are basically a kind of time series data that it might, but I may be reaching too.

Look at #TimescaleDB as #PostgreSQL extension...

We'll try as soon as posible :)

Und passend zur #wintersonnenwende ist unsere Photovoltaikanlage jetzt seit genau einem Jahr in Betrieb. Zeit um mal einen Blick in die Statistiken zu werfen.

https://tonick.net/p/2022/12/ein-jahr-photovoltaik/

#photovoltaik #timescaledb #grafana #metabase

@VojacekAles Osobně pracuji s #Influxdb, #timescaledb měl myslím nějaké problém s group by month (bral každý měsíc jako 30 dní, ale už si nepamatuji detaily).
Data ukládat vždy v UTC. A převádět do TZ až na konci výpočtu. Jediný problém je, pokud chci pracovat s agregovanými daty (to je právě ten group by time), tam už se pak musím dívat na časovou zónu už při ukládání dat. Pozor, ne time offset, ale časovou zónu.
Ale konkrétně poradit asi neumím, protože s tady těmi problémy válčím sám taky.

Another small win for #opensource tools like #grafana:
My supervisor at the #wendelstein7x #fusion experiment and I successfully used Grafana and #timescaledb to implement logging and monitoring of the new arc detection system, and the ease of use and rich set of plotting tools are quickly becoming important parts of interfacing with the system.

They now officially handed out the task of building a permanent adapter between Grafana and their internal timeseries database, ArchiveDB, to be able to use it for even more systems!

Exciting <3

Uff, data downsampling can be a weird problem sometimes!
Averaging over regular-spaced data is fine, but when you have short, sharp spikes in-between lower frequency samples, that can lead to very werid behaviour.

Picture no. 1 shows awkward graph behaviour, resulting from averaging over the leftmost edge of a sharp spike.

#timescaledb, luckily, has tools to fix this. Using their first and last operators to extract the edges of each time bucket (generated with time_bucket_gapfill), it’s possible to “fill in” buckets without any samples in them to use the edge of an adjacent bucket. This ensures that edges of sharp spikes remain preserved.

Picture no. 2 shows the exact same data but with a bit of edge preservation done. The data looks much closer to the truth with almost no extra points plotted!

Something for the #dataviz people maybe? ;)

@StanczakDominik
Grafana itself is quite easy to work with, I think the official documentation is nicely fleshed out already :)

The more important part is the data source that you’re using!
This project uses #timescaledb because it integrates very nicely with Grafana and has a few other useful abilities.
We wrote a blog about how we use it a while ago!

For server monitoring you might instead want to look into InfluxDB or similar. Grafana mostly just plots what you give it :)

Today at the #wendelstein #stellarator #fusion #experiment:

Documentation! And learning to not just write it, but also test it.

TL;DR, let someone else go through it. The second pair of eyes makes very different mistakes than yours.

We are setting up a permanent server for the sensor boards that we have been working on for the past few months - finally, a proper place to put the #grafana and #postgresql #timescaledb instances and the #ruby backend code.

In order to make this repeatable, we wrote a page or two in the #gitlab wiki of the project about how to go about it, and our supervisor set up the server by following said wiki…

And immediately things didn’t line up quite right.
The server didn’t have internet, so we had to figure out how to download the .deb packages instead - same for the Ruby bundler packages!
Then some issues with the versioning, and setting up Timescale…

Nothing insurmountable, but if we hadn’t been there in person, it might not have worked as smoothly.

So, even if you write documentation, make sure someone else tries to go through it on their own, and figure out where things get stuck!

Pictures of the new Grafana #dataviz panels coming up soon - I gotta say, Grafana 9 looks very lovely!

#TimescaleDB, a petabyte-scale distributed #time-series database on #PostgreSQL is now available for free

https://blog.timescale.com/blog/multi-node-petabyte-scale-time-series-database-postgresql-free-tsdb/

@newsbot the #timescaledb folk are amazing for their technical work. it's great seeing an article that really shows off that their technical writing also has amazing teeth! such a great team. such a great, comprehensive intro to postgres replication. great illustrations. nice condensed results.