← 2026-09-20 の一覧へ戻るホーム
Tin：Postgres フルテキスト検索

2026/09/19 22:52

Tin：Postgres フルテキスト検索

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary:

Neki から TIN（「Text INdex」）という一般利用可能な Postgres エキステンションがリリースされました。これは既存のデータベースへのドロップイン置換としてすぐに使用できる、高パフォーマンスな全文検索のための拡張機能です。ブール式・フレーズ・スパンクエリー、フッジー/ワイルドカード/正規表現一致、ケース/アクセントフォールディング、COUNT(*) と BM25 スコア付き top-k 結果、およびジョイン、複雑な WHERE クロース、更新、レプリケーション、バックアップ、MVCC トランザクション可視性と互換性があります。Postgres 18.6 を実行する AWS i7i.8xlarge でのベンチマーク結果は以下の通りです：

  • パレード DB より 25 倍、Postgres GIN より 541 倍も多く、混合された conjunction/disjunction/phrase top-10 ランククエリーで p99 レイテンシーはパレード DB より 26 倍低い性能を示しました。
  • 並行書込みを対象とした disjunction クエリー（目標：1,000 UPDATEs/sec）では、pg_textsearch より 36 倍、パレード DB より 57 倍多くのクエリを処理し、10 分間に 27 万回以上の更新を完了させました。対照的に競合他社はそれ以下の更新数でした。
  • インデックスが共有バッファーに収まる場合、8 GB の Wikipedia コーパスに対する COUNT(*) disjunction クエリーでは 10,260 QPS を達成し、パレード DB は 291 QPS、Postgres GIN は 1.4 QPS にとどまりました。

本文

PostgreSQL 用高速全文検索拡張機能「TIN」が正式に発表

PostgreSQL で最も要望の多い機能が全文検索。それをさらに高速化・高機能化した拡張機能**「TIN（Text INdex）」**が正式にリリースされました。

TIN の概要と即時利用

TIN は現在、すべての PostgreSQL および Neki データベースにおいてGA（General Availability）版として利用可能です。

基本的な使用法

以下の SQL コマンドでインデックスを作成・クエリを実行できます。

-- インデックス作成
CREATE INDEX an_index_name ON table_name USING tin(text_column_name);

-- 検索クエリ（BM25 スコアを含む）
SELECT * FROM table_name WHERE text_column_name ==> 'some words';

サポートされる主要機能

優れた全文索引として、以下の機能をすべてサポートしています。

  • 論理演算式：Boolean expressions の対応
  • 高度なクエリ：フレーズクエリ、スパンクエリの対応
  • マッチング精度：
    • 単語に対する模糊一致（Fuzzy matching）
    • ワイルドカードマッチング
    • 正規表現マッチング
  • 文字列処理：大文字小文字不区別、アクセント記号の無視（Case and accent folding）
  • スコアリング：
    COUNT(*)
    クエリと BM25 スコアに基づく Top-K クエリの対応

既存インデックスとの差別化

PostgreSQL には既存の全文検索インデックスがいくつか存在しますが、それらは以下のような要件をすべて満たしていませんでした。TIN はそれらを達成しました。

  • JOIN 処理への完全な対応
  • 複雑な WHERE クロウズ（全文検索列を含む）の高速化
  • 継続的なデータ更新への耐性
  • レプリケーション、バックアップ、トランザクションの可視性との共存

TIN の主な使用ケース

アプリケーション開発者は TIN を多様な検索機能構築に利用します。

1. E コマースプラットフォーム

検索キーワードをすべて含む上位 10 件の商品を返す必要时有効です。

SELECT * FROM products
  WHERE description ==> 'stretch denim jeans'
  ORDER BY tin.score(ctid) DESC
  LIMIT 10;

2. 法的証拠収集プラットフォーム

特定のキーワードのいずれかを包含する文書を検索し、ランキングは不要な場合にも対応します。

SELECT * FROM emails
  WHERE body ==> '[insider trading conspiracy]';

3. ファイルタグ付けプラットフォーム

