あなたが望むことを実行し、既製のレポート ツールを使用できるようにする DBMS はないと思います。低レイテンシの分析システムは、迅速かつ簡単に構築できるものではありません。非構造化データの低レイテンシーは非常に野心的です。
ただし、何らかのデータベースにデータを永続化する必要があります。
問題のドメインを詳しく調べる必要があると思います。低遅延の分析レポート、または特定のイベントが発生したときにビジネス内で何らかのアクションを促す運用レポートを実行しようとしていますか? 低遅延システムの場合、何が運用レポートを構成し、何が分析を構成するかについて、非常に冷酷である必要があります。
編集：企業が支払う準備ができていない限り、「潜在的に両方」の考え方を思いとどまらせてください. 投資銀行やヘッジファンドは、大金を投じてスーパーコンピューターを購入し、「リアルタイム分析」を行っています。それは些細な仕事ではありません。そのようなシステムを実行して、高い稼働率のために構築しようとすると、さらに簡単ではなくなります。
プレミアム料金の SMS サービスや .com アプリケーションなどのアプリでさえ、問題の現実的な範囲とコストの分析を行うと、ビジネスが後退することがよくあります。私はこれを十分に言うことはできません。「リアルタイム」の要件については、本当に冷酷である必要があります。
ビジネスで本当にリアルタイム分析が必要な場合は、ファクト テーブルにマーチング リード パーティションがあるハイブリッド OLAP アーキテクチャを作成できます。これは、ファクト テーブルまたはキューブが履歴データ用に完全にインデックス付けされているアーキテクチャですが、インデックス付けされていない小さな先行パーティションがあるため、比較的迅速にデータを挿入できます。
分析クエリは、比較的小さい先行データ パーティションをテーブル スキャンし、他のパーティションに対してより効率的な方法を使用します。これにより、データの待ち時間が短くなり、履歴データに対して効率的な分析クエリを実行できるようになります。
新しい先頭パーティションにロールオーバーし、前の先頭パーティションを統合/インデックス化するプロセスを毎晩実行します。
これは、ビットマップ インデックス (データベース上) や具体化された集計 (キューブ上) など、挿入時にコストがかかる項目がある場合にうまく機能します。リード パーティションは比較的小さく、テーブル スキャンが安価ですが、少しずつ挿入するには効率的です。ロールオーバー プロセスは、このリード パーティションをインデックス化された履歴データに段階的に統合し、レポートのために効率的にクエリできるようにします。
編集 2: 共通フィールドは、ファクト テーブルのディメンションとして設定する候補になる可能性があります (発信者、時間など)。あまり一般的でないフィールドは、(おそらく) コーディングです。効率的なスキーマのために、オプションのコーディングを 1 つ以上の「ジャンク」ディメンションに移動できます。.
簡単に言うと、ジャンク ディメンションは、2 つ以上のコードの既存の組み合わせを表すディメンションです。表の行は、単一のシステム エンティティに関連するのではなく、コーディングの一意の組み合わせに関連しています。ディメンション テーブルの各行は、生データで発生する個別の組み合わせに対応しています。
分析値を取得するには、ジャンク ディメンションの列に一貫して意味のあるものが含まれるように、データを整理する必要があります。これは、ソース データからのマッピングが意味のあるものであることを確認するための要件作業に戻ります。長さ 0 の文字列 ( ) などのプレースホルダー値を使用することで、常に記録されるとは限らない項目を処理できます''。これは、おそらく null よりも優れています。