ハイロード2012

数日前にモスクワで、「非常に負荷の高いシステムの開発者による会議」 HighLoad ++がありましたが、幸運にも参加できました。 以下に、会議中に訪れたレポートを簡単に見ていきたいと思います。私の意見で興味深い点を強調します。

私はすぐにあなたに警告します、いくつかのことを誤解し、いくつかを誤解する可能性があります。 これがあなたにとって重要な場合-この投稿を読んではいけませんが、次の会議に直接来てください！

1日目

VKontakteコンテンツの保存と配信

レポートは、2年前、PaKo DurovにVKontakteがユーザーデータをどのように保存するかを尋ねたときの話から始まりました。 その日、パシャは「ディスクで」と答えた。 それ以来、私は彼が好きではありません:)今回、オレグ（スピーカー）はこの質問に完全に答えることを約束し、彼にレポート全体を捧げました。

最初は、すべてのファイル（写真）はアップロードフォルダー内のコードと同じサーバーに保存されていました。 このアプローチは単純ですが、セキュリティ（コードインジェクション、XSS）とスケーラビリティという2つの欠陥があります。

さらに、ファイルはメインサーバーにアップロードされてから、補助（ユーザーデータ用に特別に設計された）に転送されるというスキームを組織することにより、スケーラビリティに困惑しました。
各ユーザーは、ユーザーIDで識別される同じ補助サーバーに常に対応しています。
ただし、このアプローチにはボトルネックがあります-メインサーバー。

したがって、次の手順は、アプリケーションでメインサーバーを使用せずに、コンテンツサーバーにファイルを直接アップロードすることでした。 ただし、このアプローチを実装するには、どのサーバーで写真をアップロードするのかという質問に答える必要があります。

• システムに最後に追加されたサーバーに追加します（サーバーはすぐにスペースを使い果たすため、適合しません）。
• 最も空きのあるサーバー（すべてのトラフィックがサーバーにダンプされるため適合しません）;
• ランダムに無料のサーバー（最良）;

ボトルネックを検索して排除します。 通常、ボトルネックは1つです-それと比較して、システム内の残りのノードははるかによく機能します。 大量のユーザーデータを保存するときのボトルネックは次のとおりです。

• データバックアップ（2つのディスクのアレイ全体が燃え尽きる場合、RAIDが使用されます-ユーザーファイルは永久に失われます）;
• キャッシュ（コンテンツの60％がクライアントのキャッシュから取得されます）;
• トラフィック（特にビデオの場合、ソリューションはCDNです。モスクワのVKontakteには、サンクトペテルブルクのデータセンターからのビデオをキャッシュするサーバーがあります）。

使用されるファイルシステムはXFSです。 ただし、ユーザーファイルはファイルシステムではなく、1つの大きなファイルに保存されます。 ファイルは常に読み取り用に開かれ、ファイルインデックスはRAMに保存されます。 物理メディアからの完全な抽象化により、この技術のさらなる発展が見られます。

WiFiが広く普及しているという事実を考慮して、VKontakteはHTTPSに切り替えています。 コンテンツを備えたサーバーは多数あるため、各サーバーの証明書を購入することはできません（高価すぎます）。 したがって、VKontakteには、HTTPSを介してコンテンツをプロキシするサーバーがいくつかあります。

写真はどうですか：

• 合計30,000,000,000を超え、1日あたり17,000,000が追加されます。
• 画像はクライアント側（Flash）で事前に圧縮されています。
• グラフィックマジックを使用します。
• 写真を保存すると、必要なすべての許可のためにすぐにカットされます。

音声について：

• 1日あたり130Kが追加されます。
• ユーザーは、他のページのデータを自分自身に「追加」することができます。これにより、ダウンロードされるオーディオの量が大幅に削減されます。
• 著作権所有者の要求により、ファイルは最初にmd5ハッシュによって検索されました。 現在、いくつかのオーディオ特性によって同様のオーディオレコードを見つけるアルゴリズムが開発されました。

ビデオについて：

• 1日あたり320Kが追加されます。
• キューを介した遅延ビデオ処理が使用されます-ビデオをオンラインで処理するには高すぎます。
• ffmpegはビデオ処理に使用されます。
• 他のユーザーがリロードするとビデオが複製されます-これは問題ではありません。
• かつて、VKontakteにはフラッシュ上のビデオ用のP2Pがありました（wat！？）。

一般的に、私は連絡が比較的簡単であると感じました。 シンプルだが効果的。

