運用データベース：仕組みと使い分け

運用データベース、またはオンライン トランザクション処理（OLTP）データベースは、日常のビジネスオペレーションを支えるリアルタイム トランザクションを処理するように設計されています。運用データベースは、データを迅速に保存および取得できるように設計されており、アプリケーションを実行し続ける作成、読み取り、更新、削除の継続的なストリームを処理し、トランザクションが正確かつ確実に完了することを保証します。

このガイドでは、運用データベースの仕組み、分析システムとの違い、および最新のクラウドおよび分散環境で高スループット、低レイテンシのワークロード向けに設計するために必要なことについて説明します。

運用データベースのコア特性

運用データベースは、ライブオペレーションのためにトランザクションデータをリアルタイムで効率的かつ確実に保存および更新するように設計されています。運用データベースを定義するコア特性は次のとおりです。

• リアルタイム処理: データはバッチ処理ではなく、即座に書き込まれ、利用可能になります。トランザクションはミリ秒単位でコミットされ、アプリケーションが常にビジネスの最新の状態を反映することを保証します。
• CRUD 操作: 作成、読み取り、更新、削除の 4 つの基本的な操作が、トランザクションアプリケーションを支えています。フォームの送信から支払いの完了まで、すべてのユーザーインタラクションは、これらの操作の 1 つ以上をトリガーします。
• データの鮮度: データベースは現在の状態のデータを保存します。たとえば、在庫運用では、データは前四半期の状態ではなく、現在の在庫数値を反映します。これは、運用上の意思決定および顧客向けシステムにとって重要です。
• 高い同時実行性: 同時実行制御メカニズムにより、重複するトランザクションが共有データを破損しないことが保証されます。数千人のユーザーが競合やエラーなしに同時に読み書きできます。
• ACID ガランティ: データベースは ACID（原子性、一貫性、分離性、永続性）プロパティを強制し、有効で完全なトランザクションのみが保存され、データ整合性が維持されることを保証します。各トランザクションは正しく完了するか、まったく完了しません。

運用データベースとデータウェアハウスの比較

運用データベースは、組織の継続的な運用をサポートするためにリアルタイムデータを保存および管理するように設計されています。対照的に、データウェアハウスは、ビジネスインテリジェンスと分析のためのデータを提供する構造化されたリポジトリです。データは、クエリと分析に最適化されたスキーマにクリーニング、変換、統合されます。

運用データベースとデータウェアハウスの両方がビジネスデータを保存しますが、それらは異なる方法で動作し、異なる目的を果たします。

ほとんどの組織にとって、これはどちらか一方の問題ではありません。両方の種類のデータシステムが必要です。運用データベースは、ミッションクリティカルなトランザクションを促進し、それらのトランザクションからのデータをキャプチャします。このデータは、さらなる分析とインサイトを促進するためにデータウェアハウスに供給されることがよくあります。レイクハウス アーキテクチャが単一のプラットフォームで運用ワークロードと分析ワークロードを統合するにつれて、運用データベースとデータウェアハウスの境界はますます曖昧になっています。この収束により、組織はバッチレポートからニアリアルタイム分析に移行でき、トランザクションからインサイトまでの時間を短縮できます。

OLTP vs. OLAP: プロセッシング モデルの理解

OLTP とオンライン分析処理（OLAP）モデルの両方が、大量のデータを管理および分析するために不可欠ですが、それらは異なるタスクのために設計されており、明確な目的を果たします。OLTP は、ライブオペレーションのためにトランザクションデータをリアルタイムで効率的かつ確実に保存および更新することに焦点を当てているのに対し、OLAP は、ビジネスインテリジェンス、データマイニング、および分析レポートのために設計されています。

OLTP システムは短いトランザクションを処理し、行レベルの操作を実行して日常のビジネスアクティビティを効率的に処理します。それらは書き込み中心のワークロードに最適化されており、速度とデータ整合性を維持しながら、大量の小さく同時実行されるトランザクションを処理することに焦点を当てています。通常、データ整合性を維持し、冗長性を減らすために正規化されたスキーマを使用します。

一方、OLAP システムは、複雑なクエリを実行し、列レベルのスキャンを実行して大量のデータを分析することに優れています。それらは、集計や分析などの読み取り中心の操作に最適化されており、クエリパフォーマンスを向上させるために非正規化されたスキーマを一般的に使用します。

組織は、包括的なビジネスインテリジェンスのために OLTP と OLAP の両方のデータ処理をよく使用します。OLTP から OLAP へのパイプラインは、運用データベースによって生成されたトランザクションデータを、抽出、変換、ロード（ETL）または変更データキャプチャ（CDC）プロセスを通じてデータウェアハウスまたはレイクハウスに移動し、アナリストが意思決定をサポートするためにクエリを実行します。運用データストア（ODS）—別のアーキテクチャコンポーネント—は、完全なウェアハウスロードのレイテンシなしに、運用レポートのために複数のソースからのニアリアルタイムデータを統合するために、OLTP と OLAP システムの間に配置される場合があります。

従来の OLTP データベースが最新のワークロードで不足する理由

OLTP システムは、分析または AI ドリブンワークロードではなく、高速で信頼性の高いトランザクション処理のために設計されました。しかし、最新のアプリケーションは、リアルタイム分析、柔軟なデータアクセス、および AI システムとの統合を必要とし、従来の OLTP アーキテクチャの強みと最新システム のニーズとの間にギャップを生み出しています。ハイブリッド ソリューションは、このギャップを埋めるのに役立ちます。

AI およびインテリジェント アプリケーションにおける OLTP データベースの制限

