トランザクションデータ用のDBの最適化と分析データ用のDBの最適化の間にトレードオフが必要なのはなぜですか？
私はデータサイエンティストであり、工学の側面よりも数学とモデリングの側面の方が多く、データベースの設計の基礎となるロジック、データ構造、および設計原理については、「リレーショナル構造化データのDBおよび非構造化データのNoSql DB」など.
頻繁に更新され低レイテンシを必要とするトランザクションデータにdbを使用するか、または偶発的に大規模なバッチ更新を取得し、レイテンシが存在する分析データベースに近いものにするかを選択する必要があるとよく耳にします。制約ではありません。通常、どちらか一方を使用するかどうかを決定する必要があるトレードオフがあることを意味しますか？
私が理解していないのは、なぜこのトレードオフまたは選択が避けられないのかです。私は、ほぼリアルタイムの更新を処理し、ユーザーからメインデータキューブにコミットできるOLAPキューブ（true OLAPプラットフォーム、ROLAPではない）を使用してきました。より大きなモデリングタスクの一部のバッチ処理だけでなく、事前定義された集約ルールと階層に基づいて、さまざまなメトリックをリアルタイムでスライスおよびダイシング、集約/分解することもできます。
そのようなシステムが可能である場合（私が使用したプラットフォームは2000年代半ばから存在しています）、トランザクションデータと分析データの両方を処理できるバックエンドが目的を達成するのが難しいのはなぜですか？
リソース（cpu、メモリ、ディスク）の数には限りがあり、それらをできるだけ効率的に使用したいためです。
OLTPの場合、通常は小さなトランザクションが多く、同時実行性が重要です。データモデルは通常正規化され、ほとんどのデータアクセスはインデックスルックアップを介して行われます。データのサブセットが何度も使用されるため、それをメモリにキャッシュしたい。
OLAP/DWの場合、通常、トランザクションは少なくなりますが、見返りに、トランザクションは大きくなります。書き込みは通常、ETLプロセスを介して行われます。多くの場合、モデルは非正規化されており、何らかの意味でOLAPクエリに備えています。使用されているすべてのデータをメモリに保持することは不可能であることが多いため、ディスクから読み取る必要があり、並べ替えが頻繁に行われます。このメモリ領域は、ここではしばしば重要です。
更新するユーザーの数が限られている限り、キューブのリアルタイム更新は問題になりません。 OLTPシナリオから何百万ものユーザーを投入します。同時実行が行われます。
とはいえ、私が見たほとんどのシステムには、両方の世界が少し含まれています。両方のモデルとそれらの物理的な実装にいくつかの妥協点が見られるでしょう。
SQLとNoSQLに関しては、ここ数年の傾向として、互いに近づいています。 NoSQLはNo SQLからNot Only SQLに変更されました。一方、ほとんどのSQLデータベースでは、XMLやJSONなどの非構造化データがサポートされており、SQL内から効率的にクエリを実行できます。