特定のタグを持つファイルの正確な件数を表示する際などに利用します。

SELECT COUNT(*) FROM photos
  WHERE tags ==> '"san francisco"';

注意点：検索クエリは、新しい行や変更された行がコミットされた直後に一致結果を返す必要があります。TIN はこのリアルタイム性を満たします。

パフォーマンスベンチマーク

TIN は以下の負荷条件でテストが行われました。

  • クエリ種別：
    • 連語（AND）、論理和（OR）、フレーズクエリの単独使用
    • これらを組み合わせた混合クエリ
    • Top-K ランキングおよび 
      COUNT(*)
  • 同時書き込み負荷：
    • クライアントがインデックスに新たなデータを書き込む場合
    • 書き込まない（読み取り専用）場合
  • 使用コーパス：
    • 全ての Wikipedia コーパス
    • Reddit コメント集（合計 2.3 TB）
    • Stack Exchange Q&A（85 GB、1.5 億件文書）※人工的にクエリ生成

テスト環境

  • インフラ：AWS i7i.8xlarge EC2 インスタンス（NVMe ストレージ、AVX-512 CPU）
  • 設定：PostgreSQL 18.6、vCPU 8 コア、RAM 32 GB
  • ツール：ParadeDB Benchmarker（フォーク版を使用） 
    • max_parallel_workers
      : 40 → 8
    • shared_buffers
      : 128 MB → 24 GB
    • maintenance_work_mem
      : 64 MB → 24 GB

インデックス構築時間の比較（総時間 / サイズ / RAM）

インデックス総時間インデックスサイズ必要な RAM
TIN8m10s50.7 GB32 GB
ParadeDB19m20s52.1 GB64 GB
pg_textsearch26m49s41.5 GB128 GB
Postgres GIN2h09m04s28.0 GB64 GB

主要ベンチマーク結果（読み込み専用環境）

  • 混合クエリ負荷：TIN は ParadeDB に比べて25 倍高速。p99 レイテンシは26 倍低減。
  • 論理積・フレーズクエリ：
    • TIN vs ParadeDB：10 倍高速（p99: 6 倍低減）
    • TIN vs GIN：541 倍高速（p99: 1,356 倍低減）

同時書き込み負荷環境での結果

  • 論理和クエリ + UPDATE 処理：
    • TIN: pg_textsearch に比べて36 倍、ParadeDB に比べて57 倍高速。
    • p99 レイテンシはそれぞれ 24 倍、36 倍低減。
    • 10 分間の更新件数：TIN(27 万) vs ParadeDB(18 万) vs pg_textsearch(735)。
  • メモリー不足の問題：
    • ParadeDB は読み取りスループットとレイテンシを犠牲にして書き込みを受け付ける。
    • pg_textsearch は継続的な読み込みにより書き込みが停止する（ロック競合）。
    • GIN は論理和クエリ時にメモリ不足となりベンチマーク完了できなかった。

完全な比較結果表

論理積・フレーズクエリ（Top-10）

エンジンモードQPSp99 レイテンシMB/query
TIN読み取り専用242212ms73
ParadeDB読み取り専用241,279ms668
Postgres GIN読み取り専用0.4288,066ms595

論理和クエリ（Top-10）

エンジンモードQPSp99 レイテンシMB/queryアップデート数 (10 分間)
TIN読み取り専用148324ms48-
TIN同時更新あり125354ms77270,279
ParadeDB読み取り専用172,385ms303-
ParadeDB同時更新あり2.212,634ms394185,584
pg_textsearch読み取り専用3.58,646ms11,639-

Wikipedia コーパスでの COUNT(*)（論理和）

エンジンQPSp99 レイテンシMB/query
TIN10,2602ms1.7
ParadeDB29195ms22
Postgres GIN1.430,292ms2.5

結論：多様なシナリオにおいて、TIN はスループットが少なくとも8 倍高く、ディスク読み取りデータ量は大幅に少なく、高速な更新処理も可能です。

TIN がなぜこれほど高速なのか（アーキテクチャ解説）

TIN の高速性は以下のアーキテクチャ選択によるものです。

