← 2026-09-19 の一覧へ戻るホーム
純粋な Zig を用いたゼロから構築した検索・推論データベース

2026/09/16 0:35

純粋な Zig を用いたゼロから構築した検索・推論データベース

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

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Antfly v0.2 は決定的なアーキテクチャ転換を表し、コアのドキュメントストレージおよびインデックスエンジンを Go から Zig に書き換え、迅速な開発サイクルよりも生パフォーマンス、統合的なシステム制御、外部依存関係の完全排除を優先しています。ガベージコレクションと複雑なライブラリ設定を排除した新エンジンにより、開発者はメモリを直接管理し、非安全なコードパスなしで SIMD などの機能を実装できます。この書き換えは優れたポータビリティと C 互換性を提供し、高価な翻訳レイヤーではなく単一のフラグで CUDA、Wasmtime、Metal といった先進技術とのネイティブリンクを可能にし、Rust を選択する理由としてその単一 C 互換コンパイラおよび隠されたアロケーションの欠如を挙げています。堅固な安定性は、ディスク、ネットワーク、クロック障害を意図的に導入する VOPR シミュレーションハネスと、TLA+ のトレース検証によって保証されます。

統合型バイナリ（または Kubernetes オペレーター）は、単一ファイルから CockroachDB まで多様なストレージバックエンドをサポートし、独自の LSM/B+tree エンジンも備えています。包括的な機能スイートを提供し、フルテキスト検索、ベクトル（dense/sparse）、グラフトラベル、多模态入力（OCR、文字起こし、埋め込み）のためのエンリッチメント能力を含んでいます。クエリエンジンは標準 HTTP API、SQL/Postgres ワイヤプロトコル、AI エージェントをサポートし、計算バックエンドは CPU/SIMD/GPU をカバーし、主要なモデル形式（GGUF、ONNX）とアーキテクチャに対応しています。ユーザーは、LoRA などの手法を用いて Gemma のようなモデルをハードウェア上で直接微調整でき、リモートプロバイダーのエコシステムまたはローカル推論を活用できます。このリリースは、競合他社との広範なベンチマーク（Rowan を通じて）により検証され、10,000 記事分の Wikipedia データセットなどの大規模データセットを瞬時にロードするクイックスタートデモによって実証され、複雑な多模态ワークフローにおけるシステムの安定性と速度が証明されています。

本文

ANTFLY v0.2: 「完璧な検索」への道と、なぜ書き直しを決断したのか

同僚のロワンが要約する ANTFLY（アンツフライ）の野心的な目標は**「完璧な検索」**です。達成不可能に見えるこの巨大な課題こそが、私達のチームに適しているのです。壮大な技術者たちが語るのはSFドラマのエピソードのように聞こえますが、不可能な目標を好む私たちは皮肉を楽しみ、そこでの失敗さえも「至るべき興味深い場所」と捉えています。

ここから、なぜスタートアップで避けられるはずの**「製品を書き直す」**作業を行ったのか、そしてその結果どういった成果を生み出したのかを整理します。

第一原理と初期の開発

第一原理

かつてほど頻繁には使われない言葉ですが、意思決定の基準として依然重要視されています。ANTFLY v0.1 の開発目标是**「データベース市場における空白を埋める」**ことでした：

  • フレンドリーなクエリ: Elasticsearch 並みのスキーマ親和性。
  • スケール: Postgres に近い性能。
  • 運用容易さ: Iceberg や MongoDB のような使いやすさ、Spanner や Bigtable 並みの運用性。

開発初期には現在の AI アシスタント（Codex, Claude, Aider など）を利用できませんでした。当時の主要な技術的課題は以下の通りでした：

  • 「分散システム」と「並行処理」: CockroachDB が Go を選択した理由と同じ分野での挑戦。
  • 言語選択: Rust はメモリ安全性を保証できますが、Go が圧倒的に読みやすい。また、実戦テスト済み（etcd）の Raft 実装が存在し、Bleve 基盤で Elasticsearch DSL を構築することが可能でした。

モデルに関心を寄せる、埋め込みにはしない

技術的注目は埋め込みモデルからシフトしました：

  • 技術の進化: Word2vec がベクトルに意味を持たせ、開発者は自社アプリ向け Google Lite 風セマンティック検索を実装可能になりました。
  • 市場の実態: Pinecone の資金規模などを考えると、アルゴリズム自体が過大評価されている側面もあります。しかし、**「ユーザーはモデルそのものに関心を持ちさえすればよい」**という着想こそが重要です（埋め込みの詳細を知る必要はない）。
    • ユーザーは B 木やインデックスの詳細を知らなくて良い（PostgreSQL の事例参照）。
    • 同じく Bleve/Lucene では S2 インデックスなどの詳細を知りません。
  • ANTFLY v0.1 の成果: 論文ベースの実装でしたが、ラップトップ上でのセマンティック検索可能な Wikipedia を構築する等、大きな成功を収めました。

Zig への移行：なぜ書き直しを決断したか

移行の背景