従来の OLTP データベースには、最新の AI およびインテリジェント アプリケーションを完全にサポートする機能が欠けています。それらは分析および AI ワークロードからサイロ化されていることが多く、使用前にデータを遅い ETL パイプラインを通じて移動する必要があります。それらは構造化データ用に設計されており、構造化されていない形式、埋め込み、またはベクトル検索（最新の AI システムの基盤となる機能）のネイティブ サポートはありません。厳密なスキーマは、急速に進化するエージェントおよび AI アプリケーションに不可欠な迅速なイテレーションを困難にします。スケーラビリティの観点からは、垂直スケーリングはすぐに実用的な限界に達しますが、シャーディングによる水平スケーリングは運用上の複雑さを増します。従来の OLTP システムは、きめ細かなアクセス制御、ライン追跡、およびコンプライアンス機能など、責任ある AI デプロイに必要な重要なデータガバナンス機能も欠いていることがよくあります。

最新のデータ アプリケーションの要件

最新のデータ アプリケーションには、バッチ パイプラインの遅延なしに運用ワークロードと分析ワークロードを統合し、最新データへのリアルタイム アクセスを可能にするプラットフォームが必要です。それらは、多様なユースケースを可能にするために、単一のシステム内で構造化、半構造化、非構造化、およびベクトル データを含む幅広いデータ型をサポートする必要があります。ガバナンス、セキュリティ、およびラインは、追加されるのではなく、組み込まれている必要があります。これらのアプリケーションは、予測不可能なワークロードを効率的に処理するための弾力的なサーバーレス スケーラビリティと、インテリジェントで応答性の高いシステムをサポートするために、AI/ML パイプライン、フィーチャ ストア、およびエージェント ドリブン コンテキストとの低レイテンシ統合も要求します。継続的に進化するデータで動作します。

Databricks Lakebase がギャップを埋める方法

レイクベースは、従来の OLTP システムの制限を解決します。レイクベースの主な機能は次のとおりです。

• ストレージとコンピューティングの分離: データはクラウド オブジェクト ストアに安価に保存され、コンピューティングは独立して弾力的に実行されます。これにより、大規模なスケーリング、高い同時実行性、および 1 秒未満でのゼロへのスケールダウンが可能になります。
• 無制限で低コスト、耐久性のあるストレージ: データがレイクに格納されるため、ストレージ コストは、固定容量インフラストラクチャを必要とする従来のデータベース システムよりも大幅に低くなります。また、そのストレージはクラウド オブジェクト ストレージの耐久性によってバックアップされます。
• 弾力的なサーバーレス Postgres コンピューティング: 需要に応じて即座にスケールアップし、アイドル時にはスケールダウンする完全に管理されたサーバーレス Postgres を提供します。
• インスタント ブランチング、クローニング、および復旧: データベースは、開発者がコードをブランチするようにブランチおよびクローンできます。
• 統合されたトランザクションおよび分析ワークロード: Lakebase は Lakehouse とシームレスに統合され、OLTP と OLAP の間で同じストレージ レイヤーを共有します。
• オープンでマルチクラウド対応: オープン形式で保存されたデータは、プロプライエタリなロックインを回避し、クラウド全体での真のポータビリティを可能にします。

運用データからインテリジェント アプリケーションへ

運用データは、AIエージェント、リアルタイムの意思決定、インテリジェントなアプリケーションを支えるため、価値があります。従来の運用データベースは、リアルタイムデータを効率的に保存および処理できますが、今日の要求には対応できません。Databricks Lakebase は、AI搭載アプリケーションのために運用データの価値を最大限に引き出すのに役立ちます。

AIの基盤としての運用データ

組織内のすべてのトランザクションは、AIモデル、エージェントの決定、および予測分析に利用できるデータを生成します。Databricks Lakebase は、運用システムからデータウェアハウスへのデータの移動によって生じる遅延を排除することで、運用データをほぼリアルタイムで AI に利用できるようにします。その結果、組織は、ライブ在庫に基づいて行動する AI エージェント、発生時にトランザクションをスコアリングする不正検出システム、最新のアカウントデータで動作するコパイロットなどのユースケースを実現できます。

Databricks Platform 上での構築

Lakebase は Databricks Platform 上に構築されており、データ、分析、AI を単一のプラットフォームに統合します。

• Delta Lake は、信頼性が高く柔軟な運用データに対して、ACID トランザクション、タイムトラベル、スキーマ適用をレイクハウス規模で提供し、信頼できる基盤となります
• Mosaic AI は、運用データをモデルトレーニング、ファインチューニング、エージェント、RAG に直接接続し、ライブデータでのシームレスな AI 開発を可能にします
• Unity Catalog は、すべてのデータにわたる統一された権限とエンドツーエンドの系統を持つ、単一で一貫したガバナンスレイヤーを提供します
• サーバーレス SQL と組み込みストリーミングは、インフラストラクチャを管理する必要なく、リアルタイムクエリと継続的な取り込みをサポートします

Databricks Lakebase の開始方法

Databricks Lakebase を開始するには、CDC またはストリーミングパイプラインを介して既存の OLTP システムを Delta Lake に接続し、バッチ指向のデータ移動の必要性を排除します。取り込まれると、運用データはプラットフォーム全体で即座に利用可能になり、SQL 分析、BI ダッシュボード、ML ワークフロー、および AI エージェントが最新の継続的に更新されるデータで動作できるようになります。この合理化されたアプローチにより、チームは、従来の遅延や個別のシステムの複雑さなしに、取り込みからインサイトとアクションまで迅速に移行できます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事