高負荷プロジェクトのNoSQL

NoSQLがMambaでどのように使用されているかを報告します。 問題のシステムの機能は、実行されたクエリの30％以上がインクリメントとカウンタの読み取りであることです。

Memcacheを使用して、データに適したストレージの検索を開始しました。 永続性とRAMのみの不足に満足していません。 試したラジアン-RAMのみ。
さらに、負荷が大きい場合、Memcachedのパフォーマンスは100倍低下します（負荷のテストには、Brutisツールが使用されました）。

どれくらいの間、簡潔に、彼らはTokyoTyrantを使うようになりました。 しかし、彼は突然サーバーの電源を切ったときにデータベースの整合性に関する問題を発見しました:)これらはTokyoTyrant-KoytotTycoonの作者による新しい開発によって解決されました。 ただし、アーキテクチャ上の制限により、30Mデータベースに書き込むことはできませんでした。

したがって、彼らはGoogleからLevelDBの方向に進みました。 このデータベースはLSMツリー技術を使用しています。 データはSSTableファイルに格納されます：ソートされた不変のキーと値のペア。
データは、RAM内の同様の（ただし既に変更可能な）構造に書き込まれます。 メモリからディスクへのサブツリーは時々マージされます。
突然の停電の場合に問題をキャッチしないために-先行ログの書き込みが書き込まれます。

彼らはもう一度テストを行い、ほとんどの場合、LevelDBライブラリが以前に使用されたすべてのオプションよりも優れていることを発見しました。 現在、4700 get /秒と1600 update /秒を保持し、データベース内の200Mレコードを保持しています。

マスクされていないMVCC

MultiVersion Concurency Controlは、リーダーが書き込みをブロックせず、リーダーを書き込むことを可能にするメカニズムです。 一般に、データベース内のロックの数を大幅に削減します。 オラクル、Mysql InnoDB、PostgreSQlなどに存在します。

MVCCテーブルの各レコードには2つの属性があります。creaton（xmin）-レコードが作成されたトランザクションの数、expiration（xmax）-レコードが削除されたトランザクションの数。

     INSERT xmin 40、xmax Null
    削除xmin 40、xmax 47 

    更新xmin 64、xmax 78 / xmin 78、xmax NUll

各ステートメントが実行されると、MVCCスナップショットが作成されます。これにより、データベース内のどのデータがステートメントに対して可視/アクセス可能かが決まります。
文字列の可視性を決定するアルゴリズムは次のとおりです。

• 最後に完了したトランザクション（現在）の番号を取得します。
• 以下のレコードが表示されると考えます。
  
  • xmin <現在の数;
  • それらは削除されません（xmax = null）、またはそれらが削除されたトランザクションは公開されません。
  
  

xminおよびxmaxフィールドは各テーブルにありますが、デフォルトでは非表示になっています。 ただし、選択で常に明示的に指定することができます： SELECT xmin、xmax、* FROM test ;

SELECTクエリtxid_current（）を使用して、現在のトランザクションのIDを取得できます。 このクエリは、pg_clogテーブルからデータを選択します。 トランザクションのロールバックは、適切なトークンを設定するだけで、このテーブルにトランザクションを記録することを理解することが重要です。 同時にデータは削除されません。 トランザクションは、単にロールバックされたとマークされます。

非MVCC DBMSでは、レコードを変更または削除するときにデータを直接変更する必要があります。 MVCC DBMSにはこの問題がありません-無関係なデータはすべて遅延して消去されます。
ここで、遅延クリーニング（いわゆるVACUUM）は私たちが望むほど完璧ではないことを自分から付け加えたいと思います...しかし、これは別の議論のトピックです。

ところで、ここに彼が多くの興味深い記事を約束したスピーカーのサイトがあります。

Google上のMySQL

おそらく、レポートの中で最大の失望。 要するに、その本質は1つの論文に要約されます：「はい、MySQLは私たちによって少しパッチされています。」
過剰な要求があるかもしれませんが、Good Corporationにはもっと面白いものを期待していました。

最大のプロジェクト：広告、Checkout、そしてもちろんYouTube。

データセンターでは、最も高価なハードウェアではなく、最も「高度な」ハードウェアが使用されます。 コンポーネント（ディスク）は非常に頻繁に使用できなくなりますが、簡単かつ安価に交換できます。

MySQLはクラスターとして使用されます。 各シャードには、個別のプロセス（決定）があり、古いマスターが落ちた場合に新しいマスターを選択します。
ハートビートは、いくつかのデータをウィザードに書き込み、レプリカ上のその存在をチェックする単純なスクリプトによって実行されます。