TigerBeetle と出会ってから、Zig で VSR や LSM の実装を試みていましたが、Raft や全文検索などの欠乏機能があったため未熟でした。しかし、GitHub デザインスレッドを通じて Zig の 

std.Io
が持つ革命性を目にし、以下の決定を下しました：

  1. 非同期 I/O とイベント駆動: 
    std.Io.Evented
    を活用した LSM の実装。
  2. ソフトウェア要因分解のテスト: Raft、TLA+ 仕様、明確なトレース、言語非依存テストへの挑戦。
  3. フレームワークの再構築: Go エンドツーエンドテストを Python に書き換え、コーディングエージェントによる「チート」を防ぎつつ SDK の堅牢性を確保。

なぜ書き直しなのか：非対称な成果と信頼性

多くのスタートアップが倒れるため、高パフォーマンスな依存関係を自前で書くことは価値ある投資です。データベースは機能し、信頼できなければなりません。「走る」のではなく**「飛ぶ」**（驚異的に速い）必要があります。

書き直しの理由は言語選択において明確な 4 つのポイントがあります：

  • 汎用性と C 互換性:
    • Zig はすべてのターゲットに対応する libc を備えた C コンパイラのようなもので、CUDA/ONNX/Wasmtime のクロスコンパイルが容易。
    • Rust は純粋なクロスコンパイルは可能ですが、C 依存関係に失敗し（
      cargo-zigbuild
      のような仕組みが必要）、Zig よりも劣ります。
  • 速度:
    • 同じ LLVM ベースだが、デフォルトで高速版を採用。割り当てや分岐をアロケーターが管理し、バックグラウンド処理が可能。
    • Rust はホットパスが 
      unsafe
      で実装されることが多く、Zig の「GC 無し、スケジューラ無し、CGO 無し」の方が単純で高速です。
  • テスト可能性:
    • Zig の 
      std.Io
      は世界をパラメータ化し、VOPR（障害シミュレーション）が容易。
    • Rust では Tokio を madsim/turmoil に置き換える手間がありましたが、Zig でそれらを実装するのは簡単です。
  • 完全な制御:
    • 主要な依存関係すべてをフォークして所有し、メモリ/CPU/GPU リソースをプロセス全体で統合的に管理（「ゼロ依存」ポリシーの実践）。
    • C ライブラリは何のイベントもなくリンクでき、外部ライブラリがエンジンを包み込むことを防ぎます。

書き直しの難しさ

  • Go バージョンはすでに信頼性が高く、競合他社と比較しても驚異的に高速でした。
  • Zig は 1.0 未満で標準ライブラリが変化中であり、ツールも未熟です。
  • 家族を始める準備期間という**「成功への簡単なレシピではない」**タイミングでもありました。

得られた成果：ANTFLY v0.2 の機能

書き直しにより、以下のような包括的な機能を最初から VOPR シミュレーションテストを組み込んで提供しています。

データエンジン

  • ドキュメント: スキーマに近い JSON、列形式保存、プロジェクションプッシュダウン（Mongo/Elasticsearch 風）。
  • 関係型: クローズドスキーマ、Postgres からの派生インデックス（フルテキスト、ベクトル、グラフなど）。
  • レイク: Iceberg/Parquet 対応、外部テーブルクエリ、サイドカーによる材料化。
  • 外部ソース: PostgreSQL から論理複製によるストリームテーブル出力。

ストレージエンジン

4 つのモードすべてで、独自の LSM、LMDB 互換 B+ 木、WAL、TTL を実装し、シミュレーションハネス付きです：

モードデータベース特徴
シングルファイルSQLite / .afliteバイナリ、fsync、シングルノード
PostgresPostgreSQLバイナリ、ホットスタンバイ（フェンシングあり）
分散型CockroachDBマルチ-Raft、オンラインシャード分割
サーバーレスNeon / Lakebaseオブジェクトストレージ対応

インデックスエンジン

  • フルテキスト: Lucene 風セグメント、S2 インデックス、フェイジークエリ、ハイライト機能。
  • 高密度ベクトル: RaBitQ 圧縮、SPFresh 風インクリメンタルポスティング維持（フィルタリング可能）。
  • 疎ベクトル: SPLADE 学習型スパースレトリバル。
  • 遅延相互作用: ColBERT 風 MaxSim、Multi-vector ドキュメント。
  • ハイブリッド融合: リプロシロカルランク融合、1 つのクエリ計画での結果トリミング。
  • 代数的/グラフ: 集約機能、Neo4j トラベサル、PageRank 風クエリ。

