寓話
商隊は倉庫が一つではないと発見した
隊商には最初、倉庫が一つしかなかった。すべての貨物、帳簿、地図、顧客の手紙をそこに詰め込んだ。番頭が何かを尋ねると、使用人は中に入って探した。荷が少ないうちは、この倉庫は万能の道具のようだった。
後に貨物は複雑になった。重量で探す箱もあれば、産地で探す箱もあり、「この布地の風格に近い」貨物を探すものもあり、契約、在庫、輸送リスクを同時に確認するものもあった。
主人はまずもっと大きな戸棚を買い、すべての問題を戸棚に入れれば解決すると主張した。数か月後、戸棚には確かに多くのものが入ったが、権限、フィルタリング、バックアップ、遅延、コスト、クエリ方法がすべて混ざり合っていた。
そこで彼は町で最も高価な専用倉庫に切り替えた。類似の貨物はすぐ見つかるが、会計係は古い帳簿の文法で照合したい、輸送隊は地域で絞り込みたい、安全責任者はアクセス記録を確認したいと、誰もが自分には別のツールが必要だと気づいた。
一人の老管事が隊商のニーズを広げて見せた。ローカル試験は軽く、本番サービスは安定し、大量の貨物はシャーディングでき、古い帳簿は旧帳簿の構文を受け入れ、検索隊はキーワードと類似度を同時に使う必要がある。
彼はもうどの倉庫が最も先進的かとは問わず、倉儲地図を描いた：専用ベクトル庫、検索エンジン、データベース拡張、埋め込みサービス、インデックス庫、マネージドクラウドサービス、評価と監視、それぞれを置くべき場所に置いた。後に商隊はさらに一条の調達規則を加えた：まず問題を書き、それから倉庫を選ぶ。ただの試作品試験なら宮殿を買うな；顧客権限、バックアップ、災害対策が関わるなら小さな戸棚を無理に戦場へ押し出すな。
キャラバンはシナリオごとに倉庫を選び始めた。小規模なプロトタイプには軽量なローカルストレージ、正式な業務にはフィルタリングと権限を備えたベクトルデータベースを使う。既存の Postgre旧帳簿構文 の台帳は拡張機能で受け止め、検索シナリオではキーワードインデックスとベクトルインデックスを並べて配置する。倉庫マップも更新される。新しい貨物カテゴリの出現、法規制の変更、クエリ量の増加は、いずれもどこかの倉庫の位置を変える。エコシステムの価値は名鑑が揃っていることではなく、キャラバンがビジネスの成長に合わせて、依然として貨物を見つけられ、帳簿を管理でき、コストを払えることにある。
この地図は選択を派手にするどころか、むしろ意思決定を素朴にした。データ量はどれほどか、遅延要件はどれほど厳しいか、フィルタ条件はどれほど複雑か、チームにはどのシステムがあるか、運用能力は足りているか。店主は最後に悟った。本当の問題はベクトルデータベースという箱を買うことではなく、検索・ガバナンス・コスト管理を継続的に支えるエコシステムを築くことなのだと。