トリガーを用いたPostgreSQLのデータ変更検知方法 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 事前準備 トリガーを使用する方法 補足：トリガーと関数のみ消す方法 まとめ はじめに こんにちは！ エンジニア２年目のTKDSです！ PostgreSQLでのテーブル変更検知方法について調べました。 今回はトリガーを使用する方法について説明します。 事前準備 DBの準備(compose.yaml) services: db: image: postgres:16.4-bullseye container_name: db environment: POSTGRES_USER: postgres POSTGRES_DB: postgres POSTGRES_PASSWORD: postgres ports: - "127.0.0.1:5432:5432" volumes: - db_data:/var/lib/postgresql/data - ./init.sql:/docker
PG-Strom v5.0 - KaiGaiの俺メモ
ずいぶんご無沙汰のブログ記事となりました。 今回は、設計を一新して速く、頑強になった PG-Strom v5.0 をご紹介します。 なぜ再設計が必要だったのか？ 前バージョンの PG-Strom v3.x シリーズの基本的な設計は、2018年のPG-Strom v2.0の頃から大きく変わっていません。 当時の最新GPUモデルは Volta 世代（TESLA V100）で、CUDAのバージョンは9.2ですから、かなりの大昔という事はお分かり頂けると思います。 この頃、PG-Stromの開発において最優先すべき課題は、先ず実用となるバージョンをリリースする事でした。（※ HeteroDB社の創業は2017年7月です） クエリの処理速度を高速化する事は当然なのですが、それ以上に、まだPG-Stromの内部インフラも十分に枯れていない中で、クラッシュせずに走り切る事や、バグがあったとしても容易に原
GitHub - devrimgunduz/pagila: PostgreSQL Sample Database
Pagila started as a port of the Sakila example database available for MySQL, which was originally developed by Mike Hillyer of the MySQL AB documentation team. It is intended to provide a standard schema that can be used for examples in books, tutorials, articles, samples, etc. Pagila has been tested against PostgreSQL 12 and above. All the tables, data, views, and functions have been ported; some
MySQLに独自charsetを追加する - tmtms のメモ
MySQL に独自 charset を追加できる…という話はずっと前に聞いたことあったけど、やったことなかったんでやってみた。 詳しくは MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.13 文字セットの追加 を。 マルチバイト charset は C でプログラムを書いてコンパイルする必要があるけど、1バイト charset はファイルを置くだけで追加できる。 1バイトの charset と言えばみんなご存知の JIS X 0201 ですよね。ということで、jisx0201 という charset を作ってみる。 JIS X 0201 のコードはこんな感じ: x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF 0x NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO
Active RecordでRow Level Securityを使って安全にテナント間のデータを分離する - SmartHR Tech Blog
従業員データベース機能の開発を担当している渡邉です。最近公開したGemであるactiverecord-tenant-level-securityの紹介をします。 SmartHRにおけるマルチテナントの現在 私たちが開発するSmartHRはお客様ごとに1つの環境を提供する、マルチテナント型SaaSです。サービス全体で1つのデータベースを持ち、複数のテナントのデータが混ざらないように、SQLで問い合わせを行います。 1つの環境ごとに1つのデータベースを持つ方式は安全性の面で優れていますが、スキーマの保守やマイグレーションにかかる時間の増加など、多くの技術的な困難をもたらします。この選択の背景については、2018年に書かれた以下の記事もご覧ください。 tech.smarthr.jp とはいえ、常にテナントごとのWHERE句を意識しながらコードを書くのは大変ですし、不具合の温床になります。幸い、私
オレ的EXPLAIN技を語っちゃうゾ - Qiita
メリークリスマス 本記事はPostgreSQL Advent Calendar 2021の25日目です。今年も面白い記事がたくさん揃いましたね！！！ さて、みなさん今年のPostgreSQLライフはどんな感じでしたでしょうか？ 私はというと、なんだかチューニングばっかりやってました。1案件でいろいろお手伝いすることはまあまああったのですが、複数から次々チューニングの相談をもらって、歴代継承者の個性を発現したデクくんのごとく駆け回ったのが今年のハイライトです。 （この綱渡り感、、、伝われ！！！） 俺たちは雰囲気でチューニングしている 今回上手くいったけど、あの時たまたまひらめいた1案をぶつけてみたら効果でたのであって、次善の策なんてなかったけど？？って毎回思ってるから、雰囲気でやっていると思う、マジで。コミュニティのノリだと笑いが起きていいんですけど、少しでも勝率を上げるために、若手の前でド
PostgreSQL 20年史｜コミッター石井達夫が振り返る変遷と進化の歴史｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQL 20年史｜コミッター石井達夫が振り返る変遷と進化の歴史 世界中で使用されるRDBMSであるPostgreSQLの長い歴史には、どのような変遷があったのでしょうか。長く、PostgreSQLに関わり続ける石井達夫さんに、同ソフトウェアの進化歴史の中にあるキーワードをもとに振り返ってもらいました。 オープンソースのRDBMSであるPostgreSQLは、いまや世界中の人々が利用するソフトウェアとなりました。その歴史は長く、ルーツは30年以上も前にさかのぼります。 PostgreSQLの前身は、カリフォルニア大学バークレー校で1986年に始まったPOSTGRESプロジェクトです。その後、1994年にAndrew Yu氏とJolly Chen氏がPOSTGRESにSQL言語インタプリタを追加し、翌年にPostgres95をリリース。1996年にようやくPostgreSQLとい
実録パフォーマンス改善 - 高速化のためアーキテクチャやアルゴリズム選択から見直すSansanの事例 - エンジニアHub｜Webエンジニアのキャリアを考える！
実録パフォーマンス改善 - 高速化のためアーキテクチャやアルゴリズム選択から見直すSansanの事例 インフラの特性をふまえ、ミドルウェアの挙動を理解し、プロファイリングによってボトルネックを把握し、要求に合ったアーキテクチャを選択する。そういった工夫を重ねることでアプリケーションのパフォーマンスを改善する事例を、Sansanの千田智己さんに聞きました。 アプリケーションの設計・実装方法を変えることで、性能が格段に向上するケースは数多くあります。有名IT企業のエンジニアは、どのような方針のもとでアーキテクチャあるいはアルゴリズム選択などでパフォーマンスを改善しているのでしょうか？ 法人向けクラウド名刺管理サービス「Sansan」や個人向け名刺アプリ「Eight」を提供するSansan株式会社の千田智己さんに、これまで取り組んできた事例と、そのノウハウを教えていただきました。 千田 智己（せ
PostgreSQL v11新機能先取り：Hash-PartitioningとParallel-Append - KaiGaiの俺メモ
今回のエントリーは PostgreSQL Advent Calendar 2017 - Qiita に参加しています。 PG-Stromの視点からも、PostgreSQL v11には首を長くして待っていた機能が2つ入っている。 その１：Hash-Partitioning github.com その２：Parallel-Append github.com Hash-Partitioningというのは、PostgreSQL v10で追加されたテーブルパーティショニング機能の拡張で、日付時刻などの幅（Range）でパーティション化を行うのではなく、レコードの値をハッシュ関数に通して得られた値を元に、振り分ける先の子テーブルを選択して書き込みを行うというもの。 特徴としては、データの母集団が特異なものでない限り*1、各子テーブルへの書込みは均等に平準化されることになる。これは後で説明する通り、子テ
gstore_fdw: GPUメモリをSQLで読み書き、そして…。 - KaiGaiの俺メモ
昨年、PGconf.ASIAで発表したPL/CUDAによる創薬ワークロードの高速化実験のテーマであるが、 kaigai.hatenablog.com 実測したベンチマークを見ると、奇妙な傾向が見てとれる。 このワークロードにおける計算量は「Qの行数×Dの行数」であるので、Dの行数が同じ1000万行であるならば、Qの行数が1000のケース（22.6s）に比べ、Qの行数が10のケース（13.4s）の実行時間はもっと顕著に短時間でなければならない。 計算量が1/100なのに、実行時間は半分弱にしかなっていない。 実はこれは、化合物同志の類似度を計算するための時間だけでなく、PL/CUDA関数に与える引数をセットアップするための時間に12秒程度を要しており、アムダールの法則を引用するまでもなく、類似度の計算を高速化するだけでは処理速度はこれ以上伸びないのである。 PL/CUDA関数の引数として行列
カスタムロジックをWHERE句で使う - KaiGaiの俺メモ
しばらくSSD-to-GPUダイレクトSQL実行の開発にどっぷり時間を突っ込んでいたので、久々にPL/CUDAネタ。 この辺のネタや、 kaigai.hatenablog.com この辺のネタで kaigai.hatenablog.com 紹介したように、PG-Stromはユーザ定義関数をCUDA Cで記述するための機能（PL/CUDA）を持っており、これを使えば、データベースから読み出したデータをGPUに流し込み、GPU上でカスタムのロジックを実行した後、結果をまたSQLの世界へ戻すという事ができる。 この仕組みはPostgreSQLの手続き言語ハンドラの機能を用いて実装されており、ユーザ定義のPL/CUDA関数が呼び出される毎に、手続き言語ハンドラが以下の処理を行う。 ユーザ記述のCUDA Cコードブロックをテンプレートに埋め込んで、ビルド可能なソースコードを作成。 NVRTC(NVI
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
pt-table-checksumでテーブル名の大文字小文字にハマったはなし | GMOメディア エンジニアブログ
ごきげんよう、GMOメディアにてDBAをやっておりますshowです。 今回はタイトルの通り、pt-table-checksumでテーブル名の大文字小文字にハマったはなしをお伝えします。 ■そもそもpt-table-checksumとは pt-table-checksumとは、米国PERCONA社がOSSで提供しているPercona Toolkitに含まれるツールで、MySQLでのレプリケーション環境においてマスターとスレーブ間でのレプリケーションの整合性を確認するツールです。 このツールを用いることでマスターとスレーブで、データベース名やテーブル名、テーブル内のデータの整合性がとれているのかどうか等をオンラインで確認することができます。 ドキュメントはこちら https://www.percona.com/doc/percona-toolkit/LATEST/pt-table-checks
進捗）SSD-to-GPU ダイレクトSQL実行機能 - KaiGaiの俺メモ
ここ暫くブログでまとめていなかった、SSD-to-GPUダイレクトSQL実行機能の進捗について。 この機能をかいつまんで言うと、NVMe-SSDに格納されているPostgreSQLのデータブロックをGPU RAMに直接転送し、そこでSQLのWHERE句/JOIN/GROUP BYを実行することで見かけ上のI/O量を削減するという代物である。 NVIDIAのTesla/Quadro GPUが対応するGPUDirect RDMA機能を使い、SSD<=>GPU間のデータ転送を仲介するLinux kernel moduleを使えば、CPU/RAMにデータをロードする前にGPU上での処理を行うことができる。 しばらく前からScan系の処理には対応していたが、JOIN/GROUP BYへの対応を加え、さらにPostgreSQL v9.6のCPU並列にも追従したということで、簡単なベンチマークなら取れる
PG-Strom - Limit Breaker of PostgreSQL powered by GPU
No Pain for Performance Gain 既存環境の変更なく性能向上を狙う PG-Strom works as an extension of PostgreSQL, to provide new GPU-based implementation for several SQL workloads like relations-join, aggregation/group-by, and so on. PG-StromはPostgreSQLの拡張モジュールとして動作し、表結合(JOIN)や集約(GROUP BY)などいくつかのSQL処理に対して、GPUを用いた実装を新たなオプションとして追加します。 It works transparently to the existing PostgreSQL systems, never affects to the SQL sta
RethinkDBとPostgreSQLの比較:私の個人的な経験より – 後編 | POSTD
私は Hacker Newsのこのディスカッション で、PostgreSQLにRethinkDBのchangefeedのようなものを実装するための基本的なビルディングブロックがあるということを知りました。オンラインで NOTIFY / LISTEN の使用法を検索していると、比較的シンプルな（しかし分かりやすい）デモが見つかりましたが、これは本当にありがたかったです。多くのベンチマークを経て、これはうまくいきそうだという結論に達しました。 完成には何が必要なのか、本番環境でRethinkDBを使っていた経験から、私には 正確に 分かっていました。大した設計が必要になるわけではありません。問題は明確でした。全く同じことを、代わりにPostgreSQLのLISTEN/NOTIFY、そしてトリガを使ってやればいいのです。 PostgreSQLについては、私は1990年代後半から断続的に使用してい
Hash indexes are faster than Btree indexes?
PostgreSQL have supported Hash Index for a long time, but they are not much used in production mainly because they are not durable. Now, with the next version of PostgreSQL, they will be durable. The immediate question is how do they perform as compared to Btree indexes. There is a lot of work done in the coming version to make them faster. There are multiple ways in which we can compare the per
コサイン類似度に基づくソート処理の実装方法とその性能比較
文書の類似度を計算する方法に「コサイン類似度」を用いる方法があります。 これは、出現する単語を出現回数などで数値化して、空間ベクトルに変換した上でベクトル同士の類似度を計算する、という手法です。 コサイン類似度 http://www.cse.kyoto-su.ac.jp/~g0846020/keywords/cosinSimilarity.html 最近、このコサイン類似度を使って、似ているデータを検索するWebアプリを試しに作っていたのですが、ふと、 「このコサイン類似度を使ったソート処理をPostgreSQLでどのように実装するともっとも高速な実装になるのだろうか。また、現実的なパフォーマンスを考えた時にデータ量や次元のサイズはどこまで増やせるのだろうか」 ということが気になりました。 PostgreSQLは、その拡張性の高さがウリの一つですが、そのため「UDFを作る」ということを考え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
Dockerで必要十分なNodejs+PostgreSQLの環境を作る方法 - Qiita