1. ドキュメントの識別：ctid の直接使用

多くのテキスト検索システムは「セグメント」と「連続した ID（1〜n）」を使用し、ID を ctid に変換する必要があります（マッピング維持）。これにより大量のメモリと処理が発生します。

  • TIN のアプローチ：PostgreSQL の**
    ctid
    （現在のタプル識別子）**をそのままドキュメント ID として使用します。
  • 利点：
    • ctid は PostgreSQL 内部で既に使われているため、追加のデータ構造が不要。
    • ヒープ上の物理位置 
      (ページ番号，オフセット)
      を直接参照できるため、O(1) の即時アクセスが可能。
    • 巨大な一致結果（千万件以上）を ctid マッピングなしで処理可能。

2. 48 ビット識別子の効率化

通常、非連続な 48 ビットの数字を圧縮するデルタ符号化やビットマップは不向きですが、PostgreSQL のページ構造により最適化されます。

  • 仕組み：8KB ページ内には最大 291 タプルしか収まりません（実際のテキスト表ではさらに少ない）。
  • 結果：
    • ページ番号とオフセットのリストは、高密度なビットマップとして圧縮可能。
    • 高頻度用語：ポスティングあたり約 1 ビット。
    • 低頻度用語：約 25 ビット。
    • 一度出現しない用語：保存不要。

3. ワークエリジョンとベクトル化（AVX-512/AVX2）

TIN は CPU のベクトルレジスタをフル活用しています。

  • ビットマップサイズ：ページレベルのビットマップは 256 ビットで収まり、AVX2 レジスタに完全に適合。
  • 演算加速： 
    • AND
      / 
      OR
      命令により、一度に 256 ビット分のデータを処理。
    • 共通ビットがない場合、詳細なオフセット情報を参照するコストを回避可能（カウントクエリの高速化）。
  • I/O 最適化：ディスクからランダムアクセスせず、シーケンシャルアクセスでページを読み取るため、NVMe でも非常に高速。

4. MVCC（マルチバージョンコンカレンシー）の正しい扱い

TIN はトランザクションの可視性を尊重し、消去された行や未確定な変更を返さないよう設計されています。

  • ヒープチェック：データ列を含むクエリは、ctid 照合後に実際にヘープからデータを取得し、スナップショット可視性を確認。
  • 可視性マップとのインターセクション：
    COUNT(*)
    クエリなどで、ページレベルのビットマップと PostgreSQL の可視性マップを直接演算し、不要なヘープアクセスを削減。
  • ライブネスビットマップ：VACUUM で削除された ctid を管理し、古いデータが混入しないよう即時に除外。

5. セグメントとマージ戦略（書き込み増幅の回避）

一般的なシステムはマージ時にすべての ID を再番号付けし、データを再圧縮する必要があります（ストレージ使用量増加）。

  • TIN のアプローチ：ctid は不変であるため、セグメント統合時にID 変更が不要。
  • メリット：
    • ビットマップをそのまま再利用可能（再圧縮なし）。
    • データのコピー・書き換え量が極めて少ない。
    • メモリ使用量とディスク I/O が大幅に削減。

まとめ

TIN は、以下の理由によりすべてのベンチマークで少なくとも 8 倍高速の性能を発揮しています。

  1. ctid のネイティブ活用：追加のマッピングなしで高速な物理アドレス参照を実現。
  2. 高度な圧縮技術：Postgres ページ構造を exploited し、48 ビットデータを極限まで圧縮。
  3. ベクトル化処理：現代 CPU（AVX-512）の全機能を活用した並列演算。
  4. 正確な MVCC 実装：トランザクション整合性下でも高速な読み書きを提供。
  5. ゼロコストマージ戦略：セグメント統合時のオーバーヘッドを排除。

TIN をご活用いただくことを心から期待しております。詳しくは公式ドキュメントをご覧ください。

同じ日のほかのニュース

一覧に戻る →

2026/09/19 19:46

1 年前に RL を用いた非自己回帰型決定モデルを構築した

