SQLの最適化のTPC-Cシリーズの分析03_TPC-Cベンチマーク
TPC-Cは非常に厳しいベンチマークテストモデル、完全なリレーショナル・データベース・システムの全体をリンクする能力のテストです。TPC-Cのリストの最前線に、リレーショナルデータベースの理論から、数十年にわたり蓄積してきた業界ではよく知られているいくつかはほとんど生じ、同期、同社のデータベースを開発し始めただけのように見えるのはこのためです。次は、TPC-CテストOceanBase SQLデータベースモジュールを分析するために、あなたのために、この記事を渡す最適化がなされ、遭遇した課題何か、具体的です。
背景
人々の理解は検査が非常に同時ストレス・シナリオ、最終的な性能指標tpmCをデータベーストランザクション処理能力で、TPC-C、TPC-Cは、典型的なOLTP（オンライントランザクション処理）シナリオのテストであることを知っています（分当たりのトランザクションの数、すなわち、微細加工システムTPC-Cモデル当たり新規注文トランザクション）システムと尺度としてtpmCを当たりの平均コストに。OLTPシナリオでは、各要求の応答時間は非常に短いです。そのため、各データベースベンダーは、TPC-Cのテスト中に、最小限にするたびに圧縮を操作するTPC-Cのテストでは、いくつかの重要な操作は、多くの場合、CPUに改善が必要な最適化と言っても過言を可能にすべてを行いません命令レベル。
私たちのテーマに入る前に、のは、これらの5件の取引の特定によれば、主に5つの取引、オーダー作成、支払うため、注文のお問い合わせ、受注、出荷及び在庫情報に分けTPC-Cトランザクションモデル、について話しましょう割合が発生し、テストでは、トランザクションを作成するために、毎分実行の注文数の究極の尺度です。ご存知のように、各データベーストランザクションは、実際には、つまり、すべてが成功する、またはすべてが、これは、データベース内の「原子」と呼ばれている失敗のどちらか、SQL文のいくつかの部分は、彼らがトランザクション内にある特定のロジックによって関連しています"A" でACID。そして、TPC-Cトランザクションは、それはおよそどのくらいですかかりましたか？唯一の十ミリ秒 - 非常に明確に報告書を見てください。トランザクションは複数のSQLで構成さを考慮すると、それはすべてのSQLの平均は1ミリ秒未満でありました！
完了実行に当初からSQL文のモデルとC / S（クライアント・サーバ）は、クライアントの経験からの入力、ネットワーク伝送、SQLの最適化が必要では、実行は、クライアントにそのようなプロセスの結果を返します。ただ、フィールドを行う可能性があります、各SQL更新の具体的な実装では、必要な実行時間は、非常に短く、リンク全体の観点から、それは資源が得られ、クライアントとの相互作用の中に多くの時間を要し無駄に時間のかかるを高めます。だから、どのようにこの問題を解決するには？答えは、ストアドプロシージャを使用することです。
ストアドプロシージャ
いわゆる「ストアドプロシージャは、」データベース・ユーザーのためのプロセス指向のプログラミング言語です。この言語に基づいて、ユーザは、プロシージャ（手順）、および任意の時間呼び出しでデータベースに格納されたコールにアプリケーションロジックをカプセル化することができます。ユーザは、1つの相互作用により作業を完了するために、このようにデータベースで数回やり取りするために必要とされるであろう中間伝送ネットワークの必要性と待ち時間（図1参照）を排除し、完了しています。取引ネットワークは、CPUの30％がトランシーバと決意ネットワーク上で過ごしたことを意味し、平均30％の費用がかかります。だから、6000万tpmCをスケールのテストでシステム容量の面でCPUリソースの30％の節約が素晴らしいです。ストアドプロシージャを使用しても、システムのCPU使用率を高める間接的、トランザクションロックデータベースカーネル短縮における重要な領域で、その結果、全体的なスループットが増加を減少トランザクション応答時間をもたらすことができます。消費も重要な役割を持っているの待ち時間を短縮するために、アプリケーション側でのストアドプロシージャを。
TPC-Cは、記憶処理は、システム全体のアップグレードの効率のために重要です。2.2バージョンに完全にストアドプロシージャをサポートしていますが、また、最適化の極限の多くを行ってストアドプロシージャの効率だけでなく、OceanBase。
コンパイラの実装
プロセス指向の高級言語としてのストアドプロシージャは、実行可能マシンコードに変換する必要があります。このプロセスは一般に「解釈」「コンパイル実行」とに分けることができる2つは、一般的に、コンパイラは、完全なコードの最適化の実現、高効率を説明するために比べ行いました。最後の2年間、効率的なバイナリ実行コードの実行効率にストアドプロシージャを翻訳するLLVMコンパイラフレームワークの成熟度は、コンパイラがストアドプロシージャをサポートして実装し、動的コンパイルから（実行時コンパイラ）の方法を使用しOceanBase改善の大きさの順に取得しました。一方、ストアドプロシージャは、クロスプラットフォームのコンパイラを実行する能力を獲得し、自然に有するように中間コード及びマシン独立に、ストアドプロシージャのLLVMフレームワーク中、LLVM内蔵最適化プロセス我々は、異なる様々なハードウェア・プラットフォーム上であることができることを確実にするために正確かつ効率的に実行可能なコード。
配列バインド
もう一つは、TPC-Cテスト機能に重要な役割は、この関数はまた、「配列バインド」と呼ばれているOracleでのDML文のバッチ処理に能力があるプレー。実行プロセスにおけるSQLデータベースに一般的に二段階で「計画の生成」と「実装」に分けることができます。私たちは、SQLの実行計画のキャッシュをしたが、全体の実行プロセスにおける実施計画の適切な部分を見つけることはまだ時間がかかりますが。この時間を排除方法はありませんか？SQLの実行計画のセットは正確に同じことを実行するだけのパラメータが記憶処理で、異なっている、我々は彼らが一度だけ実行する必要があり、その後、「計画の生成」、特定の構文を通じてバッチ処理を実行することができた場合これは、いわゆる「結合配列」です。
配列バインドでは、データベースが最初に使用したいプログラムを見つけ、その後、計画を実行し、それぞれ完成し、再実行プロセス・パラメータが結合した後の（結合）します。類推は、データ構造を再定義するのではなく、割り当てを繰り返す、ループのC言語のようなものです。ユーザ制御下での使用の結合配列は、この機能をトリガするために、ストアドプロシージャにFORALLキーワードを使用する必要があり、TPC-Cテストは、我々は、アレイは、システム容量を改善するために、バインディング数回使用、効果は明らかです。
プリペアドステートメントおよび実施計画キャッシュ
プリペアドステートメントの対話要求はバイナリプロトコルであり、それは大いにシステムの相互作用のコストを削減することができます。OceanBaseプリペアドステートメントを使用して、ユーザープログラムとデータベースの間でサポートするだけでなく、SQLエンジンは、実行時に、このエンジンの相互作用を使用してストアドプロシージャを呼び出すサポートしています。SQLストアドプロシージャの後、後続の各実行は、IDと対応するパラメータを渡す必要があり、準備動作を行い、一意のIDを得るために、システムは、ストアドプロシージャまたはSQLを開始するようにスケジュールされている対応するキャッシュを介して見ることができます。この手順のSQL文を使用すると、要求のテキスト解析CPUのオーバーヘッドを多数の必要性を排除し、対話的に比較しました。
OceanBase実行可能コードのストアドプロシージャとSQLの実行計画をキャッシュするために内部にキャッシュするため、ストアドプロシージャおよびSQLオブジェクトの異なるパラメータが数十マイクロ秒以内に、一般的に消費し、このキャッシュを介して取得迅速に実行する必要があり、効果的な再コンパイルを避けるために、ミリ秒の待ち時間とCPUの消費をもたらします。
更新可能なビュー
OLTPシナリオでは、データベース・アプリケーションとの相互作用の数を減らすことによって、多くの例の性能向上を達成するために、更新可能なビューは、そのうちの一つです。最も一般的なビューは通常、読み取り専用データベースで、ビューを定義することによって、ユーザーは自分の興味だけでなく、そのデータ・アクイジション・インターフェースを定義することができますが、同時にまた、TPC-Cの新しい順にシーンを作成するよう、更新操作としてエントリを表示することができます、アプリケーションは、製品情報、アップデートのインベントリを取得し、更新された値を取得する必要があります。このプロセスは、一般的に2つのSQLによって達成することができます。
？i_price、i_name、I_ID =項目からi_dataを選択します。
UPDATE株式
SETのs_order_cnt = s_order_cnt + 1、
s_ytd = s_ytd +？、
s_remote_cnt = s_remote_cnt +？、
s_quantity =（CASE s_quantity <+ 10 THEN s_quantity + 91 ELSEのs_quantity終了？） - ？
WHERE s_i_id =？
AND s_w_id =？
RETURNING s_quantity、s_dist_01、
i_dataは '％原文％' THEN 'G' ELSE（CASE S_DATAは次のようにしない場合は '％ORIGINAL％' THEN 'G' ELSE 'B' END）ENDを好まないCASE
BULKは... INTOを集めます。
しかし、更新可能なビューの設立を通じて：
AS VIEWのstock_itemをCREATE
SELECT i_price、i_name、i_data、s_i_id、s_w_id、s_order_cnt、s_ytd、s_remote_cnt、s_quantity、S_DATA、s_dist_01
在庫Sから、項目I WHERE s.s_i_id = i.i_id。
私たちは、インベントリを更新し、文を経由して商品や在庫情報を取得することができます：
UPDATEのstock_item
SETのs_order_cnt = s_order_cnt + 1、
s_ytd = s_ytd +？、
s_remote_cnt = s_remote_cnt +？、
s_quantity =（CASE s_quantity <+ 10 THEN s_quantity + 91 ELSEのs_quantity終了？） - ？
WHERE s_i_id =？
AND s_w_id =？
RETURNING i_price、i_name、s_quantity、s_dist_01、
i_dataは '％原文％' THEN 'G' ELSE（CASE S_DATAは次のようにしない場合は '％ORIGINAL％' THEN 'G' ELSE 'B' END）ENDを好まないCASE
BULKは... INTOを集めます。
これは、ステートメント、更新ロジックと、より直感的に対話する必要がなくなります。更新可能なビューは、ユーザが通常のテーブルビューと同じように動作することができ、すべてではないビューは、更新可能なビューとして定義することができます。例えば、曖昧であるため、更新を許可することができない行特定の更新セマンティクスビューによって異なる、基、です。stock_itemビュー上記の二つのテーブルを結合するために、特定の、ユニークである必要があります参加する、すなわちitem.i_id前提した後にユニークキーユニーク（キー保存表）を保持更新されたテーブルを満たす必要があります。
これは、TPC-C仕様は、マテリアライズド・ビューの使用を禁止し、強調され、基礎となるデータを変更しない更新することができるビューはテーブルの形で記憶され、準拠しています。
概要
設計基準TPC-Cは、シーンを実行しているOLTPシステムの「本当の」反応としてあるので、私たちの最適化の多くは、幅広い適用性を持っています。例えば、並行性の高いOLTPシステムのために、最も時間のかかるSQL要求が非常に短い、相互作用の純粋なC / Sモデルを使用しての結果は、データベース・アプリケーションで頻繁に相互作用して無駄なシステム時間にバインドされ、大幅この相互作用を容易にすることができるストアドプロシージャの使用は時間がかかり、ネットワークジッタを免疫系を強化する、分散OLTPデータベースのこの中核能力が不可欠です。
独立した研究開発の道に付着する開始からOceanBase、このオプションでは、我々はデータベース・カーネルを制御するための完全な能力を持っていることを保証しますので、私たちはあらゆるシーンでの極端なパフォーマンスの自信と強さの追求を持っているだけでなく、製品開発の方向性を形作ります明確な計画や目標があります。このTPC-Cのテストでは、我々は、Oracle互換性のあるデータ型と構文を使用して、すべてのストアドプロシージャとSQL、OceanBaseは、Oracle互換モードのバージョン2.0をサポートするようになりました使用するだけでなく、確実にするための究極の最適化の追求でそうします製品の反復は、一般的な、通常の方向に沿って開発することができます。OceanBaseバージョン2.0を起動し、OceanBaseは、ストアドプロシージャをバージョン2.2をサポート（PL / SQL）機能の改善と、Oracleの目標に大きな互換性に向けて続けてきた、私たちの製品はまた、反復の新ラウンドを完了しています。私たちはしっかりとTPC-Cテストの結果はOceanBaseも成熟した製品のための新たな出発点にOceanBaseデータベースとなり、極端なパフォーマンスを目撃していないだけで、この時間と考えています。
著者：
- 陳Mengmeng：研究開発のOceanBase SQL方向を担当するシニア技術専門家の現在のアリゴールドのドレスOceanBaseチーム。2006年には、CERN（CERN）でのグリッド・コンピューティング・スケジューラの開発を担当し、2009年にはウィスコンシン大学マディソンのコンピュータ大学の修士号を授与された2008年に清華大学、2006年卒業し、彼は、Oracle、華為米国で働いていましたデータベースの開発と研究機関が従事しました。
- パン李：パラレルクエリとOLAPエンジンのOceanBase新世代の責任上級技術専門家の現在の金スーツアリOceanBaseチーム。オラクル社は、Oracleパラレルクエリのデータベースの開発作業と特許出願件数を担当し、米国のために働いています。