エンジン全体の特徴

  • 拡張エンジン: アセットプロデューサーによるアーティファクト化、再処理可能。
    • 入力形状: テキスト、PDF、画像、音声、ビデオ。
    • ドキュメント: Florence-2 OCR、LayoutLMv3 レイアウト理解。
    • マルチモーダル: CLIP/Gemma 埋め込み、音声転写（Whisper/CLAP）。
    • 構造化: GLiNER2 エンティティ抽出、型付きフィールドへの書き込み。
    • Autograph: グラフインデックスの自動生成。
  • クエリエンジン: Lucene DSL、SQL (DDL, CTE, ウィンドウ関数)、エージェントツール連携。
  • 埋め込みサーフェス: Kubernetes オペレーター、C API (
    antfly-embedded
    )、WASM インフラランタイム。
  • コンピュートバックエンド: CPU(SIMD)、Metal、CUDA (JIT)。
  • モデルランタイム: GGUF, safetensors, ONNX 対応（BERT, Qwen2, Gemna, Whisper など）。
  • 微調整: LoRA/QLoRA, SFT/DPO/ORPO/SimPO/GRPO/RFT、NEFTune。

正しさの先へ：検証と評価

厳密な正しさに加え、効果性と使いやすさを保証するため、以下を実施しています：

  • VOPR シミュレーションハネス: LMDB、LSM、WAL、Raft、メタデータなど全コンポーネントへの適用。
  • 形式検証: Raft に対する TLA+ トレース検証の実施。
  • 言語非依存テスト: Python エンドツーエンドスイートの共有と利用。

**Model カード（リリースカード）**を導入： LLM のように、データベースのベンチマークやドメイン横断的な評価を行い、RAG や OCR、メモリシステムとしての性能を客観的に測定しています。また、ユーザーが重視する機能を容易に実装し、データベースユースケースをスケールするための新しいベンチマークも構築しています。

結論

**「完璧な検索」**という目標は依然として大規模で達成不可能ですが、Go の時代よりも遥かに近づいています。今回は残りの道のりを進めるために基礎を書き直す必要があり、Zig への移行によりその基盤が固まりました。

詳しくは以下のリソースをご参照ください：

同じ日のほかのニュース

一覧に戻る →

2026/09/19 6:00

これまでに Claude.md が存在しない場合、Claude Code は現在 AGENTS.md を読み取るようになりました。

2026/09/19 3:51

さらに 100TB のメモリーを節約

## Japanese Translation: Cloudflare は、トラフィックの分散に常時ハッシュリング（consistent hashing）を処理する Pingora バックエンドルーターの一部である `pingora-ketama` コンポーネントの最適化により、メモリ使用量を成功裡に削減しました。変更前に、システムはサーバーごとに過剰なハッシュエントリを格納しており、コンプライアンスとキャッシュの必要性により数十個の別々のハッシュリングが生じる場合があり、一部のケースでは 6GB に達することもありました。統計解析により、サーバーあたりに単一のハッシュのみを使用すると深刻な不均衡（変動係数約 99%）が発生し、業界標準デフォルトはハッシュ数を約 160 としていることが示されました。数学的な導出により、32 ビット値に対して 10,000～100,000 ハッシュを超えると追加容量が限界に達し衝突リスクが増大することが確認されました。エンジニアは、サーバーごとの生成されるハッシュ数を 90% 削減しても分布誤差が大きくならないことが安全に確認できました。構造レベルでは、完全な構体（struct）全体を 8 バイトのインデックス（`u32`）と、4 バイトのハッシュを圧縮された生バイト配列形式に置き換えることで、エントリあたりのメモリ使用量を 25% 削減しました。新コードは、非公開の機能フラグを通じて段階的に導入され、旧バージョン（大リング）と新バージョン（小リング）が共存可能となっています。ロールアウトは小規模な検証ロケーションから始まり、グローバルなキャッシュ churn を回避し安全な移行を確保するよう層状に行われました。これらの変更により、サーバーあたりのハッシュ生成数を 90% 削減し、グローバルメモリ消費量を 100TB 以上削減することで、コスト効率、信頼性、ロールバックの安全性を向上させました。

2026/09/18 23:18

クラウドフレイク・クイックトンネル

## Japanese Translation: 本テキストは、アカウント、DNS 設定、または開放ポートを必要とせず、開発環境向けに安全なパブリック URL を瞬時に生成する強力なコマンドラインツールを紹介しています。Cloudflare のグローバルインフラストラクチャを活用することで、このソリューションは 335 都市以上に対応し、構築済みの TLS と DDoS 保護を備えた即時のアウトバウンド専用暗号化接続を提供します。このアプローチは、`npm run dev` などのツールのエンドポイントを一貫して共有しながら既存のコードベースを変更しないようにすることで、開発者のワークフローを簡素化します。 処理は約 3 秒で完了し、構造化された JSON（ホスト名、エッジロケーション、ヘルスステータスを含む）として URL をコンソールに直接印刷して簡単なパースを可能にします。重要なのは、これらのトンネルは一時的で、ホスティングプロセスが停止すると自動的に終了し、手動での片付けを必要としないことです。この設計により、シンプルな JSON ホスト名を用いて、Webhook（例：Stripe、GitHub）、コーディングエージェント、および人間によるブラウザからローカルサービスへとの統合を容易にします。最終的に、これは内部マシンを公開する際の課題を解決し、Anycast ルーティングを介して最近のエッジノードへと接続することで不要なオーバーヘッドなしに、プライベートの localhost アプリケーションとパブリックインターネットの間で効率的な橋渡しを提供します。