MS SQL 2012（RC0）を例として使用してパフォーマンスとフォールトトレランスを最適化するための新しいツールと方法：Denali

この記事の準備中に、Microsoftは既にMS SQL Server 2012：RTMをリリースしており、製品の最終バージョンが間もなくリリースされ、多くの興味深い革新が計画されています。



それらをすべて1つの資料でカバーするのは非常に難しいので、2つだけに焦点を当てます。これは最も興味深いと思われます。生産性とフォールトトレランスの向上に関連しています。 それらはリリース候補の例を使用して調査されましたが、最終リリースで何かが大きく変わるとは思いません。





この記事で説明するサーバーのパフォーマンスに関連するほとんどすべてのMS SQL機能は、読み取り操作の最適化を目的としています。 いくつかの新しい機能を効果的に実装するには、リレーショナルデータベースの構築とメモリ内のデータ表現の形式を復元する必要があります。 また、これらのデータベースと連携するソフトウェアの修正も必要です。



多くの場合、データ処理システムは同じデータセンター内にありますが、データセンターの障害が発生する可能性が非常に高いため、常識の観点からは必ずしも論理的ではありません。 記事のこの部分では、地理的に分散したデータ処理環境を検討しますが、次の形式の仮想ファームのベンチ環境でエミュレートします。

すべてのための1つとすべてのための1つ：AlwaysOnと可用性グループ

誰もが知っているように、高性能クラスタは手作りのものであるため、高価です。 多くは、財布を傷つけることなくそれを感じたいと思っています。 同様のソリューションが最初にExchange Serverにデータベース可用性グループの形で登場し、その後データベースサーバーのニーズに適合しました。

それで何ですか？ AlwaysOn機能（ちなみに、Enterprise Editionでのみ使用可能）は、データベースのフォールトトレランスを提供するように設計されています。 これらのデータベースが動作するインスタンスではなく、浴場データベースです。 このテクノロジーは、サーバー間、より正確にはトランザクションログ間でデータベースを複製することで機能します。



地理的に分散したサーバーのフォールトトレラントグループをモデル化するプロセスを検討します。 外部ドメインコントローラーの制御下でドメインに入力された4つの同一サーバーを取得します。 実際に近い環境でデータがどのように交換されるかを確認するために、2つ（SQLONE、SQLTWO）で10 Gbの速度で接続を設定し、SQLTHREEを1 Gbのチャンネルに設定し、SQLFOURは3Gで同期されます（これは真空中の球状の馬なので、その後、10 Mbの速度を取ります）。 それらはすべて、Cisco Nexus 5548によって結合されたDEPO Storm 5302サーバー（FCoE）およびLSI 2600ストレージ（FC）に基づいて作成された仮想クラウド（ESX 5.0）に含まれています。



MSSQLサーバーのグループをフェールセーフクラスターに統合すると（クォーラムなしでノードマジョリティで十分です）、各サーバーで「AlwaysOn Avaibility Groups」オプションを有効にします。







既に説明したように、トランザクションログをパートナーサーバーに展開することでレプリケーションが実行されるため、将来のフォールトトレラントデータベースを選択し、完全復旧モデルに切り替えます。 このベースに基づいて、可用性グループを作成し、最大3台のセカンダリサーバーでスペアプレースメントを割り当てます。







これらのサーバーでの作業スキームを指定します。すべてのサーバーが、選択したデータベースのデータを自分自身に複製します。 グループのすべてのサーバーでこのデータベースのユーザーのログインを作成することを忘れないでください。 1つまたは2つのサーバーで、元のデータセットとの同期レプリケーションをサポートできます。 そのうちの1つはフェールオーバーに対応している必要があります。これにより、プライマリで問題が発生した場合にカスタマーサービスを引き継ぐことができます。 デフォルトでは、セカンダリは何もせず、電気を食べるだけです。 [読み取りアクセス許可]ボックスをオンにすると、同期レプリケーションモードの通常のセカンダリがアクティブセカンダリまたは読み取り可能なセカンダリに変わります。



次のようになります。







「そして、この寄生虫は私たちにとって何の役に立つのでしょうか？」とあなたは尋ねます。 まず、読み取り要求を処理できます。 特に、可用性グループに接続するアプリケーションがデータの読み取りのみを目的としてこれを行う場合（読み取り専用）、つまり、パラメーター 'Application Intent = readonly'が接続初期化行にあります。



次に、可用性グループにあるデータベースには、「バックアップにセカンダリを使用する」というすばらしいオプションがあります。 したがって、データベースがバックアップに24時間かかるボリュームにまで成長した場合でも、1日でオフィスの営業日とサーバーのメンテナンスウィンドウを押し出そうとせずに、セカンダリのデータレプリカから安全に実行できます。 これは、24時間年中無休の動作モードのデータベースサーバーに特に便利です。



一般に、データベースで動作するアプリケーションを慎重に編集することで、すべての読み取り操作がアクティブなセカンダリで実行され、書き込み操作がプライマリに集中するようにできます。

データベースを操作するアプリケーションが適切なアドレスにすぐにアクセスできるように、専用の「リスナー」を割り当てるオプションもあります。







