ブログ

2つのアーキテクチャ、短時間

上の図は、TURBOARDの層がどのように調和しているかを示しています。 記事の残りの部分では、周囲の環境が厳しくなるにつれて、各アーキテクチャがどのような機能を持つかを検証します。

公平なシナリオ:インメモリが勝つとき

明確に言う価値がある: データセットがRAMに快適に収まる場合、並行性が控えめな場合、およびアプリケーションに適した環境のサイズが整うと、Qlik センスは本当に高速です。 アソシティブエンジンは成熟したエンジニアリング技術であり、フィルターをクリックしてアグリゲーションをミリ秒単位で再計算するユーザーエクスペリエンスは、当日において非常に優れている。 部門の展開、集中型分析アプリケーション、およびデータモデルが安定し、十分に理解されているワークロードにおいて、インメモリ方式は真の強みである。

これは、ほとんどの製品デモンストレーションが中心に構築されているシナリオです。 また、データが増加し、ユーザー数が拡大し、さらに3つのアプリケーションが同じサーバーに展開されたことから、プラットフォームが本番開始から1年でどのように動作するかを最も簡単に示すシナリオも含まれる。

スケーリングシナリオ:アーキテクチャが分岐する場所

Qlik自身のサポートドキュメントでは、メモリモデルを詳細に説明しています。 エンジンは、いわゆる2つの設定可能な閾値に対して動作します 動作速度は低く、動作率は高く、デフォルト値は70%、物理RAMは90%です それぞれ。 低しき値以下では、エンジンはキャッシュされた計算結果を積極的に保持し、使用されていないメモリはメモリを無駄にするという原理で管理します。 低い閾値を超えると、エンジンはキャッシュされた結果を取り出して新しい結果を得る余地を作り出し、年齢、サイズ、元の計算時間による立ち退きを優先します。 高い閾値を超えると、キャッシュが効果的に停止し、エンジンを存続させるためにオペレーティングシステムのページファイルが作動する可能性がある。 Qlikのドキュメントでは、ページファイルの使用によりパフォーマンスが大幅に低下する可能性があると記されています。

その閾値の間に生じる仕組みは、閾値自体よりも重要である。 キャッシュされた結果はすべて、ユーザーが次にリクエストしたときに再計算が必要な計算です。 立ち退きが加速するにつれて、計算負荷はメモリからCPUへと変化する。 高い並行環境では、多くのユーザーがキャッシュされた回答を残さない計算を同時にトリガーする中で、CPUが新たなボトルネックとなる。メモリ圧力とは異なり、CPUの圧力はユーザー可視の遅延として直接現れる。つまり、格納するダッシュボード、数秒かけて適用するフィルター、その時間外セッションなどである。

TURBOARDのハイブリッド方式は、負荷の分布を異なる方法で行います。 未集計データセットはRAMを占有する必要がないため、 柱状ストアは、ディスクから分析クエリに効率的に回答するように設計されています — 10年前にはメモリ内処理が必要だったような高速で、クエリが触れる列のみを読み、大量の圧縮を悪用して集計を実行できるようにする。 増量読み込みにより、完全なリロードを繰り返し強制することなく、カラムストアを新鮮に保ちます。これにより、ユーザーはRAMで完全なデータセットを保持できるメモリコストを伴わず、ほぼライブデータを体験できます。 Redisキャッシュは、アクセラレーションの恩恵を最も受けるクエリを高速化します。これは、実際のエンタープライズ展開において、クエリボリューム全体のごく一部にすぎません。 次のセクションでは、その理由について説明します。

ライブデータ:ダイレクト・ディスカバリー問題

利用可能なメモリを超えたワークロードに対するQlikの答えはDirect Discoveryであり、このモードでは次元フィールドがメモリに読み込まれ、測定フィールドはソースデータベースに残り、要求に応じてクエリされます。 設計の意図は妥当であり、文書化された制限は重要である。