スケーリングとフォールトトレランスを整理するために、データベースの操作に多くの制限を設けています。 たとえば、書き込みトランザクションは30秒以上かかることはありません。 別のスレーブからマスターをすばやく作成できるようにする必要があります。

NginXでのSPDYサポート

SPDYは、TCP / TLS接続を介したバイナリプロトコルです。 HTTPのトランスポートです。 Googleによって設計されました。

主な機能：

• 多重化（サーバーからクライアントへ、およびその逆の両方の接続ごとのいくつかの要求）;
• ヘッダー圧縮（zlib、deflate）;
• フロー制御（tcp接続のウィンドウ）;
• サーバープッシュ（サーバーによって開始されたブラウザーへのデータの「ロード」）;

利点：組み込みHTTPS（TLSによる）、多数の写真（多重化による）での良好な動作。
マイナスの点：結果として1つのドメインで動作します-CDNをサポートしません。

調査（戦闘）によると、Wordpress'a：SPDYはHTTPSよりも高速ですが、通常のHTTPよりも低速です。

SQLのトリック

このレポートは興味深いリストですが、すべてのSQL / PostgreSQL機能に精通しているわけではありません。

• ビューは、ロジックやテーブルをカプセル化するための効果的なツールです。 最初のものには同意しませんが、2番目のものを使用します（テーブルの名前を変更します）。
• postgresはOSキャッシュを使用します（したがって、彼らはその一部またはすべてを割り当てることを提案します）。
• pgbench-Postgresをテストするためのユーティリティ。
• 共通テーブル名（CTE）/再帰的CTE;
• ウィンドウ関数;
• JSONサポート（c 9.2）;
• ラテラルサポート（FROM句の現在の行で計算されたデータの使用、c 9.3）;
• テキストとトライグラムを操作するための拡張：pg_trgm;
• キーと値のペアを保存するための拡張機能：hstore;
• dblinkを介して他のデータベースからテーブルを接続します。
• 地理データを操作するための拡張機能：PostGISおよびEarthDistance;
• 準備されたステートメント-要求の解析、存在と権利の確認、計画の構築のオーバーヘッドを回避できます（場合によっては、
  行うよりも多くの時間）;
• ロックは、select ... for shareコンストラクトを使用して明示的に設定できます。
• PgSQLのPrepared Statementには、executeを介してアクセスできます。
• コードブロックは$ code $ ... $ code $（c 9.1）;
• upsertは、insert-> fk constraint-> updateを使用して実装するのが最適です。
• レートを返す（トランザクション内）か、JSONを生成する（row_to_json、array_to_json）ことにより、関数から複数の値を返すことができます。

ところで、スピーカーは本当に危険です。再帰CTEとRegexpを使用して、彼は1つのリクエストの配列でJSONパーサーをPostgresで作成しました！

身をかがめるサーバー、ダイオードを隠す

「こんにちは、私の名前はアンドレイです。私はヴォロネジ牛です。」 レポートのこの説明は完了することができます:)一般的に、Aksyonovはすべての栄光に満ちています。

キーポイント：

• ベンチマークを使用する-目標について覚えておくべき主なこと：負荷平均ではなく、必要なものを測定する必要があります。
• メトリックの平均値は何の意味もありません。病院の平均気温は冷死体と熱性com睡です。
• スケーラビリティは非線形です（アムダールの法則-たとえ5％並列しない場合でも、
  64 * CPU = 14.5 X）
  
  C（n）= n /（1 + a *（n-1）+ b * n *（n-1））、ここで
  
  a-競合の度合い（比類のないコードのコスト）、
  
  b-一貫性の度合い（一貫性、通信、同期のコスト）;
• スイートスポット-パフォーマンスが最適になるリソースの量を強調できます。
• それどころか、スイートスポットの後、生産性が低下し始めます- 成長とともに悪化する可能性があります。
• デフォルト設定でテストしないでください-ほとんどのソフトウェアでは、おおまかに言って奇妙です（MySQlでは各Insert'aおよびinnodb_buffer_poolが32 MBであるため）。
• 同じリクエストを1000回実行します-キャッシュをテストします。

世界の定数-アクションにかかる費用を理解することが重要です。

