# Retriever [[Honeycomb.io]] が自社開発した独自の列指向(カラムナ)ストレージエンジン。構造化イベント・トレーススパンを高カーディナリティ・高次元性のまま秒単位でクエリ可能にすることを目的に設計された。当時利用可能な既製のカラム型ストレージエンジンが存在しなかったため自前で構築されたと *Observability Engineering* 第3章は述べる。第13章はこのRetrieverの実装をケーススタディとして解説する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]]) ## 設計の要点 - **時間ベースの追記専用セグメント分割**: テナントごとに新規イベントを現在アクティブなセグメント末尾へ追記し、1時間経過・250,000レコード超・1GB超のいずれかでセグメントを読み取り専用として確定する。各セグメントは最古・最新イベントタイムスタンプのメタデータを持ち、クエリ時はこのウィンドウと重なるセグメントのみを対象にする。行のソート済み挿入やBigtable型のコンパクションを回避できる。 - **セグメント内カラムファイル**: イベントをフィールドごとの追記専用ファイルに分解し、辞書圧縮・疎エンコード・ランレングス符号化・デルタ符号化等で圧縮した後LZ4等で再圧縮する。計算コストを読み取り時に寄せる設計のため、圧縮率より解凍速度を優先する。 - **6ステップのクエリ実行**: セグメント特定→列ファイルスキャン→行再構成→セグメント内集計→セグメント間集計→上位K件選出、という手順を各セグメント独立に並列実行してから最終マージする。 - **S3ティアリング + サーバーレス並列化**: 古いセグメントディレクトリをAmazon S3へ圧縮アップロードし、クエリ時はAWS Lambdaのサーバーレスワーカー群でMapReduce的に並列処理する。テールレイテンシ対策として、90%のセグメント処理が完了した時点で残り10%を並行して再リクエストする「RPCインパーシェンス」を用いる。 - **Kafkaベースのストリーミング取り込み**: Apache Kafkaのパーティション順序保証を利用し、複数のingestionワーカーが同一パーティションを消費しても決定的に同一のセグメントファイルを生成できる設計を取る。 (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]]) ## 本番規模(2025年11月時点) 米国ホスト本番展開は、約1,500 Graviton4 vCPUのレシーバワーカー・240 Graviton2 vCPUのKafkaブローカー・2,000 Graviton3 vCPUのRetriever ingest+queryワーカーに加え最大200,000 Graviton2 vCPUのLambdaバーストで構成される。約1.5PBの列指向データ(顧客データ2ヶ月分、10億超の圧縮セグメントアーカイブ)を保持し、毎秒300万〜500万トレーススパンを取り込みつつ、クエリは秒間数十件・中央値50ミリ秒・P99 5秒のレイテンシで応答する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]]) ## パフォーマンス調査の実例(第20章) Retrieverのクエリフロントエンドで、ネストしたderived columnを含む複雑なクエリ仕様をprotobufからJSONへ変換する`jsonpb`エンコードが、既に高負荷なマージノード上でLambda呼び出しごとに繰り返し実行されていることがCPUプロファイリング(フレームグラフ)で判明した。この処理は特定の1顧客のクエリに起因していたが、当人だけでなく他の全利用者のクエリレイテンシも悪化させていた。対応としてシリアライズ結果をキャッシュ化し、さらに深掘りするとLambda側の実行時間の長さは抽象構文木(AST)ノード数の多さに起因していたため、深くネストした`if-else`連鎖をswitch文に置き換えられるようクエリ言語を拡張することで、Lambda側の実行時間そのものも削減した。この種の内部ループの非効率はトレーシングには現れず、プロファイリングによって初めて発見できたと本章は述べる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] "Blending Performance Engineering and Observability") ## build-versus-buy象限での位置づけ(第29章) 第29章は、build-versus-buyの2×2マトリクスにおける「build(高ビジネス価値×bespoke)」象限の具体例としてRetrieverを引く。Honeycombにとって差別化要因(competitive advantage)となる自社固有の要件が、既製のカラム型ストレージエンジンでは満たせなかったために自前構築が正当化された事例として位置づけられている。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] "Build (upper right)") → [[Build Versus Buy]] ## 関連 - 開発元: [[Honeycomb.io]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] - 概念: [[列指向OLAPデータベース]] / [[データパーティショニング]] / [[Zonemap]] / [[ネスト型カラムナストレージ]] / [[LSMツリー]] / [[ストレージ計算分離]] / [[フレームグラフ]] / [[継続的プロファイリング]] - 比較対象: [[ClickHouse]](第14章で扱われる、同じ課題への別解)