こんにちは、LinuCエバンジェリストこと、鯨井貴博@opensourcetechです。 今回は、Zabbix4.2でサポートされたTimescaleDBを使ってみます。 https://blog.zabbix.com/zabbix-time-series-data-and-timescaledb/6642/ なお、TimescaleDBはPostgreSQLの拡張機能になるので、 PostgreSQLで構築されたZabbix4.2が必要です。 PostgreSQL11を使ってZabbix 4.2を構築する - Opensourcetechブログ 参考サイト zabbix4.2のドキュメントとTimescaleDBのドキュメントのみが武器ですw https://www.zabbix.com/documentation/4.2/manual/appendix/install/db_scrip

Every monitoring system has to deal with three kinds of performance-related challenges. Firstly, a good monitoring system must receive, process and record incoming data very quickly. Every microsecond counts here. This may not seem obvious from the start but when your system becomes large enough all the tiny fractions of seconds add up to become seconds if not minutes. The second challenge is to p

PostgreSQL, but faster. Built for lightning-fast ingest and querying of time-based data. Timeseries and analytics

特集のはじめに みなさんは普段、どのようなRDBMS（Relational Database Management System）をご利用でしょうか。昨今、OSS DB（Open Source Software DataBase）の需要は高まっており、DB-Enginesのデータベース人気ランキングでもOSS DBは商用DBに負けないほどの需要を持っています。その中でも特にRDBMSは需要が高く、OSS DBであるMySQLとPostgreSQLは幅広く利用されており、PostgreSQLは2017年に大きくランキングスコアを伸ばしています。 本特集では、2018年10月18日にリリースされたばかりのバージョン11と、現場の主力として使える10にフォーカスし、進化したPostgreSQLの魅力を余すことなくお伝えします。ぜひ、これを機にPostgreSQLの新しいバージョンにチャレンジして

TimescaleDB とは TimescaleDB とは、PostgreSQL の拡張 (EXTENSION) として実装されている、時系列データの扱いやすくする OSS です。 日時によって変動する CPU 使用率や温度などの監視データや金額のようなデータについて、複雑な処理を高速に行なうことができます。 2017 年 5 月から beta が公開され始め、ライセンスは Apache Licens V2.0 です。 メリット Architecture & Concepts: https://docs.timescale.com/v1.2/introduction/architecture Why Use TimescaleDB over Relational DBs?: https://docs.timescale.com/v1.2/introduction/timescaledb-v

A health check playbook for your Postgres database Written by Craig Kerstiens March 29, 2019 I talk with a lot of folks that set their database up, start working with it, and then are surprised by issues that suddenly crop up out of nowhere. The reality is, so many don't want to have to be a DBA, instead you would rather build features and just have the database work. But your is that a database i

技術コミュニケーション室 OSSグループの髙﨑です。 本記事は、とあるクエリを2万倍速にした話 -データベースの気持ちになる- 前編の続きです。 前回の記事でお話しした内容がPullRequestを作ったときの過程だったわけですが、 そのような結果に至った経緯、Index Only Scanを使わなかったPostgreSQL特有の事情について、 PostgreSQLのアーキテクチャなども交えもう少し詳しくお話させていただきます。 要するに 実行計画のコストとはレコードやindexの読み込み、フィルタ処理などからその実行にどの程度の時間が必要となるかの推定値 indexを張る際にはそのindexがどのように辿られるかを意識する必要がある 範囲検索される可能性があるカラムはindexの先頭にはあまり適さない PostgreSQLにおけるIndex Only Scanは新しい/更新頻度の高いデー

技術コミュニケーション室 OSSグループの髙﨑です。 当グループでは、マストドンというオープンソースの分散型マイクロブログについて、 弊社が運営するインスタンス「friends.nico」の運営、独自機能の開発、運用、ならびにそれらで得た知見を上流のプレーンなマストドンへcontributeするという業務を主に行っています。 本記事では、tableに適切なindexを張ることによってとあるスロークエリの速度改善を行った事例について、実際に上流へ行ったPullRequestをベースにお話させていただきます。 内容としては反面教師とするべき失敗例を伴った、非常に基礎的なPostgreSQLの実行計画の読み方ならびにクエリに合わせたindexの張り方です。 また、表題の2万倍速というのは改善前の最悪の場合比であり嘘ではないものの、通常問い合わせされる範囲の条件ではだいたい3〜30倍速であるという