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
203
このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

https://blogs.sap.com/2013/07/24/from-the-archives-the-myth-of-linear-scalability/

 

この記事のオリジナルは、Glenn Paulley が sybase.com に 2008 年 5 月に掲載したものです。

 

Ivan Bowman と私が SQL Anywhere の容量計画というテクニカルホワイトペーパーで概説した落とし穴の1つに、パーフェクトなスケーラビリティーの神話があります。

これは、因子 X でハードウェアプラットフォームを単純に改善すると、それに応じてアプリケーションのパフォーマンスが改善するというものです。

しかしながら、リニアにスケールするアルゴリズム(またはアプリケーション)はほとんど存在しないということを覚えておいた方が良いでしょう。

あるいは、全ての CPU が同じスピードで待機するという原則を常に念頭においておくと良いかもしれません。

一つの例として、最も重要なビジネスのオブジェクトのいくつかにおいて、サロゲートキーを使用して識別するデータベース設計をみてみましょう。

このアプリケーションは、サロゲートテーブルと呼んでいるデータベース内の特別なテーブルを使用するように設計されています。テーブル内のそれぞれのローはビジネスオブジェクトのタイプを表します。

サロゲートテーブルのそれぞれのローに含まれているのは、そのタイプの新しいビジネスオブジェクトを挿入する時に使用される次のキーの値です。

その値が next_key カラム内に格納されていると仮定します。

アプリケーション内で、データベースに新しいクライアントを挿入するロジックは、おおよそ以下のようになります。
DECLARE @next integer;
UPDATE surrogate SET @next = next_key, next_key = next_key + 1
WHERE object-type = ‘client’;
INSERT INTO client VALUES(@next, ...);
COMMIT;

*SQL Anywhere の言語機能では、UPDATE 文の SET 句内の変数を割り当てることが可能です。

このコードスニペッドは、データベースに対して新しい情報を挿入する場合に頻繁に行われるアプリケーションの開発方法を表しています。
--- 私は、お客様のアプリケーションでこれを何度か目にしてきました。

このコードスニペッドでは、新しいクライアントローの毎挿入というシリアル化が発生します。

なぜならば、サロゲートテーブルの「クライアント」ローの書き込みロックは、一度に 1 接続しか書き込みロックを取得できないからです。

接続が少数の場合には、このロジックでも適切に機能するかもしれませんが、このアプローチは、スケールしません。

大規模ユーザーの場合、convoy のフォーメーションが必須です。

SQL Anywhere では、そのスレッディングモデルにより、このタイプの convoy の結果は通常スレッドデッドロックです。

M 数のスレッドが、サロゲートテーブル上の同じ書き込みロックに対して待機し、同じ INSERT を行っている利用できる最後のスレッドがブロックしようとします。

これは、完全なスケーラビリティーとは神話にすぎないことを説明する良い例です。

なぜならば、このタイプのアプリケーションで CPU のスピードを上げても、実際には、何の改善も生まないからです。

また、このようなタイプの問題は、診断が難しくなりがちです。

なぜならば、期待される動作が全く行われていない場合、問題の診断はより難しくなるからです。パフォーマンスモニターの I/O や CPU カウンターは問題解決の糸口の発見の役に立ちません。

ここで私が指摘しようとしているポイントはつまり、データベースアプリケーションのパフォーマンスとは、データベースシステムの仕様にある程度依存するものの、結局、アプリケーション内のロジック、さらには、そのロジックがより多くのユーザーやデータ量にどれだけうまくスケールするかに大きく依存するということです。

これが、キャパシティプランニングの質問に対する、簡単でクイックな回答がめったにできない理由です。

そのため、ハードウェアのキャパシティプランイングの代替として、一般的にはオーバースペックにする策がとられることになります。本当に必要なものよりも、より大きなハードウェアパフォーマンスのものを購入すれば、ピークのワークロードも問題にならなくなるからです。

===

 

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」

を入力してください。

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

 

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

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