ターボードにとって、ライブ接続は記憶力の負担を防ぐ手段ではない。 建築の一流部分です。 ネイティブデータベースのドライバは、一般的なODBC接続ではなく、Apache Kuduのようなビッグデータプラットフォームを含むソースシステムへの直接的かつ高性能なアクセスを提供します。 キャッシュトリガーメカニズムにより、ユーザークリックごとにソースデータベースが攻撃されるのを防ぎます。TURBOARDは指定されたトリガーフィールド(更新されたタイムスタンプなど)を監視し、基盤となるデータが変更されていないときにRedisのキャッシュ結果を配信し、トリガーが新しいデータが利用可能であることを示す場合にのみ、ソースを照会します。 高度な分析機能は、ウィジェットがキャッシュから、カラムストアから、またはライブソースから読み取り可能かどうかにかかわらず、引き続き完全に利用可能です。 1つのダッシュボードで、妥協することなく3つすべてを混在させることができます。

パレトの洞察と、それを守る特許

エンタープライズBIの展開において、ユーザーの行動は予測可能なパターンに従います。 ユーザーの約80%が同じコアダッシュボードに繰り返し戻っています — エグゼクティブ要約、月次業績報告、地域ごとの展開。 残りの20%は、同じ形式で再度実行されない可能性のあるアドホッククエリを実行している電源ユーザーです。 メモリ管理の意味は直接的である。キャッシュされた結果すべてが同様に価値があるわけではない。また、それらを同等のものとして扱うシステムは、最も高価なリソースを無駄にしている。

Qlikの立ち退きモデルは行動盲である。 キャッシュされた結果は、年齢、サイズ、および元の計算時間に基づいて削除されます。これは、実際にユーザーが実際に要求する頻度に基づくものではありません。 メモリが満たされると、エンジンは経営陣が毎朝チェックするダッシュボードと、最近キャッシュされた一過性のクエリと区別することができません。

TURBOARDは逆のアプローチを取っている。 レポートが閲覧されるたびに、その人気スコアはRedis Sorted Setで生成されます。これは、まさにこのようなランクアクセスパターン向けに設計されたデータ構造です。 このシステムは、実際に使用されているレポートを連続して管理し、メモリが密接であるときにキャッシュ内に何が残るかを決定するために、そのリーダーボードを使用します。 最も要求されたレポートはRedisで保護されており、それらに依存するユーザーの大多数に対してゼロレイテンシで応答します。 キャッシュを見逃したパワーユーザーのクエリは、カラムストアまたはライブソースにルーティングされます。どちらも、高値のキャッシュされたコンテンツを置き換えることなく、それらのクエリにすばやく対応するように設計されています。

隣り合って

結論

Qlik Senseは、依然として高性能なインメモリ分析プラットフォームであり、バインドドデータセット、予測可能な同時実行性、大容量メモリのプロビジョニングなど、さまざまな条件で優れた性能を発揮します。 この投稿が答えようとした質問は、そうした状況が重なりにくくなるにつれてどうなるかということです。 データ量が縮小しているわけではない。 並行投資の期待は緩むものではない。 そして、メモリのコストと可用性が、久しぶりに誤った方向に進んでいる。

TURBOARDのアーキテクチャは、次の10年間のBIパフォーマンスがプラットフォームによって勝ち残されるだろうという考えである メモリを豊富に使うのではなく、賢く使いましょう。 ハイブリッドデータアクセス、カラムストレージ、ネイティブライブ接続、特許取得済みの使用スコアキャッシュにより、TURBOARDはメモリ予算において企業規模のパフォーマンスを実現でき、完全にメモリ内部でのアーキテクチャが共存するのが難しくなります。

違いを見る準備はできましたか?

Qlik センスを評価している場合、あるいはすでにそれを実行中で、この記事で説明されているメモリの圧力を感じ始めている場合、TURBOARDのハイブリッドアーキテクチャが同じワークロードをどのように処理しているかをぜひお見せします。

チームと一緒にウォークスルーを予約し、自社のデータをもとにプラットフォームが機能している様子をご覧ください。 プレッシャーはありません。特定のニーズに合った適切な条件を見つけた方がよいです。

また、私たちのものを探索することもできます 完全なBI比較 より多くのエンタープライズシナリオでどのように積み重ねていくかを確認するためのページ。