私は、OLAPがPower Pivotで、私が知っている限り、データとのやり取りを高速化するために使用されていることを知っています。LookerとChart.ioのようなSQLターゲットBIソリューションはOLAPを使用しますか？
しかし私は、Google BigQueryやAmazon RedShiftのような大きなデータ・データベースがここ数年に登場したことを知っています。 LookerやChart.ioのようなSQLターゲットBIソリューションは、OLAPを使用しているのか、データベースの速度に頼っていますか？
ルーラーはデータベースの速度に依存しますが、データをモデル化して速度を向上させます。モードと潜望鏡はこれに似ています。 Chartioについては不明。
クエリ速度に役立つデータを整理するためにOLAPを使用しました。 Power PivotやPentahoなどの多くのBI製品で使用されていますが、いくつかの企業ではデータを整理してクエリ速度を向上させる独自の方法を構築しています。場合によっては、データを構成するためにデータを独自のデータ構造に格納することも含まれます。 Birst、Domo、Gooddataなどの多くのクラウドBI企業がこれを行っています。
Lookerは、データストアに格納されたデータをモデル化するためにLookMLというモデリング言語を作成しました。 OLAPが作成されたときよりもデータベースの速度が速くなるため、Lookerはデータを照会するためにデータストア（Redshift、BigQuery、Snowflake、MySQLなど）に直接接続するアプローチを取っていました。 LookMLモデルを使用すると、ユーザーはデータとのインタフェースをとってからクエリを実行し、テーブルやビジュアライゼーションで結果を得ることができます。
私はBIソリューションに関するいくつかの経験を持っています（例えば、私たちはTableauと協力していました）。これは2つの主要なモードです：サーバーに対してクエリを実行するか、関連データを収集してユーザーのマシンに格納しますアプリがインストールされているサーバーで）。大量の作業をするときは、SQL Serverマシンが他のマシンと比較して非常に強力であるため、TableauにSQL Server自体を照会させていました。
データをローカルに保存して「更新」したい場合でも、データを更新するときにデータベースから取得する必要があります。これは高価な操作になる場合もあります。データが構築され整理される）。
また、Google BigQueryとAmazonのRedShiftは実際にはデータの保存やクエリに使用されていましたが、BIとレポートソリューションのほとんどはクエリに関するより多くの概念がありますデータとそれを視覚化し、したがって（一般的に言えば）スマートな内部データベースを（少なくとも私の経験から）持っていることにあまり集中していません。