• CPU L1-1,000,000,000 op /秒（1e9）
• CPU L2、分岐ミス-100,000,000 op /秒（1e8）
• RAMアクセス-10,000,000 op /秒（1e7）
• SSDメガレイド-100,000 op /秒（1e5）
• SSD-10,000 op /秒（1e4）
• LAN、1MB RAM-1,000 op /秒（1e3）
• HDDシーク、1MB LAN-100 op /秒（1e2）
• WAN往復-10 op /秒（1e1）
• Memcachedアクセス-10,000 op /秒（1e4）
• RDB単純選択-100 op /秒（1e2）

言語を行く

はじめに、こんにちは、World in GO。

2日目

検索の仕組み

アンドレイ・アクショノフの朝の冷静さ:)
どの検索エンジンでも、データ収集（スパイダーロボット）、インデックス作成、検索、スケーリングの4つのマイルストーンを区別できます。

索引付けには次が含まれます。

• テキスト（html、pdf->テキスト）の受信、
• トークン化
• 形態学的処理（ステミング、lemotization）、
• 逆索引の作成（キーワード->本のページ番号とその中の単語の位置）;

インデックス内のデータは圧縮する必要があります。 圧縮は、ビット、バイト、ブロックにすることができます。 データが少ないほど、要求に応じて処理する必要が少なくなります。

検索は、2つの直交ステージで構成されます。 迅速なマッチング（検索）と定性的レーキ（ランク）です。
一致基準は、その使用領域（Web、データマイニング）によって異なる場合があります。 ランク付けに関しては、原則として、関連性は各ユーザーの個人的なものであるため、最後に関連することはできません。 したがって、BM25（TF、IDF、DocLength）などのトリッキーなアルゴリズムがランキングに使用され、その結果は可能な限りパーソナライズされます。

スケーリングに関しては、検索にはリソースが必要です。 したがって、Googleには何百万もの検索サーバーがあり、Yandexには何万もの検索サーバーがあります。

オドノクラスニキ検索

彼らは、3,000万人のユーザーで（MsSQlで）フルスキャン検索を使用することができました。 16ベースのクラスターでは、1つの検索クエリが平均15〜30秒で機能しました。
そのように生きることができないことに気づいた私たちは、解決策を探すことにしました。

Javaプロジェクト以来、彼らはLuceneに目を向け始めました。 Luceneとの3年間の作業により、次の変更が行われました。

• レプリケーションを追加しました
• メモリ内のインデックスの保存（RAMドライブで試行し、ヒープ内のファイルをマッピングしましたが、最終的にはByteArray内のファイルをプルしました-OldGeneration内）;
• インデックスによる検索の書き換え（デフォルトでは作成されるオブジェクトが多すぎるため、GCで問題が発生しました）。

現在、別のインデクサーサーバーがインフラストラクチャに割り当てられ、検索インデックスが作成されます。 インデックスは、ディスクとメモリの両方にインデックスを保存するクエリサーバーに複製されます（メモリからのインデックスは、クエリの処理に使用されます）。 インデクサーはキューを介してデータを受信するため、時々アクセスできなくなります。

大きな欠点は、キューをバイパスして、データベースからインデックスを直接更新するためのロジックの欠如でした。 キューからのいくつかのメッセージが時々消えたので。 私は会社で同じ問題を述べることができます。 結論： キューを操作するときの健全性チェックは常にする必要があります 。

常に5％の要求（最も頻繁に要求される）のみがキャッシュにあります。 キャッシュで60％ヒット。
個人的な要求の場合、一時的なキャッシュが（要求に応じて）作成され、数分間存続します。

ポータルの各ユーザーには、個別のアプリサーバーが割り当てられます（userIdに基づいて計算されます）。 サーバーに問題がある場合、ユーザーはリザーブに転送されます。

オンラインユーザーの検索は、最初に一般的なインデックスによって行われ、インデックスの外側の「オンライン」フラグによってフィルタリングされました。 次に、この目的のために別のインデックスを作成しました。

evernoteにデータを保存する

デバイスとEvernote番号に関する概要レポート。

ソフトウェア：Java 6、MySQl 5.1、Debian（安定版）、DRBD（分散ストレージシステム）、Xen。
ハードウェア：SuperMicro 1U、2x L5630 COU、96 GB RAM、6x 300GB Intel SSD、LSI RAID 5（+スペア）〜8000ドル。

データベース：MySQL、10TB（ピーク時のriops 350、ピーク時のwiops 50）
検索エンジン：Lucene（ピークriops 800、ピークwiops 50）

サーバーは米国と中国にあります（Linuxサーバー400台）。

