取り除く： ホストのエリック・カバナは、インメモリ・コンピューティングとSAP HANAについて、ゲストのロビン・ブロア博士、デズ・ブランフィールド、IDERAビル・エリスと議論します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ： さて、ご列席の皆様。こんにちは、おかえりなさい。それは水曜日の東部時間の4時であり、ここ数年は、Hot Technologiesにとってもまた同じ時です。はい、確かに、私の名前はエリック・カバナです。今日の会話のホストになります。
皆さん、今日はクールなものについてお話します。私たちはインメモリの世界に飛び込みます。正確なタイトルは「Into the Future：An-Ramp for On-Memory Computing」です。最近では、それは大流行しています。メモリは、回転するディスクに依存するよりもはるかに高速です。ただし、課題は、多くのソフトウェアを書き直す必要があることです。なぜなら、今日のソフトウェアのほとんどは、ディスクを念頭に置いて書かれており、それがアプリケーションのアーキテクチャを実際に変えるからです。回転するディスクを待つようにアプリケーションを設計する場合、インメモリテクノロジのすべての能力を備えている場合とは異なる方法で作業を行うだけです。
@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はほとんど常にビジネスが実行している基本的なアプリケーションであり、単なる大きなゲームチェンジャーであり、非常に興味深いものです。しかし、もちろん、それはすべて非常に良い音ですが、インテリジェントに構成する必要があり、よく監視する必要があります。見た目ほど簡単ではありません。
そうは言っても、ボールを渡すと思います。この男は誰ですか？ああ、オーストラリア人のデズ・ブランフィールド。
デズ・ブランフィールド： 非常に面白い。常に厳しい行動をとる、ロビン・ブロア博士。本日はありがとうございます。だから、大きなトピックですが、エキサイティングなものです。そのため、現代のデータレイクとエンタープライズデータウェアハウス、そして私の小さなデータの宝物について考えているときに、よく思い浮かべるイメージを選びました。山と波に囲まれた美しい湖がここにあり、波が岩の上に打ち寄せています。これは、最近、大規模なデータレイク内でどのように見えるかを精神的に視覚化する方法です。波はバッチジョブであり、リアルタイム分析はデータに投げかけられます。それを物理的な湖と考えると、私たちに目覚めの呼びかけが返ってきます。今、私たちが構築しているデータウェアハウスの規模、このコインを思いついた理由、データレイクとは、それらが非常に大きく、非常に深く、時には嵐が発生する可能性があるということです。そして、私たちがやるとき、あなたはいつも嵐の原因を解決しなければなりません。
ですから、このことをテーマにすると、このインメモリコンピューティングのサイレンコールは、非常に強力であり、十分な理由があるように思えます。それは非常に多くの重要な商業的および技術的利益をもたらします。それは別の日に数時間の議論です。しかし、インメモリコンピューティングへの一般的な移行では、まず、ここで得られた方法とこれを可能にするものについて説明します。これは、いくつかの課題が最初に存在する場所と、認知する必要があるものの基盤を設定するからですデータを保持している従来の古い回転ディスクから離れ、ディスクのオンとオフ、およびメモリとメモリから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テラバイトからペタバイトの規模に移行するために、最大で数百台、最終的には数千台のマシンを使用する場合、これは恐ろしい概念であり、これらが現在対処している現実です。
そのため、この世界を変えるのに役立ったことがいくつかあります。それは、ディスクスペースが途方もなく安価になったことです。昔、ギガバイトのハードディスクに38〜40万ドルを費やしていたのは、それが大きさの巨大なドラムでした。それを拾うにはフォークリフトが必要でした。最近では、ギガバイトあたり1〜2セントのコモディティディスクスペースになります。 RAMも同じことをしました。ちなみに、これら両方のグラフのこれら2つのJカーブはそれぞれ10年です。つまり、10年、20年の値下げの2つのブロックを見ています。しかし、それらを2つのJカーブに分割しました。最終的には右側の1つが点線になり、詳細が見えないため、スケールを変更しました。 20年前のギガバイトのRAMは、600万ドルのオーダーでした。最近では、盗難されているコモディティハードウェアに1ギガバイトのRAMに対して3〜4ドル以上支払うと、
過去20年間の大幅な価格の下落は、メガバイトレベルだけでなく、テラバイトレベルでディスクスペースを超えてRAMに直接移行し、RAMをディスクのように扱うことができることを意味します。ただし、それが難しかったのは、RAMが本来短命だということです。つまり、それは短期間しか持続しないことを意味します。そのため、その空間に回復力を提供する方法を考え出す必要がありました。
したがって、ここでの私のポイントは、インメモリコンピューティングは気弱な人向けではないということです。この非常に大規模なメモリ内データとその周辺の処理をジャグリングすることは興味深い挑戦です。先に示したように、それは気弱な人向けではありません。そのため、大規模かつ高密度のインメモリコンピューティングに関するこの経験から学んだことの1つは、構築する複雑さが多くの分野でリスクを生むことです。
しかし、監視と応答の観点から見てみましょう。データについて考えると、データはディスクスペースから始まり、ディスク内のデータベースに置かれ、メモリにプッシュされます。メモリに格納されて配布され、コピーがあれば、そのコピーを大量に使用できます。変更が行われた場合、次の場所でバックプレーンを行ったり来たりする代わりに、メモリレベルで反映できます。 2つの異なるレベルで、メモリに出入りします。私たちは今、これを可能にするハイパースケールのハードウェアプラットフォームになりました。ハイパースケーリングについて話すと、途方もなく高密度のレベル、非常に高密度のメモリ、非常に高い密度のCPU、コア、スレッドでは困難です。これをサポートするために非常に複雑なネットワーク病理学を取得しました。ノードとクラスター間を移動する場合、データはある時点でネットワーク上を移動する必要があるためです。
そのため、デバイスの障害の冗長性が問題となり、デバイスとその一部を監視する必要があります。そのプラットフォームに復元力のあるデータ障害の冗長性を組み込み、監視する必要があります。分散データベースの復元力が組み込まれている必要があるため、データベースプラットフォームを監視し、その内部でスタックする必要があります。分散処理のスケジューリング、いくつかのプロセスの内部で起こっていることをポーリングとクエリまで監視し、クエリがたどるパスとクエリの構造化と実行の方法を監視する必要があります。どのように見えますか、誰かが「ブラー」で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年間かかります。私たちは人々が、これが来ることを知っているので、つま先を軽くたたくように見えますが、最終的に、ECCはHANAで実行されるので、あなたは本当にそのために準備し、技術を理解する必要があります
したがって、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を使用することの1つは、アクティビティがあるまでデータベース上で何も起こらないということです。そしてそのアクティビティは、アプリケーションからの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のWebサイトの[製品]で説明したように、これは簡単に見つけることができます。これを試してみたい場合は、ぜひ大歓迎です。それがどのようにあなたに情報を提供するかを見て、そのウェブサイトに追加情報があります。したがって、興味のある関係者は喜んでそれに参加します。現在、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の特定の実装に関与するとき、それが適切に実装されていることを発見しましたか、それとも、顧客が再構成することを望む可能性のあるものを発見しましたか？つまり、そのすべてがどのように行われますか？
ビル・エリス： まあ、すべてのショップは少し異なります。また、さまざまな使用パターン、さまざまなレポートがあります。アドホックレポートのあるサイトの場合、実際には、システム上のワイルドカードのようなものです。そのため、重要なことの1つは、測定を開始し、ベースラインが何であるか、特定のサイトの正常な状態、特定のサイトがどこにあるかを、使用パターンに基づいて見つけ、システムにストレスをかけることです。そして、そこから調整を行います。通常、監視の最適化は1回限りではなく、エンドユーザーコミュニティがビジネスをより効果的に提供できるようにシステムを改善し、監視、調整、ホーニングする実際の継続的なプラクティスです。
ロビン・ブロア博士： さて、実装するとき-実装のサイズによって異なるため、答えるのは難しい質問ですが、IDERA監視機能はどのくらいのリソースを消費しますか？それは何かに違いをもたらしますか、それとも干渉しませんか？それはどのように機能しますか？
ビル・エリス： オーバーヘッドは約1〜3パーセントだと思います。多くのショップは、最適化の観点からそれを買い戻す可能性があるため、それを犠牲にすることを非常に喜んでいます。使用パターンに依存します。完全なランドスケープを行っている場合、監視対象の個々のテクノロジーに依存します。そのため、走行距離はさまざまですが、先ほどお話ししたように、盲目で走るよりも、何が起こっているのかを知るために少し時間を費やす方が間違いなく良いです。特に、ここでは1月になり、年末の処理に入り、12か月分のデータを集計することになります。パフォーマンスを実行し、規制機関、銀行、株主にレポートを提供することは、重要なビジネスパフォーマンスにとって絶対に不可欠です。
ロビン・ブロア博士： 右。そして、あなたの視点から-一連のSAPサイト全体に関与していると思いますが、SAP顧客ベース間のS / 4への動きはどれほど大きいのでしょうか。つまり、熱狂的な顧客の雪崩が起こっているということですか、それとも安定したトリクルですか？どう見えますか？
ビル・エリス： 数年前、つま先だったと思います。今、私は人々が膝までやっていると言っています。タイムラインを考えると、今後数年間で人々がHANAに夢中になると思います。それで、監視、変換、あなたの知っているように、顧客の大部分は一緒に、学習曲線上にあると思います。それで、あなたが言ったように、私たちは雪崩に陥っているとは思いませんが、HANAへの大きな変革の頂点にいると思います。
ロビン・ブロア博士： さて、あなたがこれまで行ったサイトに関して、彼らはまた、HANAを他のアプリケーションに適応させているのでしょうか、それとも何らかの形で、このようなものを機能させるために完全に消費していますか？そこの写真は何ですか？
ビル・エリス： ええ、多くの場合、人々はSAPを他のシステムと統合しますが、そのモジュールなどに応じて、少しはあります。 HANAに他のアプリケーションを展開している人はまだあまりいません。それは確かに可能です。したがって、SAPインフラストラクチャを取り巻く環境はより重要です。
ロビン・ブロア博士： デズに引き渡した方がいいと思う私はあなたの時間を独り占めしてきました。デズ？
デズ・ブランフィールド： ありがとうございました。いいえ、それですべてです。テーマを設定しようとするだけの、非常に簡単な2つの方法。 SAP HANAは数年前からリリースされており、人々はそれを検討する機会がありました。あなたが私たちにそれを実行している人々の割合の大まかな見積もりを与えた場合-このようなものを実行している多くの人々がいるので-あなたが気づいている市場の割合が現在なくなっていると思いますか従来のSAPの実装からHANA上のSAPまで？ 50 / 50、30 / 70を見ていますか？市場のどの程度の割合で、今移行し、動きを始めた人々と、物事の改善、改善、変化、または状況が何であれ、ただ控えめに待っている人々とを見ていますか？
ビル・エリス： ええ、私は実際に、私の観点から、パーセンテージを約20パーセントにしたと思います。 SAPは従来のビジネスである傾向があります。人々は非常に保守的である傾向があるため、人々は足を引きずります。また、SAPを長い間使用しているのか、それとも最近導入したSAPのようなSMBなのかにも依存していると思います。そのため、いくつかの要因がありますが、全体的には割合は50/50とは思いません。 50％は少なくとも手を出しており、HANAをデータセンターのどこかで実行しています。
デズ・ブランフィールド： 先ほどお伝えした興味深いことは、これはある意味で既成事実であり、時計は物理的および文字通り移行する時間を刻むということです。そうする過程で、人々はそれを考えたと思いますか？これはプラットフォームの過渡的な変化であり、単なるオプションではなく、デフォルトになっているという一般的な理解は何ですか？
そして、SAPの観点からは、パフォーマンスに大きな競争上の優位性があるため、彼らはその方法を推進していると確信していますが、それはまた、彼らがサードパーティに行くのではなく、プラットフォームのコントロールを奪い取っていることですパーティデータベース、彼らは今彼ら自身のプラットフォームにそれを戻しています。企業は実際にそれを得たと思いますか？人々はそれを理解しており、今ではそれに取り組んでいると思いますか？それとも、それはまだ、ある種、不明瞭なものですか、市場から出ていると思いますか？
ビル・エリス： SAPはコミュニケーションについて恥ずかしがり屋ではなく、SAPPHIREに行った人はどこでもHANAを見てきました。だから、私は人々はよく知っていると思いますが、人間の性質はそれが何であるか、あなたの知っているように、ある種の人々は足を少し引っ張っています。
デズ・ブランフィールド： 私がその質問をしていた理由だと思うので、あなたは私を許さなければならないでしょうが、それは私が同意することです。彼らはそれを伝えることに恥ずかしがっていなかったと思います。信号は多くの点で消えたと思います。そして、私はあなたに同意します–みんながまだ飛び上がったことを私は知りません。ご存知のように、従来の企業、これを実行している非常に大規模な企業は、いまだに多くの点で、足を引っ張るのではなく、シフトの複雑さに取り組もうとしています。あなたのツール、そして確かに今日のデモンストレーションが強調したことの1つは、私にとって重要なことの1つだと思います。今日、皆さんが聞いて調整し、座って反射的に注意を払うことを望んでいます。今では、このプロセスが単純化されたツールです。非常に神経質なCIOとその下のチームが、「何十年も前から知られている従来のRDBMS、リレーショナルデータベース管理システムから、まったく新しいコンピューティングのパラダイムに移行するにはどうすればよいか」と考えています。まだ比較的勇敢なスペースでのストレージ管理？」しかし、それは多くの点で未知であり、他の分野でそのシフトを行った人はほとんどいません。すでにインメモリコンピューティングに移行しているビジネスの別のセクションがあるわけではありません。だから、それは彼らの心の中のオールオアナッシングの動きです。
ですから、私がこれから何よりも取り除いたものの1つ-すぐに質問であなたを攻撃するつもりです-恐れが今、多くの方法で軽減されていると思います。もし私がCIOのリスニングだったら、「そうですね、どうやってこの移行をするのですか？リレーショナルデータベース管理プラットフォームとDBAの長年の経験で得たのと同じ機能を、現在スキルを持っていない新しいプラットフォームにどのように保証するのでしょうか？」 、あなたはツールがあなたが提供しているものと共に今そこにあり、彼らは一種の、深呼吸をして、移行が以前だったかもしれないほど怖くないという安reliefのため息をつくことができると人々は理解したと思いますかこのツールが利用可能になりましたか？人々は、インメモリコンピューティングとインメモリストレージへの移行と、NVMe、フラッシュ、ディスクの古い学校の組み合わせに取り組んでいるということを、今でも理解しているのでしょうか？
ビル・エリス： ええ、間違いなく、これをグラフィカルに表示し、何が起きているのかを把握し、トップのリソース消費者を簡単に特定できるテクノロジーとツールがたくさんあります。つまり、それは物事を簡素化するのに役立ち、テクノロジースタッフが本当に良いハンドルを握るのに役立ちます。ねえ、彼らは何が起こっているのかを知ることができ、すべての複雑さを理解できるようになるでしょう。したがって、市場のツールは間違いなく有用であるため、SAP HANAのワークロード分析を提供しています。
デズ・ブランフィールド： ええ、今日お見せしたことのすごいところは、ハードウェアの一部、オペレーティングシステムの一部を監視すること、そして移動するワークロードの一部を監視することです。しばらくの間。私にとっては、特にHANAのようなものの中では、必ずしも虫眼鏡を覗いて覗き込んで、クエリで何が起こっているのか、どのようになっているのかを確認することができなかったということです構造化され、その負荷がどこにあるか。
これまでに見てきた展開では、あなたが文字通り世界のプラットフォームでこの分野で最も権威があることを考えると、あなたが見たいくつかの素早い勝利-あなたが共有できる逸話的な知識がありますかユーレカの瞬間、アハの瞬間、人々がIDERAツールセットを展開したとき、彼らは彼らが持っていたプラットフォームとパフォーマンスに気付いていなかったものを見つけました。人々がそれを展開した場所の素晴らしい逸話的な例はありますか？実際に彼らが持っていたものを知らず、突然消えてしまいました、「わあ、実際にそこにあることを知りませんでしたか？」
ビル・エリス： ネイティブツールの大きな制限は、暴走したクエリがキャンセルされた場合、情報がフラッシュされるため、基本的に履歴がないことです。暴走クエリのように履歴をオフラインで保存することにより、履歴があり、何が起こったかを知ることができ、実行計画などを見ることができます。そのため、エンドユーザーコミュニティの基本的な操作の改善、レポートの作成などを支援できます。それで、歴史は本当に素晴らしいものです。そして、私が見せたかったことの1つは、最大4週間のリアルタイムを見ることができ、関心のある任意の時間枠に簡単にズームインでき、基礎となる運転活動を公開できることです。その可視性を持つことは、ボトルネックが発生したことを知るのに非常に役立ちます。
デズ・ブランフィールド： 展開された後はマルチユーザーだとおっしゃいましたが、多くの点でエージェントレスで効果的にゼロタッチであるという事実に非常に感銘を受けました。ツールを1回展開するだけで、クラスターを支えるコアインフラストラクチャをアプリケーションと開発チームまで監視するNOCのネットワークオペレーションセンターの全員が利用できるようになるのは普通ですか？それは当たり前であり、一度展開すれば彼らはそれを共有するでしょうか、それとも人々はスタックのさまざまな部分を見るモデルインスタンスを持つかもしれないと予想していますか？それはどのように見えますか？
ビル・エリス： したがって、基本チームは通常、SAPで行われていることの技術基盤に非常に強い関心を持っています。明らかに、ランドスケープ全体をサポートする複数のチームがあります。 HANAの部分はそのことに焦点を合わせています。私は、情報の主要な消費者としてデフォルトでSAPベーシスチームになります。
デズ・ブランフィールド： 右。ただし、コードレベルだけでなく、開発チームがいる場合、特にそこにあるデータセットの分析作業を行うデータサイエンティストまたはアナリストのチームがある場合、現在、私の考えでは、組織内のすべてに適用されるデータサイエンスへの大きな推進-そして、間違っている場合は修正します-これは、彼らにとっても非常に興味深いものになると思われます。データウェアハウス環境でできる重大なことの1つは、データサイエンティストを解き放ち、アドホッククエリの実行を開始できるようにすることです。ショップがあなたを怒らせているような状況の例はありますか？「データサイエンスチームを投入しました。本当に痛いです。彼らのために何ができるのか、私たちはただ何をしているのか」従来の運用上の監視と管理？」
ビル・エリス： ええ、私はちょっとこれを回して、返事をカットします、パフォーマンスを見て、QAプロダクションの開発でパフォーマンスを意識すること、あなたが知っている、あなたはあなたが持っているより少ない問題、より少ない驚き。だから、絶対に。
デズ・ブランフィールド： それに続いて、私が経験した多くのツール、そしてロビンも同意するでしょう-ここにある多くのツール、あなたが大規模なRDBMSを持っているなら、本当に高度なスキルが必要です。知識豊富で経験豊富なDBA。 SAP HANAに付随するインフラストラクチャとプラットフォームの要件の一部は、現在、特定のハードウェアなどから、私の知る限りで調整された特定のディストリビューションでサポートされているためです。ご存知のように、同じではない数十年の経験を持つ人々がいます。しかし、私が見ているのは、それが必ずしもこのツールの要件ではないということです。ツールを展開して、かなり新しい顔にそれを与えて、すぐにパフォーマンスが良くないものを見つける力を与えることができるように思えます。これに習熟し、それを展開することで価値を得るための非常に短い学習曲線があるのでしょうか？私の一般的な感覚では、価値をすぐに確認するためにツールを操作した20年の経験は必要ありません。そうだと思いますか？
ビル・エリス： ああ、絶対に、そしてあなたのポイントに、私は展開の成功の多くが本当にSAP HANA環境の計画と設計に依存していると思います。そして、間違いなく多くの複雑さ、それを基盤とする多くのテクノロジーがありますが、それは結局のところ、起こっていることの使用パターンを監視することになります。そのため、より複雑ですが、ある意味ではパッケージ化されており、多少簡素化されています。それは非常に貧しいです。
デズ・ブランフィールド： ええ、だから私がエリックに返事をする前に、彼がいくつかの質問、特に面白そうなQ＆Aからの質問を受け取っていることを知っているので、私はその答えを聞きたいです。誰かのための伝統的な旅-あなたはそれを手に入れることができると先に述べました、あなたはそれをダウンロードしてそれを試すことができます。今日聞いている人や後で再生するかもしれない人のために、すぐにそれを要約できますか？コピーを手に入れて展開し、購入する前に環境で試すための簡単な2つまたは3つのステップは何ですか？それはどのように見えますか？そのための手順は何ですか？
ビル・エリス： うん。したがって、IDERA.comから[製品]に移動すると、SAP HANAのワークロード分析が表示されます。ダウンロードページがあります。連絡先を尋ねられると思いますが、製品はライセンスキーでパッケージ化されているので、Setup.exeでインストールして、すぐにローリングできます。
デズ・ブランフィールド： だから、彼らはあなたのウェブサイトに行くことができ、それをダウンロードすることができます。しばらく前にそれを見たのを覚えていますし、昨夜も確認しました。メモリからデモをリクエストできます。あなたのチームの誰かが、それを通してあなたを案内してくれますか？しかし、実際に無料でダウンロードして、ご自身の環境でローカルに展開することはできますか？
ビル・エリス： はい。
デズ・ブランフィールド： 優れた。まあ、何よりも、それはおそらく私が個人的に行うことを人々にアドバイスすることだと思います、ウェブサイトからコピーを取得し、そこにドキュメントの一部を取得することは、それを行うための良いコンテンツがたくさんあることを知っているので、試してみてください。それを環境に入れて、見つけたものを見てください。 IDERAツールを使用してSAP HANA環境の内部を確認すると、実際には気付いていなかったものがそこにあることがわかります。
見てくれてありがとう、ロビンと私とのQ＆Aだけの時間に感謝します。エリック、参加者からもQ＆Aが出てくることを知っているので、私はあなたに戻ってきます。
エリック・カバナ： ええ、ここで簡単に確認できます。ですから、出席者の一人が、物事がどのように変化しているかについて話しているだけで、とても良いコメントをしています。過去に言って、メモリは窒息し、頻繁なページングによって速度が低下していましたが、現在のCPUはメモリ内のデータが多すぎて窒息しています。ネットワークの問題があります。常に動いているターゲットになるでしょう？ボトルネックがどこにあり、どこに注意を集中する必要があるかという点で、最近の軌跡をどう思いますか？
ビル・エリス： うん。あなたが測定するまで、知るのは難しいです。 SQLステートメントに関することの1つは、それらがリソース消費のドライバーになることです。そのため、大量のメモリ消費やCPU消費が発生する状況では、どのアクティビティがそのリソース消費を引き起こしたかを把握できます。さて、あなたは必ずしもそれを殺したいとは思わないでしょうが、あなたはそれと、また、何が起こっているのか、それがどのくらいの頻度で起こるのか、などを認識したいのです。私たちは、さまざまな状況への対応のセット全体またはクックブックに対処するという点で、まだ新しいものです。そして、それは素晴らしい質問であり、時間が経てばわかるでしょう。時間の経過とともに詳細情報が得られます。
エリック・カバナ： それでおしまい。さて、皆さんは非常に興味深いスペースにいます。コンテンツコールで提案されたように、SAPが移行を行うための素晴らしい長いオンランプを提供したことを知っているので、今後数か月および今後数年で多くのアクティビティが見られると思いますHANAへ。しかし、それでも、そのランプには終わりがあり、ある時点で人々はいくつかの深刻な決定を下さなければならないので、早ければ早いほど良いでしょう？
ビル・エリス： 絶対に。
エリック・カバナ： さてさて、ここ1時間、Hot Technologiesで燃え尽きました。オンラインで情報を見つけることができます、insideanalysis.com、techopedia.com。これらの過去のウェブキャストのすべてのアーカイブのリストを含む、多くの興味深い情報については、そのサイトに注目してください。しかし、皆さん、そこにいるすべての人、IDERAの友人、ロビン、そしてもちろんDezに感謝します。そして来週、皆さんに追いつきます。ご清聴ありがとうございました。気を付けて。バイバイ。