@tony_stark

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

AI時代、分析用DBと業務用DBの境界はなくなっていくと思いますか?

AI時代、分析用DBと業務用DBの境界はなくなっていくと思いますか?

最近、AI/LLM向けのデータ基盤を考える機会が増えてきました。ベクトル検索やRAG、リアルタイム分析などの要件が増え、ClickHouseのような分析特化型DBが「AIスタックの基盤」として注目されているのを感じます。

そこで気になっているのが、従来の「業務用DB(OLTP)」と「分析用DB(OLAP)」の使い分けが、これからどうなっていくのかという点です。

これまでは、

  • トランザクション処理は PostgreSQL や MySQL
  • 大量データの集計・分析は別の分析基盤

というように、役割で明確に分けるのが定石でした。

しかしAIの普及で、

  • アプリのデータをそのままベクトル検索したい
  • リアルタイムのログをすぐ分析にかけたい
  • 1つのデータをトランザクションにも分析にもAIにも使いたい

といった「境界をまたぐ要件」が増えている気がしています。

そこで質問です。

  1. みなさんは今、トランザクション用と分析用のDBをどう使い分けていますか?
  2. AIやベクトル検索の要件が入ってきて、構成は変わりましたか?
  3. 将来的に、これらの境界は「統合される」方向だと思いますか?それとも「役割分担はむしろ明確になる」と思いますか?

設計思想の話でも、実際の構成事例でも構いません。みなさんの考えや経験をぜひ聞かせてください!

2 likes

1Answer

個人的には、「完全に統合される」というより、物理的には近づくが、設計上の役割分担は残ると思っています。

今のところ自分なら、基本は次のように分けます。

  • 業務データの正本: PostgreSQL / MySQL などのOLTP
  • ログ、イベント、集計: ClickHouse / BigQuery などのOLAP
  • RAG・類似検索: pgvector / Qdrant / Elasticsearch / OpenSearch など

AI要件が入って変わった点は、「後で分析基盤に流す」だけではなく、アプリのデータをリアルタイムにAIへ渡す前提で設計するようになったことです。

例えば、

  • 商品、ユーザー、注文などはPostgreSQL
  • 行動ログやイベントはClickHouse
  • ドキュメントや説明文はembedding化してvector DB
  • 必要に応じてCDCやキューで同期

のような構成が現実的だと思います。

一方で、すべてを1つのDBに寄せすぎると、トランザクション性能、スキーマ変更、分析クエリの負荷、ベクトル検索のチューニングがぶつかりやすくなります。

なので将来的には、

「DBが1つになる」
というより、

「OLTP / OLAP / Vector / Search の境界を意識せず扱えるレイヤーが増える」

方向に進むのではないでしょうか。

アプリ開発者から見ると統合されて見えるけれど、内部では用途ごとに最適化されたエンジンが分担している、という形が一番自然だと思います。

0Like

Your answer might help someone💌