ファイルへのアクセスは、Apache / WebDAVを介して制御されます。 データは常に同じホストに保存され、転送されません。 NFSと比較して、WebDavにはわずかなオーバーヘッドがありますが、展開とサポートが何倍も簡単で安価です。

負荷分散は、SSL Iron Balancerを備えたA10で使用されます（HTTPSは外部から見ていますが、HTTPは内部でプロキシされています）。

サービスの機能（多くの小さなファイルの保存）を考慮して、問題とその重大度を次の表で説明できます。

/	サイズ	通常の負荷	ピーク負荷
帯域幅	-	中	中
遅刻	-	低い	低い
CPU	-	低い	中
ファイルサイズ	高い	低い	中
メタデータ	低い	中	低い

著者は、アプリケーションがリソースを大量に消費する場合（帯域幅、ストレージ、CPU）、または可変量で使用する場合、クラウドプラットフォームの使用を推奨しません。
疑わしい場合は、アプリケーションのニーズに合わせてサーバーを購入してサポートするのにかかる費用と、Amazonにかかる費用を検討してください。 Evernoteの場合、差は1〜4桁です。

DDOSの仕組み

私は夕食を食べていたので、この報告書をほぼ完全に見落としました:)最後の部分から、私はこれらの2、3の論文だけを分離することができました。

HTTP攻撃に対する最も簡単な保護は、Nginxの制限ゾーンです。 NGINXモジュール「testcookie」にも注意を払うことができます。

ただし、NginxはDDOS攻撃の治療法ではないことを理解することが重要です。

ロシア2012年のDDOS攻撃

合計で、2012年の攻撃は2600以上でした（昨年は1700以上でした）。

3,000台の車のボットネットは、平均的なサイトをあふれさせるのに十分です。 最大のボットネットは15万台のマシンで構成されていました。 ほとんどのボンネットは、ドイツ、アメリカ、ウクライナ、カザフスタンに住んでいます（降順）。

DDOSアクティビティはeコマースアクティビティと同じです（まあ、ちょっとした政治）。
政治的DDOSは、インドのパキスタン（法執行機関が届かない場所）のボットネットを使用しています。

ほとんどの攻撃は1GB未満のトラフィックを生成します（通常のサイト帯域幅はこれ以上ではありません）。

攻撃する場合、最初に行うことは、ログ（access.log）を分析し、トラフィックナゲットを作成することです（tcpdump -s0 -c1000000 -w attack.dump）。 攻撃のさらなる中和：ジャンクトラフィックから削除し、攻撃が発生したIPアドレスをブロックし、IPを変更します。

サイトのパフォーマンスには少なくとも2倍のマージンが必要です。

ロシアDDOSの機能-フルブラウザースタック（すべてのアンチddosテストに合格できる実際のブラウザーを使用）。

まあ、はい-問題が発生する場合は、Qratorにお問い合わせください。

2012年のスケーリング

ほとんどの場合、レポートは負荷の最適化などについてのものでした。 悲しいかな、私はすべての始まりをトイレで過ごしました:)質問の間に展開されたかなり興味深い議論を考慮してのみ言及することにしました。

スピーカーは、彼のプロジェクトの冗長性とスケーリングの欠如に言及しました。 これにより、最初はかなり予想外の質問が発生しました。サイトのビジネスモデルは何ですか？ 結局のところ、スピーカーのプロジェクトでは、サブスクリプションを使用してサイトの機能へのアクセスに対してユーザーが支払います（6、12、24か月間）。 サイトが置かれるfakapyが1年に2、3回しか発生しないという事実と、サイトのすべてのユーザーが既にその使用に対して支払いをしているという事実を考慮すると、高いフォールトトレランスは非常に高価で複雑で、最も重要なこと-それほど必要ではないこと:)別のことは、プロジェクトの収益化がプロジェクトへの各リクエストに依存していた場合です！

プロアクティブなWebパフォーマンスの最適化

このレポートはTwitterの従業員が読むことになっていたので、個人的にこのレポートを楽しみにしていて、何か面白いことを楽しみにしていました。 しかし、レポートの開始直後、彼は最近Twitterに取り組んでおり、その前はほとんどの時間でWeb最適化に取り組んでいました。 そして、群衆を完全に終わらせるために、彼は素晴らしいツール/ユーティリティ/プロファイラー/ウェブ最適化のためのプラグイン-YSlowについて教えてくれます。

仮想マシン向けの分散されたスケーラブルな高負荷のストレージシステム

