Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Sawa_Ito
Product and Topic Expert
Product and Topic Expert
0 Kudos
192
このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

この記事のオリジナルは、Glenn Paulleyが sybase.com に 2008 年 12月に掲載したものです。パフォーマンスベンチマークのテーマは決してすたれることはありません。

 

10年以上にもわたって、我々 iAnywhere 社では、スキーマとクエリの複雑性はデータベースインスタンスのサイズや、ハードウェアプラットフォームの性格とは全く相関関係がないという議論をかわしてきました。
我々の経験では、アプリケーションまたはスキーマの複雑性、そしてデータベースのサイズまたは配備プラットフォームの間には、相関関係とはほとんどありません。

アプリケーション開発者は、フロントラインの業務向けに既存のアプリケーションを移行する際、ターゲットがリソースが限られたハンドヘルドデバイスのようなプラットフォームであるにも関わらず、シンプルに設計するどころか複雑にしてしまう傾向があります。

このようなデバイスへの移行では、入力モードが異なるという理由で、ユーザーインターフェースの再構築にとどまるってしまうのが通常です。

今週あった3件のお客様とのやりとりの中で、私のこの見方はさらに確固たるものになりました。

  1. あるお客様のスキーマは、121 のテーブルで構成されており --- 2003 のインスタンスに対して20 増加 --- 宣言された RI (ON DELETE CASCADEを含む)、CLOB属性、そして自己参照型"star" join を含むビュー がありました。ある 1 つの事実 --- SQL Anywhere が Intermec 社の数千もの Windows Mobile ハンドヘルドデバイス上で稼働していること --- を除けば、特別なことはありません。

  2. 別のお客様では、existential (EXISTS) と universal (NOT EXISTS) 定量化の両方を利用する 3つのレベルのネストされた SQL クエリに関しての支援リクエストでした。このクエリは、Ultra Light データベースに対して実行されるもので、これもまた、Windows Mobile デバイスでした。

  3. そして、もう 1 社のお客様は、8-wayの UNION クエリに関しての支援リクエストで、そのステートメント文内の各クエリ仕様は、3-way の join と universal に定量化されたサブクエリの両方を含むものでした。これもまた、1つの重要なことを除けば、それほど特殊なものではありません --- このクエリは、Blackberry デバイスで稼働するUltra LightJ データベースに対してのものでした。(注:Blackberryのサポートはversion 16までです)


 

他のブログ記事の中で、私はTPC-C [2] や TPC-E のような業界標準のベンチマークは、全てではないものの、お客様のワークロードのほとんどと異なるというスタンスを示しました。これは、IBMの2001年[1]の研究からの発見です。我々の見解では、これらのベンチマークには、我々が、通常お客様のアプリケーションの中で見つける洗練されたクエリ処理が欠けているため、TPC ベンチマーク結果とお客様のアプリケーションのパフォーマンスの間には、ほとんど関連性がないと考えています。

 

この弱点に対処した新たなベンチマークを提案するべき時が今なのかどうかはわかりませんが、このようなベンチマークを作成する触媒となってくれるのが、Hibernate や LINQ のようなクエリ生成ツールの継続的な広がりにあると考えています。

どちらも、アプリケーションで使用されているオブジェクトの関連セットを構築するためのリーズナブルかつ複雑なクエリを生成することができますが、比較的少しの行しか返しません。 (余談ですが、あなたが存在量化型サブクエリが含まれる outer join を含むクエリを最後に書いたのはいつでしょうか ?)

 

私が考えるベンチマークとは、「ワークロードがミックスされた」ものであり、シンプルな DML リクエストや、ほとんど行を返さない多様な join クエリ、特定の傾向をつかむ目的でデータベースのコンテンツを分析するためにたまに実行する「レポーティング」のクエリなどを組み合わせたものです。

適切なワーキングセットの分析とデータスキューともに、このようなベンチマークこそが、現実社会のワークロードをより正確に表していると思っています。

 

[1] W. W. Hsu, A. J. Smith, and H. C. Young (2001). Characteristics of production database workloads and the TPC benchmarks. IBM Systems Journal 40(3), pages 781-802.

 

[2] Francois Raab (1991). An Overview of the TPC Benchmark C: A Complex OLTP Benchmark. In The Benchmark Handbook, Jim Gray, ed., 2nd edition. Morgan Kaufmann Publishers, San Francisco.

===

 

SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページ<英語> を参照してください。

 

上記のコミュニティーに掲載されている技術情報は、順次SQL Anywhere 日本語コミュニティ

に掲載しています。

 

SQL Anywhere に関してはまずはこちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。

 

SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。

Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」

を入力してください。

不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。

 

======================
ご購入に関するお問い合わせ

こちらよりお問い合わせください。