## Japanese Translation: 本テキストは、エンタープライズワークフローを悩ませてきた高遅延と幻覚（ハルシネーション）のリスクを排除することを目的として設計された画期的な完全にオープンソースの AI モデル「Laya」を紹介する。標準的な生成型大規模言語モデルがしばしば 500〜2,000 ミリ秒の遅延を経験するのに対し、Laya は単一の GPU で顕著な 32.8 ms の遅延を実現し（バッチ処理された質問の場合には 7.2 ms）、これを達成するためには形式自由なテキスト生成を完全に回避し、代わりに辞書からオプションを選択する「choice」命令、順序付けされた評価基準レベルを割り当てる「score」命令、および真理値論理によって有用でない出力を示す「noul」という 3 つの特定の決定プリミティブのみを通じて構造化データのみを出力することを行っている。この建築学的なシフトは、ルーティングやスパム検出などの重要なタスクに対して瞬時に数学的に校正された確率を確保し、100 言語以上をカバーしている。TypeSafe の「Jev」といったプロプライエタリ競合製品に優越するように開発された Laya は、企業がローカルで展開することを可能にし、API 手数料と運用コストを大幅に削減する。将来的な改良により、現在のトークン予算の制限を超えたより大きなオプションセットを処理することが予想され、英語専用モデルに見られる一般的な失敗がないグローバルかつマルチスキーマの意思決定のための堅牢なソリューションとなるだろう。

2026/09/19 18:20

生成 AI で作られたポスターがひどいものに終わる必要はありません。

## Japanese Translation: チャットGPT は、AI アートにしばしば関連づけられる反復的・一般的な外見を避け、独自で高品質なポスターデザインを容易に生成できます。初期の要求では標準的なテンプレートが生成される場合もありますが、具体的な指示を与えることで、文脈に応じたテキストオーバーレイ付きのバウハウス幾何学や日本のミニマリズムなど、多様な芸術スタイルを解き放つことができます。以前の批評において「すべての AI 画像は同一である」と主張されていた点とは対照的に、洗練されたプロンプティングは、鑑賞者が直ちに機械生成であると特定しにくい独自性のある視覚コンテンツの作成が可能であることを証明しています。さらに、Claude や Gemini などの他の高度なモデルも、編集可能なテキスト層を含む PDF や HTML ファイルといった実用的に使用可能な形式を出力し、デザイナーが必要なグラフィックアセットを素早く取得する際に実践的な利便性を提供します。これらの成功した結果を他者が再現できるようにするために、著者は様々なポスタースタイルを網羅した 100 の即座に使用できるプロンプトのカタログを編纂しました。このリソースにより、各新しいプロジェクトに対して複雑な手動指示を必要とせずに、多様な視覚コンテンツを迅速に生成できるようになります。結局のところ、効果的なプロンプティングは、AI を退屈なデフォルトの源から、実世界のデザイン基準を満たすプロフェッショナルでユニークなグラフィックを作成する強力なツールへと変革します。

2026/09/20 5:00

インターネット検閲を測定し、最大級のオープンデータセットに貢献しましょう。

## 日本語訳： オニー・プローブは、インターネット検閲に関する世界の最大のオープンデータセットの中核を成すものであり、主に異なる国でどの特定のウェブサイトやアプリがブロックされているかを検証することを目的として設計されています。该软件の核心には、WhatsApp、Facebook Messenger、Telegram などの主要プラットフォームが利用者のネットワーク上でアクセス可能であることを確認するテストが含まれています。さらに重要なのは、M-Lab と共同で作成された標準化された測定方法である NDT テストを活用して、一般インターネットの速度と安定性を評価することです。このツールは Linux および macOS で動作し、個人の利用者がデジタル自由の解決策（例えば回避アプリ）が実際にはローカルの制限に対して機能しているかどうかを検証する能力を付与します。個人の検証を超えて、オニー・プローブ は研究者や組織に、世界の検閲トレンドを追跡するための不可欠なデータを提供します。M-Lab と協力することで、オープンソースコミュニティ全体で一貫性のある信頼できるパフォーマンス指標が確保されています。