Lakebase Searchのサイジング：実際のアプリと400万件のパッセージから得た教訓

Slide Hubは、Databricks社内のアプリケーションです。フィールドエンジニアは、イベントの講演、製品デッキ、アーキテクチャデッキなど、約700個の社内プレゼンテーションからスライドを検索し、再利用するために使用しています。検索バーでは意味やキーワードで単一のスライドを検索でき、Model Context Protocol (MCP) サーバーによってAIエージェントにも同様の検索機能が提供されます。アプリは、スライド、投票、検索テレメトリ、変更履歴を Lakebase Postgresに保存します。Lakebase Postgresのベンチマークの基準としてSlide Hubを使用しています。これは実際のユースケースとユーザーを持つ実稼働アプリであるため、その数値は実際のワークロード下でデータベースがどのように動作するかを示しています。 本記事は、Databricks上でアプリを構築し、アプリ自身のLakebase Postgresデータベース内で検索を実行したい開発者やアーキテクトを対象としています。SQLおよびPostgreSQLの基礎知識があることを前提としています。Lakebase Postgres上で検索バーやエージェントツールを計画している場合、以下の数値は本番環境へ移行する前のコンピューティングサイズの選定に役立ちます。 この記事では、Slide HubがLakebase Postgres内でどのように検索を実行するか、負荷がかかったときに何が制限となるか、コストがどのくらいかかるか、そして公開コーパスの100万行から400万行においてLakebase Searchがどのように動作するかを解説します。 アプリとその検索のための単一データベース Lakebase Searchは9月に一般提供（GA）が開始されました。これは一連の Postgres拡張機能であるため、アプリケーションテーブルと同じ場所で動作します。アプリがデータを別の検索システムにコピーすることはありません。開発者が2つ目のトランザクションパスを維持する必要もありません。 2つの CREATE...