2000P's Blog

最初のページ

ディスクシークは悪ですので、それらを避けましょう。4

著者 pinger 時間 2020-04-16
all

前の記事からのテーマで続けて、MySQL操作からすべてのディスクシークを取り除くことができ、したがって2桁のスピードアップを得る別のケースを調べたいです。これらの投稿の概要は以下の通りです。

それで、どのpiggyback仕事が重要であるかを見つけることについてのすべてです(重要なパフォーマンスペナルティを支払うのに十分な重要な)、そして、それはそうではありません。

このブログのポストは、最も簡単な操作の一つです:主キーでアドホック挿入。B - treeインデックスとフラクタルツリーインデックスの間で識別された違いは、ディスクが挿入のシークなので、この場合はほとんど見られないかもしれません。しかし、主キーへの挿入の意味は次のようになります。挿入されている主キーが既にテーブルに存在しない場合は、要素を挿入します。

それで、テーブルがあるならば

create foo ( a int , b int , primary key ( a ))

実行します。

foo値に挿入します

テーブルに( 1000 , 1 )を挿入する前に、ストレージエンジンは最初にa = 1000が存在するテーブルの行を参照するかどうかをチェックしなければなりません。もしそうならば、複製キーがあるというエラーを返してください。エラーを返す必要条件は非常に高価です。

ディスクベースのストレージエンジンがキーが存在するかどうかを確認できる唯一の方法は、要素を調べることです。これは、ここでユニークな二次キーに使用されるのと同じ推論です。主キーがアドホックである場合、ルックアップはディスクシークを必要とする。そして、ディスクシークは悪です。

もう一度、B -木はすでに挿入のためにディスクシークを支払います。葉ノードが挿入をするためにメモリになければならないので、ユニークさを確かめることは本質的に無料で来ます。それで、あなたが重複チェックをするかどうかにかかわらず、B -木はディスク探索に苦しみます。

したがって、どのようにユーザーは、フラクタルツリーベースのストレージエンジンで高速パフォーマンスを達成することができます- Bツリーに比べて、それは遅くなるでしょうか?複製がキーであるならば、エラーを返すこの要件を取り除いてください。それはあまりにも高価です。MySQLにはエラーを返す代わりに他のアクションを実行する構文があります。

問題は、これらのコマンドがディスクシークを必要とするpiggyback仕事をすることですか?彼らがするならば、パフォーマンスはどんなディスクベースの記憶装置エンジンのためにも遅くなります。そうでなければ、フラクタルツリーデータ構造は最大2桁までの高速化を達成する。来週のポストでは、これらのケースを調べます。