小さな紹介
IBSの私たちは、コンピューターがこの写真のように見えたときからHabrに行きたかったのです。 しかし、常に何かが欠けていました。時間、専門家、または興味深い話です。 最後に、すべてが一致し、主にテストラボ（IBS InterLab）の内部についてブログを立ち上げました。IBSInterLabでは、ITインフラストラクチャソリューションが開発され、顧客向けのテクノロジーがテストされます。 少なくともこの夏、私たちはめったに書きませんが、最も有用な素材を作ろうとします。 ありがとう
行こう
今日、恐らく、大企業のほぼ全体が何らかの形でERPまたは他の重いビジネスアプリケーションで動作します。 当然、時間の経過とともに、仮想マシンに移行する必要が生じます。 このタスクを簡単に解決することは危険なビジネスです。すべての驚きが常に途中で出てくるので、それぞれがプロジェクトの完全な失敗になる可能性があります。 これを防ぐために、 IBS InterLabチームはクライアントのタスクのためにさまざまなテクノロジーのテストに取り組んでおり、そのような研究の一環として、興味深い有益な結果を得ることができました。
どのようにすべてが始まりましたか？
顧客の1人のタスクについて、タンデムSAP + Oracle DatabaseとSAP + HANAのパフォーマンスの比較テストを行いました。 ロシア市場向けの新しいHANA DBMSの動作を確認し、HuaweiのHANA認定コンピュータコンプレックスと連携する可能性を確認することを、いくつかの目標を追求しました（これについては、必ず個別に説明します）。
しかし、生命は動的なものであり、非常にすぐに（宇宙の基準と科学技術の進歩によって）、IBSで開発されたSKALA-Rユニバーサル収束複合体が地平線に現れました。 そして、特別な難しいテストを行う時間はありませんでしたが（近い将来、間違いなくそれを行います）、戦闘状態で作業するときに実際の能力を評価するために手をかざすだけでした。 「動作する/動作しない」をチェックするだけでなく、それが動作することを100％確信していました。
パフォーマンスを有名な製品と比較したかった。 したがって、彼らは、すでに実行されたVMWareバンドルテストと比較するために、プラットフォームでSAP + Oracleバンドルのテストを続けることにしました。
入力データ
以前に使用したテストコンプレックスはクラウドに実装されましたが、比較がやや簡単になったため、手のかゆみが増えました。 そのため、SCALA-Rクラウドでは、同一の仮想マシンが作成されましたが、前の仮想マシンが異なるハイパーバイザーを使用して実装された場合にのみ異なり、このテストではParallelsのハイパーバイザーを使用しました。 Raidixソフトウェアを使用してディスクアレイにアセンブルされたLUNがこの仮想マシンに接続されました。 そして、後者、より正確にはスケーリングに関して、特定の困難がありました。以前に使用され、SCALA-Rに含まれていたディスクサブシステムのパフォーマンスを相関させる必要がありました。
IOPでの直接的なパフォーマンス測定を比較することにより、この問題を解決しました。 最初のテストでは、仮想ディスクサブシステムの実際のパフォーマンスは1500 IOPであり、SCALA-Pの専用LUNの測定パフォーマンスはIOMeterによると1900 IOPであり、 計算機を使用して計算された理論上の1998 IOPにほぼ達しました。 同時に、完全を期すために、ディスクアレイキャッシュが小さなボリュームで非常に働きすぎて、途方もない37100 IOPを受け取ったため、テストデータのサイズが大幅に増加した後にのみ1900 IOPの結果を達成したことに注意する必要があります。
ハードウェアリソースの比率を理解したことで、テストが開始されました。 ただし、テストでDBMSが小さく使用されたため（1 GB未満）、テスト結果に対するキャッシュのアクティブな影響を事前に決定したことに注意してください。
テストプロセス
テスト中に、ABAPで記述されたプログラムと標準のSAP R / 3機能の両方を使用して、30種類のクエリが実行されました。
- テストの最初のグループ 。 ここでは、多数のレコードとフィールド（約100）を持つ2〜3個のテーブルを使用し、そこから複数の方向のサンプルを作成しました。 同時に、さまざまなテストで返されるレコードの数を数回変更するような方法でフィルタリング基準が選択されました。
- 個々のデータベースフィールドの選択（行1および3）。 3つのフィールドが選択され、フィルタリング条件により、大量のレコード（数十万件）または小規模のレコードが確実に返されました。
- 同じテーブルのすべてのレコードフィールド（行2および4）の選択 。 ろ過条件は同じままでした。
- 同じテーブルのすべてのレコードフィールド（行5〜7、13、15、17）の選択 。 フィルタリングは、キーフィールドと非キーフィールドによって実行されました。
- 同じテーブルから1つのレコードフィールド（行8〜12、14、16、18）を選択します。 フィルタリングは、キーフィールドと非キーフィールドによって同じ方法で実行されました。
- テストの2番目のグループ。 この場合、19〜21行目で集計タイプのクエリが使用されました。つまり、集計操作の実行を意味します。レコードは、会社コードと転記通貨でグループ化するときに「転記値」フィールドで計算されます。 HANAは分析アプリケーションに最適化された（つまり、集約要求を実行する）システムとして位置付けられているため、このタスクはテストプログラムに含まれていました。
- テストの3番目のグループ。 テストの次のラウンドには、SAPに組み込まれたツール（テーブルコンテンツの表示-トランザクションSE16）を使用して実行された非フィルタリング選択（行22〜25）の実行が含まれ、テーブルのコンテンツを表示できます。 同時に、返されるレコードの数の最大制限がこのユーティリティに設定されました-50,000。
- テストの4番目のグループ。 最後のテストは、標準のSAP R / 3機能の一部である合成テスト（26-29行目）と、R / 3からBWにデータをインポートするSAP BW分析レポートシステムの独自のデータ抽出（30-34行目）でした。 抽出者は、指定された基準（主にドキュメントを選択する期間）に従ってデータを取得しました。
キャッシュのパフォーマンスレベルを評価するために、各テストを2回実行しました。 その結果によると、最初の操作中にすべてのデータがデータストレージシステムから読み取られ、2番目の操作中にキャッシュメカニズムが最適化されることが明らかになりました。 同時に、Oracleサーバーキャッシュの影響を排除するために、新しいタイプテストを実行する前に、ゼロを設定しました。
そして今、すべてが始まったのは、テスト結果です。 理論的には、すべてが表に明確に示されているため、特別な説明は必要ありません。 しかし、質問がある場合は、コメントでいつでも質問することができ、迅速かつ完全に対応します。 だから、見て。
まとめると
私たちは絶対的な科学的正確性を主張しなかったので、かなり自由な形式で結論を導きます。
- 最初に 、Oracleソフトウェアのキャッシュの仕組みを明確に確認できます。1回の実行で、操作の完了に必要な時間を大幅に短縮できます。 これは、Oracleの利点によるものです。
- 第二に 、各最初のテストに費やされた時間は、ディスクサブシステムのパフォーマンス比（1500IOP / 1900IOP）とほぼ同じで、ほぼ同等であることが判明しました。 同時に、SCALA-Rでの同じタイプのテストの後続のパフォーマンスが結果を改善することに注意する必要があります。これは、ディスクアレイキャッシュを含めることで説明されます。
- 第三に 、私たちは可能な限り公平で客観的になりますが、同時に、 SCALA-RはERPをサポートする非常に良い仕事をしたことに注目します。 競争力のある機能を備えたプラットフォームで非常に適切な結果が得られましたが、有名なメーカーのハイパーバイザーやディスクアレイでの従来のソリューションと比較して大幅に低コストです。 実験の純度のために、「デフォルト」設定でテストを実施することが決定されました。
追加、質問、反対、いわば「苦情や提案の本」に追加するものがある場合は、コメントで議論を続けていただければ幸いです。
専門家は、Andrei Sungurovの積極的な参加を得て、Alexander SashurinとAlexander Ignatievのポストに取り組みました。
彼らに感謝します。
IBS Interlabチーム 。