PostgreSQL を使ったユーザー検索機能のパフォーマンス改善の話 - エムスリーテックブログ
こんにちは、デジスマチームでソフトウェアエンジニアをしている伊藤です。 この記事はデジスマチームブログリレーの8日目の記事です。 今回は我々が開発しているデジスマ診療 (以降、デジスマ) で、医療機関向けに提供しているユーザー検索機能のパフォーマンスを PostgreSQL の機能を活用して改善した話について紹介します。 ユーザー検索の課題感 データ構造 検索クエリ Step 1: 仕様の変更で対応できることはないか? Step 2: 部分一致検索のままで高速化できないか? (pg_bigm の導入) Step 3: インデックスを効率的に活用できないか? (2段階検索への分解) Step 3.1: 各検索条件で user_id のリストを個別に取得 Step 2: 取得した user_id リストでIN句を使った最終検索 パフォーマンス改善の結果 終わりに We are Hiring!
LLMによる自然言語を用いたDB問い合わせ機能の実装例 | DevelopersIO
はじめに こんにちは、Zennチームの五十嵐です。 Zennでは、日々の運用業務（お問い合わせの調査やデータ分析など）において、DBに対してSQLでデータを参照する事があります。非定型作業については毎回SQLを手書きしていましたが、人間がSQLを書くのではなくAIに任せられないかと考え、独自の管理画面からデータベースに対して自然言語で問い合わせをできる機能を実装しました。（将来的にはタスクをAI Agentが自律的に解決できるようになるのがベストですが、今回はその第一歩です。） 当初このアイディアは、データベースに対応したMCPサーバーを用いることで実現できることが検証できました。しかし、現時点ではMCPサーバーのリスク診断を行うエコシステムが成熟していないため、もしMCPに悪意のあるコードが混入されたら？と考えると、本番環境で使うにはリスクが大きいと考えました。そこで、MCPを使わずに自
履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複
PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
PostgreSQL チューニングよもやま話 - エムスリーテックブログ
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
Web APIを手作りする時代は終わった？
::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
まだ PostgreSQL の開発で疲弊してるの？ - Qiita
{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // （ SQLite など他の RDS と競合させないためです。） // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq
決済システムの残高管理周りの DB 設計と戦略 - カンム テックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
運用中のPostgreSQLのスキーマを無停止で安全に変更する | 株式会社ヌーラボ(Nulab inc.)
初めに こんにちは。ビジネスチャットサービスTypetalkを開発・運用している吉田です。Typetalkではデータの永続化ストレージとしてPostgreSQLを利用しています。扱うデータ量は多く、チャットというサービスの性質上書込み頻度はとても高いです。PostgreSQLを使い日々開発を進めていると、追加する機能によってはスキーマを変更する必要があります。メンテナンスを計画・告知してサービスを止めてしまえば、時間はかかるかもしれませんがスキーマの変更はそう難しくありません。しかしTypetalkはユーザーが日々の業務を進めるために利用しており、サービスが止まるとコミュニケーションが取れなくなります。業務を円滑に進めるためのビジネスチャットツールですので、極力サービスは止めたくありません（最後の計画メンテナンスは2019年6月30日で1年以上前となっています。）。本記事では以下の3つのケ
100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
ERDをPlantUML形式で自動生成するツールを作った - くりにっき
PlantUML + ERDでPlantERDです github.com モチベーション PlantERDの特徴 使い方 出力するテーブル数の制限について 技術的に頑張ったこと テストのこと Foreign keyで隣接している別のテーブルを探す方法 複数DB対応のつらみ 追記：2019/12/13 9:45 モチベーション 既存プロダクトへの不満が一番大きいです。 https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい そもそもRails前提なので他言語とかでは使えない https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する 僕は初め
稼動統計情報を活用しよう(2) | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 笠原 辰仁 稼動統計情報を取得してみよう では、実際に稼動統計情報を取得してみましょう。稼動統計情報は、PostgreSQLのテーブルやビューの形で提供されています。pg_stat_* という名称のテーブル/ビューがそれらに当たります。そのため、取得にはSQLを用います。なお、psqlの\dコマンドなどでpg_stat_*のビュー定義を見てみると、pg_stat_get_*() 関数で各種情報が取得されていることが分かると思います。稼動統計情報を直接取得するには関数を使うのですが、それをビュー経由でユーザが閲覧できるようになっています。本項では、pg_stat_*で提供されているビューを読み解いていくことにします。 それでは、前ページの冒頭で紹介した情報について具体的に解説していきます。下記は稼動統計情報の中でも多用される情報ですので、覚えておくと
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
PostgreSQLでテーブルの制約を確認する。 - Tihiroのストレスフリーな生活
概要 前回（PostgreSQLでテーブルの定義を確認する。 - Tihiroの頭を休めるIT教室）はPostgreSQLでテーブル定義を確認する、ということでした。 今回は、テーブルの制約を確認したいと思います。 例によって環境は PostgreSQL9.6 です。 確認してみる メタコマンドで確認してみる 前回、テーブル定義を確認したのと同じく ¥d テーブル名 で確認できます。便利ですね！ SELECT文で確認してみる メタコマンドとは違って、SELECT文で制約を確認するのは少しめんどいです。なぜなら、情報スキーマ内の複数のビューを参照する必要があるからです。 めんどいことは細かく分解して解決するのが一番です。 ということで、 主キー制約 CHECK制約 外部キー制約 ユニーク制約 の４つに分けて確認してみます。 1.SELECT文で主キー制約を確認する テーブルの主キー*1を確認
PostgreSQLでauto_explainを使ってどのクエリが遅いか把握する - $shibayu36->blog;
ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースエンジニアの仕事を楽にする。PgAssistantの紹介
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
