HNSWのフィルター付きベクトル検索の課題を解決する -pgvectorをマルチテナント環境で用いたインデックス戦略-
「社内版ビズリーチ by HRMOS（以下、社内版ビズリーチ）」では、自然な言葉で社内の人材を探すことができるセマンティック検索機能を提供しています。セマンティック検索には、ベクトル検索を用いており、PostgreSQLの拡張機能であるpgvectorとHNSWインデックスを使用しています。 ベクトル検索には、専用のベクトルデータベースを使用するなど様々な選択肢があります。「社内版ビズリーチ」は新規プロダクトであり、高速な価値検証が求められていました。そのため、運用負荷を下げ、開発スピードを優先できるよう、APIサーバーで使用するPostgreSQLにpgvectorを導入するというシンプルなアプローチでセマンティックサーチを実現しました。 ベクトル検索で一般的に使用されるHNSWインデックスは、高速なベクトル検索を実現しますが、フィルター条件と組み合わせて使用することが難しいという仕組み
Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL データベース向け AI 搭載チューニングツール: PI Reporter | Amazon Web Services
Amazon Web Services ブログ Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL データベース向け AI 搭載チューニングツール: PI Reporter AWS では、Amazon Relational Database Service (Amazon RDS) のデータベースパフォーマンスメトリクスを収集・分析するためのいくつかのサービスを提供しています。これには Amazon CloudWatch と CloudWatch Database Insights が含まれます。さらに、さまざまなツールを使用して Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL-Compatible Edition を監視するためのカスタムダッシュボードを作成できます (詳細
PostgreSQL設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに 本ガイドラインはPostgreSQLを使用する開発者向けに
Aurora DSQLの楽観同時実行制御を手を動かして学ぶ | DevelopersIO
「楽観同時実行制御ね。おーおーおー、そういうことね。なるへそ？」 Aurora DSQLは、re:Invent 2024の最大の発表でした（個人の感想です）。キーノートの最中に、いきなりGoogle CloudのSpannerが引き合いに出されるほどだったので、Spannerファンの人にも要チェックのアプデだったのではと思います。 マルチリージョン対応 高可用性とスケーラビリティ VPCの外で稼働 サーバーレス設計 ACID特性のサポート PostgreSQL互換rd 楽観的同時実行制御（OCC）の採用 分散アーキテクチャ など、ポイントが目白押しのAurora DSQLですが、トランザクション制御の仕組みが、RDBでは聞き慣れない楽観的同時実行制御（OCC）が採用されていると聞き、改めてその挙動を手を動かしてまとめてみました。 はっきり言います。ドキュメント読んでいるだけより手を動かした
Re: 履歴テーブルから最新の1件を取ってくる方法
そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr
PostgreSQLで時間枠を適切に扱う設計 - そーだいなるらくがき帳
はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複
履歴テーブルから最新の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 and UUID as primary key
UUIDs are often used as database table primary keys. They are easy to generate, easy to share between distributed systems and guarantee uniqueness. Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide. This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently. P
GitHub - HexaCluster/pgdsat: PostgreSQL Database Security Assessment Tool
PGDSAT is a security assessment tool that checks around 90 PostgreSQL security controls of your PostgreSQL clusters including all recommendations from the CIS compliance benchmark but not only. This tool is a single command that must be run on the PostgreSQL server to collect all necessaries system and PostgreSQL information to compute a security assessment report. A report consist in a summary of
マルチテナントにおけるRow Level Securityの具体的な実装と注意点 - そーだいなるらくがき帳
文脈、背景や問題点の説明 マルチテナントを実装するうえで企業情報（以下company）単位で最小限の情報を扱うようにしたいがcompany単位にTableを作ったりDatabaseを作るのはALTERなどの運用が大変。 そこでRLSを採用するために実際の技術検証をした上での注意点と実際の運用について必要な情報をまとめる。 PostgreSQL 14を前提としている 公式ドキュメント CREATE POLICY 必ず一読はすること。 困ったとき、わからないときはまずは公式ドキュメントを都度見ること。 このドキュメントのゴール RLSの概要をつかめる RLSの最低限の注意点を理解し、実装時に罠を踏まない 自分たちでRLSのポリシー自体をメンテナンスすることができ、デバッグできる テーブル構成 create table if not exists company ( id uuid defaul
パフォーマンスチューニング9つの技 ～「探し」について～｜PostgreSQLインサイド
今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ～はじめに～ パフォーマンスチューニング9つの技 ～「書き」について～ パフォーマンスチューニング9つの技 ～「探し」について～（本記事） パフォーマンスチューニング9つの技 ～「基盤」について～ 1. パフォーマンスチューニングの「探し」とは PostgreSQLは、SQLが発行されると、アクセス先のデータの特性を示す『統計情報』を参照
パフォーマンスチューニング9つの技 ～「書き」について～｜PostgreSQLインサイド
今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ～はじめに～ パフォーマンスチューニング9つの技 ～「書き」について～（本記事） パフォーマンスチューニング9つの技 ～「探し」について～ パフォーマンスチューニング9つの技 ～「基盤」について～ 1. パフォーマンスチューニングの「書き」とは 一般的にデータベースは、大量データを扱い、大量の問い合わせや更新を高速に処理し、さらに障害発生
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Decathlon/dblinter: A static analysis tool for postgresql databases
8.17. 範囲型
PostgreSQL DISTINCT ON
Prisma ORMを2年運用して培ったノウハウを共有する
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
GitHub - dalibo/pev2: Postgres Explain Visualizer 2
Optimizing bulk loads in Postgres, and how COPY helps with cache performance
PostgreSQL技術インデックス｜PostgreSQLインサイド