もちろん、このスキームには欠点があり、まず第一に価格です。 一方、1台のサーバーが書き込み、2台が読み取り、4番目のラウンジでそのコピーを管理するときに作業のスキームを取得します。 最初の読者のいる作家はモスクワにいて、2番目の読者はサンクトペテルブルクまたはロンドンにいて、「ローファー」はウラジオストクまたは北京にいます。 このアプローチにより、メインサーバーの読み取り操作の負荷を軽減し、アンロードしてより効率的な書き込み操作を行うことができます。これは、従来のフェールオーバークラスターよりも効果的です。

垂直方向に7つ、水平方向に4つ-列ストアインデックス

データベースでの作業を最適化するためのもう1つのオプションは、いわゆるColumnar DBMSです。 従来の行ベースとの主な違いは、データの内部表現です。 次のようなテーブルがあるとします：







古典的な行ベース（文字列）データベースは、このデータを次の形式で保存します。







これは、データベースに行全体を追加することが多い場合には便利ですが、名前や姓などの選択を選択することは非常に困難になります。そのような選択では、テーブル全体を読み取る必要があるためです。



「newfangled」の場合（つまり、前世紀の70年代前半に発明されたが、Microsoftの専門家によれば、それは突然になった）円柱状のデータベースは次の形式で格納されます。







ここでは状況がまったく逆であることに気付くのは簡単です。行を追加するには、各列を変更する必要があります。したがって、データベースをRAMにプルし、並べ替えて元に戻します。 しかし、1つの操作で新しい列を追加したり、既存の列を変更したりするには、単に吐き出します。 繰り返しますが、選択的サンプリングは非常に便利になります。ソースデータベースの必要な列を取得するだけで、RAMのスペースを節約できます。



圧縮中にColumnar DBの追加のプラスが現れます-列内のデータは行内よりも均一な外観を持っているため、LZWタイプの圧縮アルゴリズムは行上よりも列上でより高度なデータ圧縮を行います。



Columnstoreインデックス（CSI）を使用すると、テーブルからRowbasedとColumnarのハイブリッドを作成できます。 つまり、従来の行ベースのテーブルで、列形式で保存する列を選択する機会が与えられます。



これにはいくつかの制限が伴いますが、最も不快なものは次のとおりです。

• Columnstoreインデックスがテーブルで定義されている場合、テーブルは変更できません。 UPDATE、INSERT、DELETE、およびMERGEはありません。 もちろん、DROP-> INSERT-> CREATEを実行できますが、堆積物は不快なままです。
• Columnstoreインデックスを使用できる列には型制限があります（http://msdn.microsoft.com/en-us/library/gg492088(v=sql.110).aspx#Described）;
• 列ストアインデックスはキーにすることはできません（プライマリ-プライマリ、外部FOREIGNの両方）、一意にすることはできず、ASCおよびDESCで並べ替えることはできません（圧縮アルゴリズムが並べ替えを担当しているため）およびその他（http://msdn.microsoft.com/ en-us / library / gg492088（v = sql.110）.aspx＃制限）;
• 列ストアインデックスもRAMを非常に要求します。つまり、列がRAM全体に収まらない場合、メリットはありません。

しかし、もちろん、この決定には肯定的な側面があります。

• ColumnstoreインデックスフィールドによるSELECTは、行ベースの選択よりも約10倍高速です。
• 同じことが* JOINにも言えます。

「それだけですか？」とあなたは尋ねます。 はい、それだけです。 最も人気のある2つのデータベースクエリでは、約10倍のゲインしか得られません。 その後、建築家の仕事を開始して、ベースをまともな外観にします。 それらの一部は、頻繁に変更されるものとしてRowbasedに残し、その他は静的としてColumnstoreに部分的に変換します。



または、より創造的にアプローチします。 たとえば、Rowbasedに格納されている未処理の注文があり、処理された注文のグローバルアーカイブが先月のテーブルに作成する場合、DROP COLUMNSTORE INDEX、INSERT DATA INTO MONTH、CREATE COLUMNSTORE INDEXがあります。 そして、両方のテーブルをすばやくチェックして、作業中のデータベースから共通の行を削除し、全員が幸せに暮らします。



別のオプション。 本質的に均一な着信テレメトリデータがあります。 たとえば、1時間または1日など、特定の期間のデータが収集されるテーブルがあります。 次に、スケジュールに従って理解可能な名前20120229のこのテーブルは、円柱ビューに変換され、データは20120301ですでに流れ始めます。その結果、情報はきちんと折り畳まれ、圧縮され、必要に応じてオンラインで読むことができます。

おわりに

記事の冒頭で述べたように、ここでは読み取り操作のゲインのみが表示されます。 読み取り操作をセカンダリサーバーに委任することで書き込みサーバーをアンロードできるため、書き込み操作は高可用性グループの一部としてのみ勝ちます。 一般的に、この機能は非常に便利です。 神経とリソースを節約し、生産性を向上させます。 通常、この機能にはマイナス記号を付けて5つを安全に配置できます。 復旧モデルの要件のマイナス。



列化された書き込みインデックスの場合、正味損失が発生します。このようなテーブルにデータを入力することはできませんが、そこからすばやく読み取ることができます。 これにより、この機能の使用に特定の制限が課せられます。 それはアメリカのドラッグスターのようなものです：速度は速いですが、直線で水平なトラックに沿っているだけで、RAMにも制限があるので、それほど長くかかりません。



一般的に、リリース候補者は良い印象を残しました。 MS SQL 2012を詐欺なしでエンタープライズレベルの製品と呼ぶことができる機能が登場しました。



evans2094 、

システムエンジニアDEPO Computers