Techopediaスタッフ、2017年1月25日
まとめ：ホストのエリック・カバナがインメモリコンピューティングとSAP HANAについて、ゲストのロビン・ブロア博士、デズ・ブランフィールド、およびIDERAのビル・エリスと議論します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：わかりました、ご列席の皆様 。 こんにちは、おかえりなさい。 それは水曜日の東部標準時の4時であり、ここ数年は、Hot Technologiesにとってもまた同じ時だということです。 はい、確かに、私の名前はエリック・カバナです。今日の会話のホストになります。
皆さん、今日はクールなものについてお話します。 私たちはインメモリの世界に飛び込みます。正確なタイトルは「Into the Future：An-Ramp for On-Memory Computing」です。最近では、それは大流行しています。メモリは、回転するディスクに依存するよりもはるかに高速です。 ただし、課題は、多くのソフトウェアを書き直す必要があることです。 なぜなら、今日のソフトウェアのほとんどは、ディスクを念頭に置いて書かれており、それがアプリケーションのアーキテクチャを実際に変えるからです。 回転するディスクを待つようにアプリケーションを設計する場合、インメモリテクノロジのすべての能力を備えている場合とは異なる方法で作業を行うだけです。
Twitterで@eric_kavanaghにアクセスしてください。 私はいつもフォローして、誰かが私に言及したときはいつでもリツイートしようとします。
先ほど言ったように、今日はインメモリについて、特にSAP HANAについて話します。 昨年は本当にSAPコミュニティをよく知るために費やしましたが、それは魅力的な環境です。 SAPは信じられないほど優れた操作であるため、その操作を実行し、最前線にいる人々に嫌気がさします。 彼らが本当に得意としているのは、ビジネスをすることです。 もちろん、テクノロジーも優れており、HANAに多大な投資を行っています。 実際、私たちが実際に米空軍のために仕事をしていたのは、おそらく6〜7年前だったのを思い出すことができます。SAPから誰かが入って来て、 HANAと何が計画されていたか。 そして控えめに言っても、SAP Labsのスタッフは、すべてがメモリにあるため、従来の環境とはまったく異なるこのアーキテクチャを構築する方法を理解することに多くの時間と労力を費やしていました。 したがって、彼らは、メモリ内の同じデータに対してトランザクションと分析の両方を行うことについて話しているのです。従来の方法では、データを引き出してキューブに入れ、たとえば、そこで分析し、トランザクションではなく、非常に異なる方法で発生します。
これは興味深いスペースであり、実際に別のベンダーであるIDERAから、それらすべてがどのように機能するか、そしてオンランプが何であるかについて率直に調べます。 それで、私たちはここThe Bloor GroupのチーフアナリストであるRobin Bloor博士から話を聞くことになります。 データサイエンティストであり、IDERAの親友であるビルエリスのDez Blanchfield氏。 それで、私はそれを奪うロビン・ブルーア博士に鍵を渡すつもりです。
ロビン・ブロア博士：ええ、エリックが言っていたように、私たちがSAP HANAから最初に説明を受けたのは何年も前のことです。 しかし、それはとても面白かったです。その特定の時間はとても面白かったです。 私たちは、何らかの形でインメモリテクノロジーを提供している1つまたは2つの企業に出くわしました。 インメモリが来ることは明らかでした。 そして、SAPが立ち上がって突然HANAを起動するまで、それは本当にありませんでした。 つまり、SAPがそうするのを見たときはショックでした。 他の場所から来ると思っていたので、衝撃でした。 マイクロソフト、オラクル、IBM、またはそのような人になると思っていました。 SAPがそれを行っていたという考えは、私にとって非常に驚くべきものでした。 SAPは戦略的ベンダーの1つであり、業界で発生する大きなことはすべてその1つから来るため、SAPは戦略的ベンダーの1つであるため、そうすべきではなかったと思います。
とにかく、インメモリに関するすべてのポイント、つまり、実際にインメモリになるとすぐに話したことがあります。これは、メモリにデータを入れることではなく、メモリ層がシステムレコードであるという考え–システムレコードをメモリに移行すると、ディスクはある種のハンドオフメディアになり始め、別のものになります。 そして、それが起こり始めたとき、それは非常にエキサイティングだと思いました。 だから、本当に、それはディスクの回転のために終わった。 スピニングディスクはすぐに博物館にのみ存在します。 私はそれがすぐにどれくらい早くなるかわかりませんが、基本的に、ソリッドステートディスクはムーアの法則曲線上にあり、錆を回すよりもすでに10倍高速です、彼らは今それを呼ぶので、すぐにそれはまだ速くなりますつまり、ディスクのユースケースはますます少なくなります。
奇妙な事実、従来のDBMS、実際には、多くの従来のソフトウェアが回転ディスク用に構築されていました。回転ディスクを想定しています。 スピニングディスクを活用し、データ取得を可能な限り高速にするために、あらゆる種類の物理レベルの機能が綿密にプログラムされていました。 そして、それらはすべて洗い流されています。 消えただけです そして、明らかに、非常に-わからない、luかる、最終的にはそうなると思う-大きなデータベースであるOracleとMicrosoft、SQLの位置を占めようとするインメモリデータベースを開くサーバーとIBMのDB2は、メモリ内のスペースを占有しており、それが前進していくのを見るのは非常に興味深いものでした。
メモリカスケードについて話しましょう。 言及するだけの価値があります。 また、これを言及する理由、私がこれを投げ入れた理由は、本当にここで記憶について話しているときに、私が話しているこれらのレイヤーのすべてが実際に記憶であるということを、単にみんなに知らせることでした。 しかし、これを見てみると、これは階層的なストアであり、単なるメモリではないことに突然気付きます。 したがって、かなり前に階層ストアについて学んだことのほとんどすべてが適用されます。 また、メモリ内のデータベースはすべてこの方法でナビゲートする必要があることを意味します。一部のデータベースはRAM自体を介してただ歩くだけです。 そして、どんどん大きくなっており、現在はメガバイト単位で測定されています。 しかし、メモリの100倍の速度のL1キャッシュ、メモリの30倍の速度のL2キャッシュ、メモリの約10倍の速度のL3キャッシュがあります。 そのため、多くの技術、つまりかなりの量の技術があり、それらのキャッシュを、ある種のストレージスペースとして使用する戦略を採用しています。特にデータベーステクノロジーです。 ですから、それが一つの影響です。
その後、3D XPointとIBMのPCMが登場しました。 そして、それはほとんどRAMの速度であり、基本的にこれらのベンダーの両方が誇るものです。 ユースケースはおそらく異なるでしょう。 これに関する初期の実験はまだ完了していません。 それが、RAMの使用とインメモリデータベースのテクノロジーにどのように影響するかはわかりません。 これで、RAMとSSDが得られます。 現在、RAMは約300倍高速ですが、もちろんその倍数は減少しています。 SSDとディスクは、理解できれば約10倍高速です。 だから、それはあなたが持っているような状況です。 階層型ストアです。 別の見方をすれば、インメモリはもちろんまったく異なります。 そのため、上の図は2つのアプリケーションを示しており、どちらもおそらくデータベースにアクセスしますが、確実に回転する錆のデータにアクセスします。 そして、どの依存関係が存在するかに応じて、実際に物事がネットワークを流れるようにする方法は、ETLを持っていることです。 つまり、データは回転する錆に行き、回転する錆から離れてどこにでも行き、どこにでも戻り、回転する錆に戻ることを意味します。これは3つの動きです。 また、メモリは回転するディスクよりも10万倍高速である可能性があり、データを取得してメモリに格納すると、全体がまったく異なるものになることは確かです。
そのため、ここにある画面に何が起こるかを考えていたかもしれませんが、何らかの方法で、実際にはETLが実際にはデータからメモリ内のデータに移動するだけだと考えたかもしれません。 しかし、実際にはそれができないかもしれません。 実際には、2つのアプリケーションが同じメモリを実際に起動できる状況がここにあります。 確かに、インメモリデータベースは、ロックとそれを中心に調整された他のすべてを持っている限り、その機能を提供できます。 したがって、これは物事の速度を変えるだけでなく、実際にアプリケーションとデータフロー全体を構成する方法を変えます。
ですから、それは大きな影響です。 それで、インメモリは破壊的ですよね？ そして、私は私が言ったことからそれを得る必要があります。 現在、メモリ内処理はアクセラレータですが、それが標準になるでしょう。 アプリケーションの価値に応じて適用されて使用されるため、メモリ内にあるERPソフトウェアのバージョンをSAPが実際にリリースすることは非常に興味深いことです。 そして、レイテンシーの改善は最大3桁まで完全に可能であり、実際にはそれをさらに上回ります。 したがって、メモリ内に移動することにより、速度が大幅に向上します。 そして、結果としてリリースされたSAP HANAのS / 4-人々はそれがまだリリースされていると言いますが、昨年リリースされたことは確かです-SAPの顧客ベースを考えればゲームチェンジャーです。 つまり、SAPのERPを使用している企業は10, 000社あり、そのほとんどが大企業です。 だから、それらすべてがメモリに入って基本を使用するインセンティブを持っているという考えは、ERPはほとんど常にビジネスが実行している基本的なアプリケーションであるため、それは単なる大きなゲームチェンジャーであり、非常に興味深いものです。 しかし、もちろん、それはすべて非常に良い音ですが、インテリジェントに構成する必要があり、よく監視する必要があります。 見た目ほど簡単ではありません。
そうは言っても、ボールを渡すと思います。この男は誰ですか？ ああ、オーストラリア人のデズ・ブランフィールド。
Dez Blanchfield：とても面白い。 常に厳しい行動をとる、ロビン・ブロア博士。 本日はありがとうございます。 だから、大きなトピックですが、エキサイティングなものです。 そのため、現代のデータレイクとエンタープライズデータウェアハウス、および私の小さなデータの宝物について考えているときに、よく思い浮かべるイメージを選択しました。 山と波に囲まれた美しい湖がここにあり、波が岩の上に打ち寄せています。 これは、最近、大規模なデータレイク内でどのように見えるかを精神的に視覚化する方法です。 波はバッチジョブであり、リアルタイム分析はデータに投げかけられます。 それを物理的な湖と考えると、私たちに目覚めの呼びかけが返ってきます。今、私たちが構築しているデータウェアハウスの規模、このコインを思いついた理由、データレイクとは、それらが非常に大きく、非常に深く、時には嵐が発生する可能性があるということです。 そして、私たちがやるとき、あなたはいつも嵐を引き起こしているものを解決しなければなりません。
ですから、このことをテーマにすると、このインメモリコンピューティングのサイレンコールは、非常に強力であり、十分な理由があるように思えます。 それは非常に多くの重要な商業的および技術的利益をもたらします。 それは別の日に数時間の議論です。 しかし、インメモリコンピューティングへの一般的な移行では、まず、ここで得られた方法とこれを可能にするものについて説明します。これは、いくつかの課題が最初に存在する場所と、認知する必要があるものの基盤を設定するからですデータを保持している従来の古い回転ディスクから離れ、ディスクのオンとオフ、およびメモリとメモリからCPUへのページングが行われている私たちの世界では、今ではこれらの層のほぼ1つを削除しています回転ディスクであること。 なぜなら、コンピューティングのごく初期の頃、アーキテクチャ的には、コアメモリやドラムストレージと当初考えていたメインフレームやミッドレンジの世界から長い間移行しなかったことを思い出してください。
Robin Bloor博士が言ったように、コンピュータアーキテクチャ内でデータを移動するために採用したアプローチは、実際にはしばらくの間、実際には数十年間劇的に変化しませんでした。 技術的には、現代のコンピューティングが存在しているという事実を考えると、60年以上もの間、60年以上もの間、しゃれを許してくれるなら、それはあなたができるという意味です棚から箱を買う。 新しいアーキテクチャへの移行は、メインフレームとミッドレンジ、コアメモリとドラムストレージアーキテクチャに関する考えから、勇敢な人やスーパーコンピューティング、特にクロスバーバックプレーンなどのセイモアクレイなどに移行したときに本当に思い浮かびました。ものになりました。 最近のように、バックプレーンまたはマザーボード上でデータを移動するための1つのルートを用意する代わりに。 インラインメモリは、ご存知のように、最近ではDIMMやSIMMと言ったときに実際に何を意味しているのかをよく考えていません。 しかし、SIMMはシングルインラインメモリであり、DIMMはデュアルインラインメモリであり、それ以来、私たちはそれよりも複雑になっています。さまざまな種類のさまざまなメモリタイプがあります。ビデオ用、汎用アプリケーション用、CPU内蔵などです。
そのため、データを保存およびアクセスする新しい方法への大きな転換がありました。 私たちは別の世代全体で同じ変化を経験しようとしていますが、ハードウェア自体ではなく、ビジネスロジックおよびデータロジック層でのハードウェアの採用であり、それは私の心の別の大きなパラダイムシフトです。
しかし、ここまでの道のりについて簡単に説明します。 つまり、ハードウェアテクノロジが改善され、劇的に改善されました。 CPUを使用することから脱却し、コアのアイデアはかなり現代的な概念でした。 スマートフォンには2つまたは4つのコアがあり、コンピューターにはデスクトップに2つまたは4つ、または8つのコアがあり、サーバープラットフォームにも8と12以上があります。 。 しかし、実際には、コアがCPU内の機能になり、32ビットから64ビットに移行したのはかなり現代的なことです。 そこで起こった大きな問題がいくつかあります。複数のコアでより高いクロック速度が得られたため、並行して処理を実行でき、それらの各コアが複数のスレッドを実行できました。 突然、同じデータに対して多くのことを同時に実行できました。 64ビットのアドレス間隔により、最大2テラバイトのRAMが得られました。これは驚異的な概念ですが、今では問題になっています。 これらのマルチパスバックプレーンアーキテクチャ、マザーボード、昔々、一方向にしかできないことができました。つまり、後方と前方です。 そして、Crayコンピューティングや当時のスーパーコンピューターの設計の時代と同様に、現在はデスクトップコンピューターや一般的な市販のデスクトップグレードのラックマウントPCで、実際にはほとんどの場合、現在、PCはメインフレーム、ミッドレンジ、マイクロデスクトップのこの時代を経て、サーバーに戻しました。
そして、そのスーパーコンピューター機能の多く、そのスーパーコンピューター級の設計は、一般的な市販のコンポーネントに組み込まれました。 ご存知のように、非常に安価なラックマウントPCを数千台ではないにしても数百台でラックに入れ、Linuxのようなオープンソースソフトウェアを実行し、SAP HANAなどを展開するというアイデアは、知っている、私たちはしばしばそれを当たり前だと思っています。 しかし、それは非常にエキサイティングなことであり、複雑さも伴います。
ソフトウェア、特にメモリ管理とデータのパーティション化も改善されました。 詳細については詳しく説明しませんが、過去15年程度またはそれ以下の大きな変化を見ると、メモリの管理方法、特にRAMのデータとRAMのデータのパーティション分割の方法、ロビン・ブロア博士が以前に示唆したように、または暗示されているように、物事は待ち時間をとるのではなく、お互いに影響を与えることなく同時に読み書きできます。 オンチップでの圧縮や暗号化など、非常に強力な機能が多数あります。 暗号化はより重要なものになりつつあり、ソフトウェア、RAM、CPUスペースで必ずしも実際に行う必要はありません。今では実際にチップ上でネイティブに行われています。 それは物事を劇的にスピードアップします。 分散データの保存と処理、また、以前はスーパーコンピューターと並列処理のことを前提としていましたが、SAP HANAやHadoopとSparkなどの分野では当然のことと考えています。
そのため、このハイパフォーマンスコンピューティング、HPC機能が企業にもたらされ、現在、企業はパフォーマンスの向上とテクノロジースペース、技術的な利点と商業的な利益という利点を享受しています。価値実現までの時間の短縮は劇的に低下します。
しかし、レゴでPCケースを作った紳士の話を先ほど読んだこのイメージを使用します。これらのことを考えるといつも頭に浮かぶからです。 そして、それは、あなたがそれを構築し始めたとき、それは素晴らしいアイデアのように思えます、そして、あなたはそれを途中で通り抜けます、そして、あなたはすべてのレゴのビットをまとめて堅実なもの、十分に堅実にすることは実際に本当に難しいことであるとわかりますマザーボードなどを入れるために、それはパソコン用のケースを作ります。 そして最終的には、すべての小さなビットが正しくくっついていないことに気づき、どの小さなビットをくっつけてしっかりさせるかについて少し注意する必要があります。 それは非常にかわいいアイデアですが、中途半端になって、「うーん、たぶん300ドルのPCケースを買うべきだったかもしれませんが、今それを終えて、そこから何かを学びます。」
私にとって、それはこれらの非常に複雑なプラットフォームを構築するのがどのようなものであるかの非常に類似しています。なぜなら、それを構築し、ルーターとスイッチ、サーバーとラックを持っている環境になってしまうからです。 CPUとRAM、およびオペレーティングシステムがクラスター化されています。 そして、分散インメモリ処理およびデータストレージとデータ管理のために、HANAのようなものをその上に配置します。 その上にSAPスタックを構築し、データベース機能を取得してから、データとビジネスロジックを読み込み、読み取りと書き込み、クエリなどの適用を開始します。 I / Oを常に把握し、物事をスケジュールし、ワークロードとマルチテナンシーなどを管理する必要があります。 このスタックは非常に複雑になり、非常に迅速になります。 それが1台のマシン上にある場合、それ自体は複雑なスタックです。 それに16または32台のマシンを掛けると、非常に重要です。 100テラバイトからペタバイトの規模に移行するために、最大で数百台、最終的には数千台のマシンを増やす場合、それは恐ろしい概念であり、これらが現在対処している現実です。
そのため、この世界を変えるのに役立ったことがいくつかあります。それは、ディスクスペースが途方もなく安価になったことです。 昔は、1ギガバイトのハードディスクに38〜40万ドルを費やしていたのに、それが大きさの巨大なドラムだったので、フォークリフトで拾う必要がありました。 最近では、1ギガバイトあたり1〜2セントのコモディティディスクスペースになります。 RAMも同じことをしました。 ちなみに、これら両方のグラフのこれら2つのJ曲線はそれぞれ10年です。つまり、10年の2ブロック、20年の値下げを見ています。 しかし、最終的には右側の曲線が点線になり、詳細が見えないため、2つのJ曲線に分割しました。そのため、スケールを変更しました。 20年前のギガバイトのRAMは、600万ドルのオーダーでした。 最近では、奪われているコモディティハードウェアに1ギガバイトのRAMに対して3〜4ドル以上支払うと、
過去20年にわたる価格の大幅な低下は、メガバイトレベルだけでなく、テラバイトレベルでディスクスペースを超えてRAMに直接移行し、RAMをディスクのように扱うことができるようになったことを意味します。 ただし、それに対する課題は、RAMが本来短命であるということでした。つまり、短期間続くことを意味します。そのため、その空間に回復力を提供する方法を考え出す必要がありました。
したがって、ここでの私のポイントは、インメモリコンピューティングは気弱な人向けではないということです。 この非常に大規模なメモリ内データとその周辺の処理をジャグリングすることは興味深い挑戦です。 前に示したように、気弱な人向けではありません。 したがって、大規模で高密度のインメモリコンピューティングのこの経験から学んだことの1つは、構築する複雑さが多くの分野でリスクを生むことです。
しかし、監視と応答の観点から見てみましょう。 データについて考えると、データはディスクスペースから始まり、ディスク内のデータベースに置かれ、メモリにプッシュされます。 メモリに格納されて配布され、コピーがあれば、そのコピーを大量に使用できます。変更が行われた場合、次の場所でバックプレーンを行ったり来たりする代わりに、メモリレベルで反映できます。 2つの異なるレベルで、メモリに出入りします。 私たちは今、これを可能にするハイパースケールのハードウェアプラットフォームになりました。 ハイパースケーリングについて話すとき、途方もなく高密度のレベル、非常に高密度のメモリ、非常に高い密度のCPU、コア、スレッドでは困難です。 ノードとクラスター間を移動する場合、データはある時点でネットワーク上を移動する必要があるため、これをサポートするために非常に複雑なネットワーク病理学があります。
そのため、デバイス障害の冗長性が問題になり、デバイスとその一部を監視する必要があります。 そのプラットフォームに復元力のあるデータ障害の冗長性を組み込み、監視する必要があります。 分散データベースの復元力を組み込む必要があるため、データベースプラットフォームを監視し、その内部でスタックする必要があります。 分散処理のスケジューリング、いくつかのプロセスの内部で起こっていることをポーリングとクエリに至るまで監視し、クエリがたどるパスとクエリの構造化と実行の方法を監視する必要があります。 どのように見えますか、誰かが「blah」でSELECT *を実行したか、実際にバックプレーンのアーキテクチャを通過する名目で最小のデータ量を取得する非常にスマートでよく構造化されたクエリを実行しましたか？ マルチテナンシーワークロード、同じまたは複数のワークロード、バッチジョブ、およびリアルタイムスケジューリングを実行する複数のユーザーと複数のグループがあります。 そして、バッチ処理とリアルタイム処理のこのブレンドがあります。 定期的に実行されるものもあります（1時間ごと、1日ごと、1週間ごと、または1か月ごと）。その他はオンデマンドで実行されます。 誰かがリアルタイムレポートを実行したいタブレットと一緒に座っているかもしれません。
そして再び、私たちはその全体のポイントに来ます、これらで生じる複雑さは今の挑戦ではなく、それは非常に恐ろしいことです。 そして、1つのパフォーマンスの問題、それ自体が1つのパフォーマンスの問題であっても、エコシステム全体に影響を与える可能性があることをこの現実チェックで確認しています。 それで、私たちは、どこに影響があるのかを見つけるという非常に楽しい挑戦になりますか？ そして、私たちはこの課題を抱えています。私たちはリアクティブかプロアクティブか？ リアルタイムで物事を見ていて、何かが「バタン」と鳴り、それに反応するのを見ますか？ または、何らかの形のトレンドを見て、積極的にそれに参加する必要があることに気付きましたか？ 鍵は誰もが高速で安価で簡単なものを求めているからです。 しかし、これらのシナリオ、私が言及したいもの、ドナルド・ラムズフェルドの難問の私のお気に入りの行になります-私の心ではこれらの非常に複雑なシナリオのすべてに適用されます-そして、それは私たちが知っていることです設計および構築し、計画どおりに実行します。 誰が何を、いつ、どこで、オンデマンドで実行しているのかわからないという点で、既知の未知数があります。 そして、未知の未知数があり、それらは監視とチェックが必要なものです。 現実は、誰もが知っているように、測定できないものを管理することはできないからです。
したがって、CPUスケジューリングを監視する適切なツールと適切な機能を使用するには、待機時間を探し、パイプラインのスケジュールキューで待機する必要がある理由を見つけます。 メモリで何が起こっているのか、どのような使用率が実行されているのか、メモリからどのようなパフォーマンスが得られているのか？ ものは正しくパーティション化されていますか？それは分散されていますか？それのコピーを保持する十分なノードがあり、それに投入されているワークロードに対処できますか？ オペレーティングシステムプロセスから離れてプロセスを実行するとどうなりますか？ 実行中のジョブ自体、個々のアプリとそれらをサポートするデーモン？ それらのプロセス内で何が起こっているのか、特にクエリの構造化と、それらのクエリがどのように実行されコンパイルされているのか？ そして、それらのプロセスの健全性はずっとスタック内にありますか？ 繰り返しますが、待機時間に戻って、正しくスケジューリングされているか、待機する必要があるか、どこで待機しているのか、メモリ読み取り、I / O、CPU、エンドユーザーへのネットワーク経由のI / Oを待機している？
そして、そのポイントに戻って、私がラップアップする直前にすぐに言及しましたが、それは問題解決とそれらへの応答時間にどのように近づいていますか？ リアルタイムで監視し、物事に反応しますが、これは最も理想的なシナリオではありませんが、それでも、ヘルプデスクコールを知らないで、何か問題が発生したと言って、それを追跡する必要があるよりも、それを行う方が良い？ それとも私たちは積極的にそれをやっていますか？ つまり、言い換えると、メモリが不足していて、さらにノードを追加する必要がありますか？ トレンド分析を行っていますか、キャパシティプランニングを行っていますか？ そして、そのすべてにおいて、過去の実行時間を監視し、キャパシティプランニングについて考えていますか、それをリアルタイムで監視し、積極的にスケジュールを変更して負荷分散を行っていますか？ そして、そもそも実行されているワークロードを認識していますか？ クラスター内で誰が何をしているか、そしてその理由を知っていますか？
インメモリコンピューティングは非常に強力ですが、その能力を備えているため、装填された銃や弾薬で遊んでいるようなものの1つです。 気をつけないと最終的には自分で足を撃つことができます。 そのため、インメモリコンピューティングのパワーは、非常に分散した個別のデータセットでより多く、より迅速に実行できることを意味します。 しかし、その場合、エンドユーザーからの需要が高まります。 彼らはその力に慣れ、それを望んでいます。 彼らは、ジョブの実行に数週間かかることをもはや期待しておらず、レポートは普通の古紙で表示されます。 そして、そのすべての下に、パッチの適用、更新、アップグレードを取り巻く日常のメンテナンスがあります。 そして、インメモリコンピューティングによる24時間365日の処理、そのデータの管理、ワークロード全体のワークロードの管理について考えている場合、パッチとアップデートおよびアップグレードの適用を開始する場合、技術的には一時的なプラットフォームですべてインメモリになりますそこには、他のあらゆる管理および監視の課題もあります。 オフラインにできるもの、アップグレードできる時期、オンラインに戻す時期を知る必要があります。 そして、それが最後のポイントになります。つまり、これらのシステムがますます複雑になるにつれて、人間が親指を吸って耳を引っ張るだけでできることではありません。 ガットフィーリングのアプローチはもうありません。 計算およびデータ管理でこの高レベルのパフォーマンスを管理および提供するための適切なツールが本当に必要です。
そして、それを念頭に置いて、IDERAの友人に引き渡し、彼らがこの課題にどのように取り組んでいるかを聞きます。
ビル・エリス：ありがとうございます。 画面を共有しています。 ですから、2017年に利用可能になったこのようなものを利用可能にするために、すべてのテクノロジーと、私たちの前に来たすべての人々を考慮することは本当に謙虚です。 SAP HANAのワークロード分析について説明します。基本的には、データベース監視ソリューションであり、包括的で、エージェントレスで、リアルタイムで履歴を作成するため、過去に何が起こったかを確認できます。 SAP S / 4 HANAは、より良い、より速く、より安価な可能性を提供します。 私はそれが安価だと言っているのではなく、私はそれがより安価だと言っているだけです。 種類、伝統的に起こったのは、メインの実稼働インスタンス（おそらく、SQL Serverの可能性がある大規模なショップのOracleで実行されている）があり、そのETLプロセスを使用して、複数の種類の真実のバージョンがあったことです。 また、これらの個々の環境ごとにハードウェア、オペレーティングシステム、Oracleライセンスの支払いを行っていたため、これは非常に高価です。 それに加えて、あるバージョンの真実を次のバージョンの真実に一致させる人々が必要です。 そのため、この複数バージョンのETL処理は非常に遅く、非常に面倒でした。
そのため、基本的に1つのHANAインスタンスであるHANAは、他のすべてのインスタンスを潜在的に置き換えることができます。 そのため、複数ではなく1つのハードウェアプラットフォーム、1つのオペレーティングシステムであるため、安価です。 したがって、S / 4 HANAは実際にすべてを変更します。基本的に、さまざまな拡張パックであるR / 2からR / 3へのSAPの進化を検討しています。 現在、レガシシステムは2025年まで利用できるため、移行が実際に余儀なくされるまで8年間かかります。 私たちは人々を見るが、あなたが知っているので、彼らのつま先をこれに軽くたたきます。
したがって、1つのデータベース、ETLプロセス、調整する必要のあるコピーはありません。 だから、もう一度、より速く、より良く、より安く。 HANAはインメモリです。 SAPはソフトウェアを提供し、ユーザーはハードウェアを提供します。 集計テーブルはありません。 このことについて考えているときに彼らが示唆していることの1つは、これに参加したくないということです。利用可能な最大のサーバーを購入するだけです。 彼らは、SAPランドスケープを前もって適切なサイズにすることを提案し、基本的には20年分のデータを移行しないことを提案しています。 アーカイブは、SAPショップだけでなく、全般的にITで十分に活用されていないものだと思います。 そして、次は、SAPが実際にSELECT *を使用しないようにネイティブコードを書き換えるのに多くの時間を費やしたということです。 SELECT *は、テーブルからすべての列を返しますが、列データベースでは特に高価です。 したがって、SAP HANAにとっては良い考えではありません。 そのため、多くのカスタマイズ、多くのレポートがあるショップでは、これは探したいものであり、すべてをHANAに移行する際に列名を指定したいと思うでしょう。
私たちはHANAは万能薬ではないと言いたいです。 すべてのデータベース、すべてのテクノロジーと同様に、それを監視する必要があり、前述のように、測定ごとに過剰を管理するには数値が必要です。 IDERA領域で私が話していることの1つは、すべてのビジネストランザクションが記録システムと対話することです。この場合、HANAになります。 そのため、HANAはSAPトランザクションのパフォーマンス、エンドユーザーエクスペリエンスの基盤となります。 そのため、最高速度で実行し続けることが重要です。 それは単一障害点になります。そして、人々と話すと、これはあなたがエンドユーザーを持っているところに現れる可能性があり、おそらくそのリアルタイムデータを使用しており、潜在的に完全ではないアドホッククエリを持っています正しい。 テーブルを結合しておらず、外部結合、パルチザン製品を作成しており、基本的に多くのリソースを消費している可能性があります。 現在、HANAは最終的にそれを認識し、そのセッションを終了します。 したがって、私たちのアーキテクチャには重要な部分があり、これを実際に履歴に取り込むことができるため、過去に何が起こったかを確認し、それらの状況を認識することができます。
それでは、SAP HANAのワークロード分析を見てみましょう。 これはバージョン1であるため、この旅にご参加ください。IDERAの製品です。 包括的でありながらシンプルです。 トレンド付きのリアルタイム。 ホストの状態、インスタンスの状態。 待機状態、SQLクエリ、メモリコンシューマ、およびサービスを追跡します。 したがって、これはGUIの外観であり、Webが有効になっていることがすぐにわかります。 実際に、このソリューションをシステム上でライブで実行しました。 確認したい重要なことがいくつかあります。 私たちは、さまざまなワークスペースに細分化しました。 最も重要なのは、CPU使用率とメモリ使用率からホストレベルで何が起こっているかです。 スワッピングやスラッシングの観点に立ちたくはありません。 そして、基本的には、応答時間、ユーザー、SQLステートメント、つまりシステム上のアクティビティを駆動しているものから、トレンドで何が起こっているのかを把握します。
IDERAには、アクティビティが発生するまでデータベースで何も起こらないということがあります。 そしてそのアクティビティは、アプリケーションからのSQLステートメントです。 そのため、根本原因を検出できるようにするには、SQLステートメントの測定が不可欠です。 それでは、先に進んでドリルインしましょう。ホストレベルでは、実際にメモリを調べ、時間の経過を追跡し、ホストのCPU使用率を調べることができます。 一歩下がれば、COBSQLステートメントを見ることができます。 今、あなたが私たちのアーキテクチャ側で見るものの1つは、この情報がHANAから保存されていることです。したがって、HANAに何かが起こった場合、基本的に、神が禁止されている、利用できない状況までの情報をキャプチャしています。 また、システムで発生するすべてをキャプチャして、明確な可視性を確保できます。 そして、私たちがやろうとしていることの1つは、SQL文を重み付き順序で提示することです。 したがって、それは実行回数を考慮に入れるため、これは集約されたリソース消費です。
それで、ここで個々のメトリックを取得できます-そのSQLステートメントはいつ実行されましたか？ そして、リソース消費は実行計画によって大きく左右されるため、継続的にそれを把握することができます。 HANAはインメモリです。 それは非常に平行です。 すべてのテーブルにプライマリインデックスがあり、一部のショップでは、特定のパフォーマンスの問題に対処するためにセカンダリインデックスを作成することを選択しています。 そのため、特定のSQLステートメントの実行計画で何が起こったのかを知ることは非常に価値があります。 また、時間の経過とともにグラフ化されたサービス、メモリ消費量についても見ていきます。 アーキテクチャ：したがって、これは自己完結型のソリューションであり、当社のWebサイトからダウンロードできます。アーキテクチャは、Web対応であるということです。
特定のインスタンスに複数のユーザーを接続させることができます。 SAP HANAのローカルインスタンスを監視できます。 また、リポジトリには4週間のローリング履歴があり、それは自己管理されています。 これを展開するには、かなり簡単です。 Windowsサーバーが必要です。 ダウンロードする必要があります。 ほとんどのWindowsサーバーには、.NETフレームワークが組み込まれており、ライセンスがバンドルされています。 したがって、Setup.exeによって起動されるインストールウィザードに移動し、実際に画面、ライセンス契約を開き、[次へ]をクリックしてこのアウトラインを単純に下に移動します。インストールされますか？ 次はデータベースプロパティであり、これはSAP HANAへの接続になるため、これはHANAインスタンスのエージェントレス監視です。 そして、基本的にプレビューを行います。これはデフォルトで通信するポートです。 「インストール」をクリックすると、基本的にHANAが起動し、履歴の構築を開始します。 そのため、サイジングチャート情報のほんの一部です。 最大45個のHANAインスタンスを監視できますが、これをスライドスケールで使用して、必要なコア数、メモリ、ディスクスペースを決定できます。 そして、これはあなたが完全な4週間のローリング履歴が入っていることを前提としています。
したがって、簡単に要約すると、サーバーの正常性、インスタンスの正常性、CPU /メモリ使用率を調べています。 メモリ消費者は何ですか、アクティビティドライバーは何ですか、サービスは何ですか？ SQLステートメントは非常に重要です–実行状態は何ですか？ 実行計画を見せて、いつ実行されたのか、トレンドを提供しますか？ これにより、リアルタイムで何が起きたかの履歴が得られます。 そして、私が言ったように、私たちの歴史はHANAとは別なので、タイムアウトしてHANAの歴史からフラッシュされたものをキャプチャします。 そのため、別の履歴があるため、システム上の真のリソース消費を確認できます。
それで、私が言及したように、IDERAのウェブサイトの製品の下で、あなたはこれを簡単に見つけることができます。 これを試してみたいのであれば、ぜひ大歓迎です。 それがどのようにあなたに情報を提供するかを見て、そのウェブサイトに追加情報があります。 したがって、興味のある関係者は喜んでそれに参加します。 現在、IDERAが提供するポートフォリオ製品には、SAP ECCトランザクションモニターもあり、これはPrecise for SAPと呼ばれています。 ポータルを使用している場合でも、ストレートECCを使用している場合でも、実際にはクリックからディスクまでのエンドユーザートランザクションをキャプチャし、SQLステートメントに至るまで何が起こっているかを表示します。
これで、1つの要約画面のみを表示します。 この要約画面からいくつかのことをお伝えします。 これは、Y軸の応答時間、X軸の時間に1日を加えたものです。このトランザクションビューでは、クライアント時間、キュー時間、ABAPコード時間、データベース時間を表示します。 エンドユーザーID、Tコードをキャプチャし、特定のトランザクションを経由してサーバーを実際にフィルタリングおよび表示できます。 そのため、多くのショップがVMwareのランドスケープのフロントエンドを運営しているため、各サーバーで何が起こっているかを実際に測定し、非常に詳細な分析を行うことができます。 したがって、このトランザクションビューは、SAPランドスケープ全体にわたるエンドユーザートランザクション用です。 そして、あなたは私たちのウェブサイトのProducts APM Toolsの下でそれを見つけることができます、そして、これは我々が持っているSAPソリューションです。 このインストールはもう少し複雑なので、HANAのようにダウンロードして試してみるだけではありません。 これは、トランザクション全体を実行、設計、実装するために私たちが協力するものです。
したがって、SAP HANAのワークロード分析は、3番目の簡単な要約であり、包括的で、エージェントレスで、リアルタイムであり、歴史を提供します。 私たちはあなたのサイトでそれをダウンロードして試す機能を提供します。
だから、それで、私はエリック、デズ、ドクター・ブロアに時間を戻すつもりです。
エリック・カバナ：ええ、多分ロビン、あなたからの質問、そしてロビンの後のデズ？
ロビン・ブロア博士：わかりました。 つまり、最初に言いたいのは、トランザクションビューが本当に好きだということです。なぜなら、それはまさにそのような状況で望むものだからです。 私は多くの仕事をしました-まあ、それはかなり前のことです-パフォーマンスの監視をしていますが、それは一種のことでした。 当時はグラフィックスがありませんでしたが、それは私が特にやりたいと思っていた種類のものでした。 何らかの方法で、問題が発生している場所に自分自身を注入することができます。
最初の質問は、ほとんどの人が何らかの形でS / 4を実装していることです。 S / 4の特定の実装に関与したとき、S / 4が適切に実装されていることを発見しましたか、それとも顧客が再構成したくなる可能性のあるものを発見しましたか？ つまり、そのすべてはどのように行われますか？
ビル・エリス：まあ、どの店も少し違う。 また、さまざまな使用パターン、さまざまなレポートがあります。 アドホックレポートを持つサイトの場合、実際には、システム上のワイルドカードのようなものです。 そのため、重要なことの1つは、測定を開始し、ベースラインが何であるか、特定のサイトの正常な状態、特定のサイトがどこにあるかを、使用パターンに基づいて見つけ、システムにストレスをかけることです。 そして、そこから調整を行います。 通常、監視の最適化は一度限りではなく、エンドユーザーコミュニティがビジネスをより効果的に提供できるようにシステムを改善し、監視、調整、ホーニングする実際の継続的なプラクティスです。
ロビン・ブロア博士：わかりました。実装するとき、つまり、実装のサイズによって異なるため、これは答えるのが難しい質問であることがわかります。 ？ それは何かに違いをもたらしますか、それとも干渉しませんか？ それはどのように機能しますか？
ビル・エリス：ええ、オーバーヘッドは約1〜3パーセントだと思います。 多くのショップは、それを犠牲にすることをいとわないでしょう。なぜなら、潜在的に、最適化の観点からそれを買い戻すことができるからです。 使用パターンに依存します。 完全なランドスケープを行っている場合、監視対象の個々のテクノロジーに依存します。 そのため、走行距離はさまざまですが、先ほど説明したように、盲目的に走るよりも、何が起こっているのかを知るために少し時間を費やす方が間違いなく良いです。 特に、ここでは1月であり、年末の処理に入り、12か月分のデータを集計しています。 パフォーマンスを実行していること、規制機関、銀行、株主にレポートを提供することは、重要なビジネスパフォーマンスにとって絶対に不可欠です。
ロビン・ブロア博士：そうです。 そして、あなたの視点から-一連のSAPサイト全体に関与していると思いますが、S / 4に向かうSAP顧客ベースの動きはどれくらい大きいのでしょうか。 つまり、熱狂的な顧客の雪崩が起こっているということですか、それとも安定したトリクルですか？ どう見えますか？
ビル・エリス：数年前は、つま先だったと思います。 今、私は人々が膝までやっていると言っています。 タイムラインを考えると、今後数年間で人々がHANAに夢中になると思います。 それで、監視、変換、あなたの知っているように、顧客の大部分は一緒に、学習曲線上にあると思います。 それで、私たちはあなたが述べたように雪崩に完全には陥っていないと思いますが、HANAへの大きな変革の頂点にいると思います。
ロビン・ブロア博士：わかりました。それで、あなたがこれまで行ったサイトに関して、彼らは他のアプリケーションにもHANAを適応させているのでしょうか、それとも何らかの形でこれを作るのに完全に消費されていますか？仕事は？ そこの写真は何ですか？
ビル・エリス：ええ、多くの場合、どのモジュールなどに応じて、人々はSAPを他のシステムと統合します。そのため、少しあります。 HANAで他のアプリケーションを展開している人は、まだあまり見かけません。 それは確かに可能です。 そのため、SAPインフラストラクチャを取り巻く環境はより重要です。
ロビン・ブロア博士：あなたをデズに引き渡したいと思います。 私はあなたの時間を独り占めしてきました。 デズ？
Dez Blanchfield：ありがとう。 いいえ、それですべてです。 テーマを設定しようとするだけの、非常に簡単な2つの方法。 SAP HANAは数年前からリリースされており、人々はそれを検討する機会がありました。 あなたが私たちにそれを実行している人々の割合の大まかな見積もりを与えた場合-このようなものを実行している多くの人々がいるので-あなたが気づいている市場の割合が現在なくなっていると思いますか従来のSAPの実装からHANA上のSAPまで？ 50 / 50、30 / 70を見ていますか？ 市場のどの程度の割合で、今移行し、動きを始めた人々と、物事の改善、改善、変化、または状況が何であれ、ただ控えめに待っている人々とを見ていますか？
ビル・エリス：ええ、実際には、私の観点から、パーセンテージを約20パーセントにしたと思います。 SAPは従来のビジネスである傾向があります。 人々は非常に保守的である傾向があるため、人々は足を引きずります。 また、SAPを長い間使用しているのか、それとも最近導入したSAPのようなSMBなのかにも依存していると思います。 そのため、いくつかの要因がありますが、全体的には割合が50/50であるとは思いません。 50％は少なくとも手を出しており、HANAをデータセンターのどこかで実行しています。
Dez Blanchfield：先ほどお伝えした興味深いことは、これはある意味で既成事実であり、時計は移行する時間を物理的および文字通り刻々と刻んでいるということです。 そうする過程で、人々はそれを考えたと思いますか？ これはプラットフォームの過渡的な変化であり、単なるオプションではなく、デフォルトになっているという一般的な理解は何ですか？
そして、SAPの観点からは、パフォーマンスに大きな競争上の優位性があるため、彼らはその方法を推進していると確信していますが、それはまた、彼らがサードパーティに行くのではなく、プラットフォームのコントロールを奪い取っていることですパーティデータベース、彼らは今彼ら自身のプラットフォームにそれを戻しています。 企業は実際にそのメッセージを受け取っていると思いますか？ 人々はそれを理解しており、今ではそれに取り組んでいると思いますか？ それとも、それはまだ、ある種、不明瞭なものですか、市場から出ていると思いますか？
ビル・エリス： SAPはコミュニケーションについて恥ずかしがらず、SAPPHIREに行った人はどこでもHANAを見てきました。 だから、私は人々はよく知っていると思いますが、人間の性質はそれが何であるか、あなたの知っているように、ある種の人々は足を少し引っ張っています。
Dez Blanchfield：私がその質問をしている理由を考えているので、あなたは私を許さなければならないでしょうが、それは私が同意することです。 彼らはそれを伝えることに恥ずかしがっていなかったと思います。 信号は多くの点で消えたと思います。 そして、私はあなたに同意します–私は誰もがまだジャンプしたことを知りません。 ご存知のように、従来の企業、これを実行している非常に大規模な企業は、いまだに多くの点で、足を引っ張るのではなく、シフトの複雑さに取り組もうとしています。 あなたのツール、そして確かに今日のデモンストレーションが強調したことの1つは、私にとって重要なことの1つだと思います。今日、皆さんが聞いて調整し、座って反射的に注意を払うことを望んでいます。今では、このプロセスが単純化されたツールです。 非常に緊張したCIOとその下のチームが、「何十年も前から知られている従来のRDBMS、リレーショナルデータベース管理システムから、まったく新しいコンピューティングのパラダイムに移行するにはどうすればよいか」と考えています。まだ比較的勇敢なスペースでのストレージ管理？」 しかし、それは多くの点で未知であり、他の分野でそのシフトを行った人はほとんどいません。すでにインメモリコンピューティングに移行しているビジネスの別のセクションを持っているようではありません。 だから、それは彼らの心の中のオールオアナッシングの動きです。
ですから、私がこれから何よりも取り除いたものの1つ-すぐに質問であなたを攻撃するつもりです-恐れが今、多くの方法で軽減されていると思います。もし私がCIOのリスニングだったら、「そうですね、どうやってこの移行をするのですか？ リレーショナルデータベース管理プラットフォームとDBAの長年の経験で得たのと同じ機能を、現在スキルを持っていない新しいプラットフォームにどのように保証するのでしょうか？」 、あなたはツールがあなたが提供しているものと共に今そこにあり、彼らは一種の、深呼吸をして、移行が以前だったかもしれないほど怖くないという安reliefのため息をつくことができると人々は理解したと思いますかこのツールが利用可能になりましたか？ 人々は、NVMe、フラッシュ、ディスクの旧式の組み合わせに対するインメモリコンピューティングとインメモリストレージへの移行に取り組んでいるということを、今でも理解しているのでしょうか？
ビル・エリス：ええ、間違いなくこれをグラフィカルに表示し、何が起きているのか、そしてトップのリソース消費者を簡単に特定できるようにする多くのテクノロジーとツールがあります。 つまり、それは物事を簡素化するのに役立ち、テクノロジースタッフが本当に良いハンドルを握るのに役立ちます。 ねえ、彼らは何が起こっているのかを知ることができ、すべての複雑さを理解できるようになるでしょう。 したがって、絶対に、市場のツールは間違いなく有用であるため、SAP HANAのワークロード分析を提供します。
Dez Blanchfield：ええ、今日お見せしたことのすごいところは、ハードウェアの一部、オペレーティングシステムの一部を監視すること、そしてあなたが言ったように、移動するワークロードの一部を監視することです。しばらくそこにいた。 私にとって、特にHANAのような人にとっては、虫眼鏡を覗いて覗き込んで、クエリで何が起こっているのか、どのようになっているかをすぐに見ることができなかったということです構造化され、その負荷がどこにあるか。
これまでに見てきた展開では、あなたが文字通り世界のプラットフォームでこの分野で最も権威があることを考えると、あなたが見たいくつかの素早い勝利-あなたが共有できる逸話的な知識がありますかユーレカの瞬間、アハの瞬間、人々がIDERAツールセットを展開したとき、彼らは彼らが持っていたプラットフォームとパフォーマンスに気付いていなかったものを見つけました。 人々がそれを展開した場所の素晴らしい逸話的な例がありますが、実際に彼らが持っていたものを知らず、突然消えてしまいました。「わあ、実際にそこにあることを知りませんでしたか？」
Bill Ellis：ええ、ネイティブツールの大きな制限は、暴走したクエリがキャンセルされると、情報がフラッシュされるため、基本的に履歴がないことです。 暴走クエリのように履歴をオフラインで保存すると、履歴があり、何が起こったのかがわかり、実行計画などを見ることができます。 そのため、エンドユーザーコミュニティの基本的な操作の改善、レポートの作成などを支援できます。 そして、歴史は本当に素晴らしいものです。 そして、私が見せたかったことの1つは、最大4週間のリアルタイムを見ることができ、関心のある任意の時間枠に簡単にズームインでき、基礎となる運転活動を公開できることです。 その可視性を持つだけで、ボトルネックが発生したことを知るのに非常に役立ちます。
Dez Blanchfield：展開された後はマルチユーザーだとおっしゃいましたが、多くの点でエージェントレスで効果的にゼロタッチであるという事実に非常に感銘を受けました。 ツールを1回展開するだけで、クラスターを支えるコアインフラストラクチャをアプリケーションと開発チームまで監視するNOCのネットワークオペレーションセンターの全員が利用できるようになるのは普通ですか？ それは当たり前であり、一度展開すれば彼らはそれを共有するでしょうか、それとも人々はスタックのさまざまな部分を見るモデルインスタンスを持つかもしれないと予想していますか？ それはどのように見えますか？
ビル・エリス：それで、基本チームは通常、SAPで起こっていることの技術基盤に非常に強い関心を持っています。 明らかに、ランドスケープ全体をサポートする複数のチームがあります。 HANAの部分はそのことに焦点を合わせています。 私は、情報の主要な消費者としてデフォルトでSAPベーシスチームにデフォルトを設定します。
Dez Blanchfield：そうです 。 ただし、コードレベルだけでなく、開発チームがいる場合、特にそこにあるデータセットの分析作業を行うデータサイエンティストまたはアナリストのチームがある場合、現在、私の考えでは、組織内のすべてに適用されるデータサイエンスへの大きな推進-そして、間違っている場合は修正します-これは、彼らにとっても非常に興味深いものになると思われます。データウェアハウス環境でできる重大なことの1つは、データサイエンティストを解き放ち、アドホッククエリの実行を開始できるようにすることです。 ショップがあなたを怒らせているような状況の例はありますか？「データサイエンスチームを投入しました。本当に痛いです。彼らのために何ができるのか、私たちはただ何をしているのか」従来の運用上の監視と管理？」
ビル・エリス：ええ、そうですね、これを少し変えて、パフォーマンスを見て、QAプロダクションを開発する際にパフォーマンスを意識することで、ストアを早くすればするほど、問題は減ります。あなたが持っている驚き。 だから、絶対に。
Dez Blanchfield：それに続いて、私が経験した多くのツール、そしてロビンも同意するでしょう–ここにある多くのツール、あなたが本当に必要な大きなRDBMSを持っているなら、熟練した、深い知識があり、経験豊富なDBA。 SAP HANAで発生するインフラストラクチャとプラットフォームの要件の一部は、特定のハードウェアなどから、私が知る限りでは整合している特定のディストリビューションで現在サポートされているためです。 ご存知のように、同じではない数十年の経験を持つ人々がいます。 しかし、私が見ているのは、それが必ずしもこのツールの要件ではないということです。 あなたのツールを展開して、かなり新しい顔にそれを与え、すぐにパフォーマンスが良くないものを見つける力を与えることができるように思えます。 これに習熟し、それを展開することで価値を得るための非常に短い学習曲線があるということですか？ ご存知のように、私の一般的な感覚では、価値をすぐに確認するためにツールを操作した20年の経験は必要ありません。 そうだと思いますか？
ビル・エリス：絶対に、そしてあなたの言うところまで、展開の成功の大部分は、SAP HANA環境の計画と設計に本当にかかっていると思います。 そして、間違いなく多くの複雑さ、それに基づいた多くの技術がありますが、それは結局のところ、起こっていることの使用パターンを監視することになります。 そのため、より複雑ですが、ある意味ではパッケージ化されており、いくらか単純化されています。 それは非常に悪いです。
Dez Blanchfield：ええ、だから私がエリックに話を戻す前に、彼がいくつかの質問を持っていることを知っています。特に、Q&Aで出てきた質問から興味深い質問があります。その答えを聞きたいです。 誰かのための伝統的な旅-あなたはそれを手に入れることができると先に述べました、あなたはそれをダウンロードしてそれを試すことができます。 今日聞いている人や後で再生するかもしれない人のために、すぐにそれを要約できますか？ コピーを手に入れて展開し、購入する前に環境で試すための簡単な2つまたは3つのステップは何ですか？ それはどのように見えますか？ そのための手順は何ですか？
ビル・エリス：ええ。 したがって、IDERA.comからProductsに移動すると、SAP HANAのワークロード分析が表示されます。 ダウンロードページがあります。 連絡先を尋ねられると思いますが、製品はライセンスキーでパッケージ化されているので、Setup.exeでインストールしてすぐにローリングできます。
Dez Blanchfield：だから、彼らはあなたのウェブサイトに行き、ダウンロードすることができます。 しばらく前にそれを見たのを覚えていますし、昨夜も確認しました。メモリからデモをリクエストできます。あなたのチームの誰かが、それを通してあなたを案内してくれますか？ しかし、実際に無料でダウンロードして、自分の環境に、自分の時間にローカルに展開することはできますか？
ビル・エリス：はい。
Dez Blanchfield：すばらしい。 まあ、何よりも、それはおそらく私が個人的に行うことを人々にアドバイスすることだと思います、ウェブサイトからコピーを取得し、そこにドキュメントの一部を取得することは、それを行うための良いコンテンツがたくさんあることを知っているので、試してみてください。 それを環境に入れて、見つけたものを見てください。 IDERAツールを使用してSAP HANA環境の内部を確認すると、実際にはそこにあることに気付いていなかったものが見つかると思います。
見て、本当にありがとう。ロビンと私とのQ&Aだけに感謝します。エリック、参加者からもQ&Aが出てくることを知っているので、私はあなたに戻ってきます。
エリック・カバナ：ええ、ここにあるのは本当に簡単なことです。 ですから、出席者の一人が、物事がどのように変化しているかについて話しているだけで、とても良いコメントをしています。 過去に言って、メモリは窒息し、頻繁なページングによって速度が低下していましたが、現在のCPUはメモリ内のデータが多すぎて窒息しています。 ネットワークの問題があります。 常に動いているターゲットになるでしょう？ ボトルネックがどこにあり、どこに注意を集中する必要があるかという点で、最近の軌跡をどう思いますか？
ビル・エリス：ええ。 あなたが測定するまで、知るのは難しいです。 SQLステートメントに関することの1つは、それらがリソース消費のドライバーになることです。 したがって、大量のメモリ消費やCPU消費が発生する状況では、どのアクティビティがそのリソース消費を引き起こしたかを把握できます。 今、あなたは必ずしもそれを殺したいとは思わないでしょうが、あなたはそれと、また、何が起こっているのか、それがどのくらいの頻度で起こるのかなどを認識したいのです。 私たちは、さまざまな状況への対応のセット全体またはクックブックに対処するという点で、まだ新しいものです。 そして、それは素晴らしい質問であり、時間が経てばわかるでしょう。 時間が経つにつれて、より多くの情報が得られます。
エリック・カバナ：それだけです。 さて、皆さんは非常に興味深いスペースにいます。 コンテンツコールで提案されたように、SAPが移行を行うための素晴らしい長いオンランプを提供したことを知っているので、今後数か月および今後数年で多くのアクティビティが見られると思いますHANAへ。 しかし、それでも、そのランプには終わりがあり、ある時点で人々はいくつかの深刻な決定を下さなければならないので、早ければ早いほど良いでしょう？
ビル・エリス：もちろんです。
エリック・カバナ：申し分なく、私たちはここHot Technologiesでもう1時間燃えました。 オンラインで情報を見つけることができます、insideanalysis.com、techopedia.com。 これらの過去のウェブキャストのすべてのアーカイブのリストを含む、多くの興味深い情報については、そのサイトに注目してください。 しかし、皆さん、そこにいるすべての人、IDERAの友人、ロビン、そしてもちろんDezに感謝します。 そして来週、皆さんに追いつきます。 ご清聴ありがとうございました。 気を付けて。 バイバイ。