概して、このレポートは、Parallelsがチャンク、メタデータサーバー、その他の属性でGoogleFSのバージョンをどのように補完したかを示しています。
（私にとって）特徴的な機能は、まだ高価だが高速なSSDの使用を提案することです。 Googleでは、ポリシーは購入に帰着するようです
安い鉄は、捨てて交換するのは残念ではありません。

仮想化の主な目的は、1つのホストのリソースの共有、効果的なバックアップと展開です。

ディスクをアレイに結合し、SANストレージ仮想マシン間でパーティションを分割するための最適なソリューション。 しかし、それは高価なので、誰もが通常のディスクを使用します。

FSをジャーナリングする場合、データは最初にジャーナルに送られ、次にディスクに送られます。 これは、突然ディスクをオフにした場合にログを再生し、不足しているデータをディスクに追加できるようにするために必要です。

レポートから、PAXOSアルゴリズムについて言及されました。 私たちは議会があるギリシャの島PAXOSを考えます。 議員は議会に座っており、彼らもビジネスマンです。 後者を考慮して、彼らは非常に頻繁に離れているため、国会議員の半数以下が常に議会にいる。 不在者との連絡は、メッセンジャーの助けを借りてのみ可能です。 同時に、議会は常に機能し、法律を採用すべきです。 さらに、すべての議員は常に最新の法律に注意する必要があります。 私が理解する限り、連中はこのアルゴリズムを使用してチャンクサーバーを同期します。

SIGSTOPプロセスを送信することにより、停電をエミュレートできます。 この場合、TCP接続のもう一方の端のアプリケーションは、電源がオフにされたときと同じ状況になります。 これは実際の停電よりも高速です。

仮想Hadoopクラスターの推奨サービス

みんなは、Hadoopを使用してマップ/タスクの「サイト上のサービスの推奨事項」を削減しました。 それらの特定の問題と解決策は例として与えられているので、おそらくここに書くことは何もないでしょう。

MariaDB：新しいMySQL

Maria DBに関する概要レポート。 MySQLのフォークは、MySQLがSunからOracleに移行した後、MySQLの創設者によってゼロから完全に書き直されました。
エンジンとして、PerconaのXtraDBがデフォルトで使用されます。 InnoDBをサポートします。

本質的に、レポートは、Chanhelog MariaDBバージョン5.5に要約されます。

MySQLがどのように成長したか、そして旅で出会った挑戦の個人的な話

Oracleからのレポート。 基本的に、新しいバージョンで何が起こるか。 ロードマップMySQlの一種。

レポートは興味深い質問に答えました。なぜOracleはMySQLをサポートするのですか？ 同社はすべての市場で代理人を務めたいと考えており、MySQLはWeb、モバイル、組み込みをカバーしています。 また、FacebookやTwitterなどのクライアントを失いたくありません。 あなたが言及できない巨大なコミュニティについて。

また、Windows用MySQL Installerには、MsSQL、 Sybaseなどのデータベースからの移行ユーティリティが含まれています。 残念なことに、彼女は付随するすべてのプロジェクトコードを1つに書き換える方法を知りません。 その観点から、私にとっての意味は失われたままです。

正しいインデックスの選び方

インデックスとは何で、何を一緒に食べるのかについてのレポート。 レポートにはかなりの数の機器と例が含まれていたので、この問題に興味がある人は誰でもプレゼンテーションを見ることをお勧めします。

私の意見では、次の点が最も価値があります。

• 挿入速度が低下し、一般にオーバーヘッドが伴うため、あまり多くのインデックスを作成する必要はありません。
  必要です;
• 必要なデータのみを選択します。ネットワーク経由で送信されるデータが少なくなり、プロセッサで処理されるデータが少なくなります。
• ソートは非常に高価な操作です。
• distinct-サンプリングの結果に対して機能するため、操作が非常に遅くなります。
• インデックス（a、b）は、インデックス（a）よりも同等の操作でのみ優れています。
• クラスタリングインデックスにはすべての行データが含まれます（明らかに、クラスター化インデックスの構築時に、テーブル内のデータがインデックスに従ってソートされることが暗示されました）。
• 列がインデックスにないが、選択に使用されている場合は、テーブルからフェッチする必要があります。

プレゼンテーション

すべてのプレゼンテーションは SlideShareで利用できます 。

PS

キエフ駅近くのMUMUカフェのWiFiは地元のOlivierほど良くないので、写真なしで投稿します。