mySQLのFalconエンジンの概要

2008年6月中旬にジムスターキー（当時Falconエンジンに取り組んでいたチームの責任者） がプロジェクトを去ったという事実にもかかわらず、mySQLの将来のバージョンでこのエンジンを使用する非常に漠然とした見通しについて、開発者が望むものを共有したいと思います実装する。



そのため、Falconの機能の一部（以下、無料翻訳）：

• スピンロックの欠如。 Falconはスピンロックを使用しません。 リソースが使用できない場合、オペレーティングシステムを強制的にスタンバイモードに移行させる独自のロックメカニズムを使用します。 これが何につながるかを見てみましょうが、複数のプロセッサがサポートされているOSの条件下では、いくつかの種類のロックに対して、複数の競合が発生する可能性がある場合、スピンロックを使用する必要があります。 現在、いくつかのラップトップにも複数のプロセッサがインストールされているため、スピンロックが1つのCPUのCPU時間を無駄に使用している状況を実用的なメリットなしに忘れることができます。 同時に、スピンロックは賢明に使用する必要があります。
  
  
• 文字列をキャッシュします。 Falconでは、テーブルの個々の行をキャッシュできるため、 これは、同じ量のRAMでより多くのデータを保存できることを意味します。 8〜16 KBのページから1行だけをキャッシュする必要がある場合がありますが、ページレベルでキャッシュすると、ページ全体を保存する必要があります。 つまり、それぞれが新しいページにある1000個の100バイト行をキャッシュにキャッシュする必要がある場合、Falconでは8〜16 MBではなく100 KBを割り当てるだけで済みます。 実際には、ページキャッシングを最適化できる特別な手法があります。そのため、実際にはゲインはわずかに少なくなります。
  
  
• 固定キャッシュボリュームの代わりに、範囲。 曖昧なことに加えて、マイナーチェンジ。 Vryatでは、Falconは固定値ではなく、キャッシュに割り当てられたメモリ量の最小または最大制限を使用していることがわかります。 8 GBのRAMがあり、キャッシュに4 GBを割り当てることにした場合、mySQLがこれらのギガバイトをどのように管理するかを気にしますか？ この場合、キャッシングが可能な限り効率的になるように、3 GBまたは3.8 GBの範囲を設定する必要がありますか？ 違いは何ですか？ 最小値と最大値を互いに近くに設定すると、メモリクリーニングが頻繁に開始されなくなりますか？ この件に関するドキュメントには具体的な説明はありません。
  
  
• 少数の設定。 おそらくこれは前の段落とは多少相反するものですが、平均的なユーザーではなく、実験者の観点から見てみましょう。 データベースの動作を自分のニーズに合わせてカスタマイズするための設定を増やしたいです。 私は「管理を必要としない」という原則が大好きで、データベースが私のためにあらゆることをしてくれることを望みますが、まず、それが私よりもうまくいくことを証明する必要があります。そして私が自分の手で自分で作ったもの。 これまで、すべてのサーバー負荷モードに適した自動構成を見たことはありません。「標準」モードでは問題なく実行できますが、mySQLで頻繁に発生する非標準モードで作業する場合は効果がありません。
  
  
• 小さなインデックス。 スペースをほとんど占有しないインデックスは優れています。 一方、巨大なインデックスは、InnoDBの高いパフォーマンスの鍵です。 したがって、実際には、インデックスがどの程度「小さくなる」か、システムパフォーマンスがどれだけ低下するか（またはどれだけ利益が得られるか）を確認する必要があります。 Falconをテストしたリリースでは、SHOW TABLE STATUSコマンドはインデックスのサイズを表示しないため、このイノベーションを評価することは困難です。
  
  
• USING INDEXコマンドがありません。 Falconは、選択がインデックスに含まれるデータのみを取得する場合でも、行のコンテンツを常に表示するように強制されます。 これは大きな問題だと思います 「インデックスのカバー」（インデックスのカバー）により、多くのクエリのパフォーマンスが大幅に向上します。
  
  
• データの整然とした読み取り。 インデックスパスに従ってデータを読み取る他のエンジンとは対照的に、Falconは最初にインデックス全体を（おそらくインデックスを組み合わせて）処理し、その後に順序付けられたデータを読み取ることで、このプロセスを最適化できます。 これは、テーブルから大量のデータを選択する必要がある場合に非常に役立ちます。 ただし、このような可能性はmySQLエンジンのレベル（ストレージエンジンレベル）よりも高くする必要があると考えています。ほとんどのタイプのエンジン、そして確かにMyISAMとInnoDBに物理的な場所の順序で行を読み込むことができます。 そのような計画はしばらく前に聞こえたのを覚えていますが、この方向で何かが行われているかどうかはわかりません。
  
  
• インデックスクラスタリングのサポートの欠如。 InnoDBとは異なり、Falconはプライマリインデックスまたはその他のインデックスによってデータをグループ化しません。 場合によっては、これは良いこともあれば、悪い場合もあります。 多くの既存のアプリケーションはInnoDBのこの機能に依存しているため、この機能は新しいエンジンのマイナス面になりやすいです。 私の意見では、この機能はオプションにする必要があります（たとえば、InnoDBで既に実行されているため、非表示の主キーを作成できます）が、この機能は移植性が低くなります。 主キーなどを削除する必要があります。 一部のプレゼンテーションでは、Falconはクラスタリングのインデックスを作成する必要がないと主張しています。 それらを読むときに特別な最適化を使用します。 ただし、そうではありません。 InnoDBの主キーの小さい部分を読み取る必要がある場合、mySQLは数ページのみを参照しますが、Falcon（行が異なる時間に追加され、インデックスによって「分散」される場合）は、さらに多くのページを読み取る必要があります。 たとえば、InnoDBでのクラスタリングの典型的なケースを考えてみてください-クラスター化されたキー（user_id、message_id）を持つテーブル内のユーザーメールボックス。
  
  
• 行圧縮 Falconは、行単位での高速データ圧縮のためのメカニズムを実装しています。 たとえば、整数値に必要なだけのバイト数を使用し（最大値に割り当てられているバイト数ではなく）、デフォルト値と等しい場合は列に値を保存しません。 これは大きな革新ですが、いくつかの困難を引き起こす可能性があります：たとえば、列のデフォルト値を変更する場合、Falconはメタデータを変更するだけでなく、テーブル全体を再構築する必要があります（ただし、この機能も実装されていません） mySQLで）。 InnoDBに実装された透過的なgzip圧縮と比較したFalconのパフォーマンスと圧縮の比率を見るのは非常に興味深いでしょう。
  
  
• データベースレベルのテーブルスペース。 現在のリリースで気づいたかもしれませんが、Falconはデータベースごとに個別のテーブルスペースと独自のログを作成します。 テーブルごとに個別のディレクトリを作成する標準のmySQLアプローチでは、これにより特定の困難が生じる可能性があります：トランザクションが複数のデータベースを生成する場合、コミットされたとき（つまり、コミットされたとき）、いくつかのログを更新する必要があります。 さらに、複数のデータベースのトランザクション固定を同期するには、 XAトランザクション （非常にリソースを消費する）を使用する必要があります。または、あるデータベースでトランザクションがコミットされたが別のデータベースではコミットされない場合があります。 別の問題は、サーバーのシーケンシャル「スナップショット」がデータベース内でのみシーケンシャルになるため、データベースAにアクセスし、少し後にデータベースBにアクセスするトランザクションを開始すると、データベースBに次の行が表示されることです。トランザクションの開始後に追加/更新されました。
  
  
• 分離モード。 Falconは現在、非常に限られたクエリ分離セットをサポートしています（SELECT FOR UPDATEクエリをサポートしていません）。 Falconエンジンは、競合アクセスのあるOptimisticロックモデルを使用します。これにより、ロックが行レベルで解放されるまで待たなければならない多数のUPDATEクエリがあるサーバーの状態で問題が発生する可能性があります。 さらに、トランザクションがUPDATEクエリで完了するのをエンジンが待機しているときに、「エラー1020（HY000）：テーブル 't'で最後に読み取られてからレコードが変更されました」（「レコードはテーブルの最後の読み取り以降に変更されました "）。 これは、エンジンのこの動作がInnoDBの場合よりも悪いということではなく、異なるため、Falconに基づいてアプリケーションを開発するときに考慮しなければなりません。 この問題に関するドキュメントも十分ではありません。
  
  
• ページへの部分的な書き込みに対する保護はありません。 これは、このページのエントリがアトミックでない場合、つまり ページの一部が変更された場合、ページの別の部分が古いままであると、テーブルが修復不可能なほど損傷する可能性があります。 InnoDBが二重書き込みバッファーを使用するのはこのためです（ 注：InnoDBは最初にそれらをテーブル領域の隣接セクションに書き込んでからファイルにページを書き込みます。したがって、リカバリ中の障害の後、InnoDBは隣接セクションのデータのコピーを見つけることができます ）。 ジムはこれを重大な問題とは考えていませんが、二重書き込みバッファーを導入する前にInnoDBエンジンを使用するときに何度も遭遇しました。 PostgreSQLとOracleの開発者と話したところ、私は彼ら全員がこの問題を認識しており、独自の対処方法を持っているという結論に達しました。そのため、Jimがそれをあまり信じない理由がわかりません。
  
  
• ディスク上のデータは、トランザクションがコミットされた後にのみ変更されます。 InnoDBエンジンは、そのようなコマンドが発行された直後にファイル内のデータを変更します。一方、Falconは、コミット後にのみ変更します。 この瞬間には、プラスの側面（たとえば、大規模なトランザクションの長いロールバックがないこと）とマイナスの側面（RAM量の要件の増加）の両方があります。 ほとんどのトランザクションは小さいことに同意しますが、たとえば何かをバッチ処理する場合は、メモリの量を増やすか、トランザクションをより頻繁にコミットするようにリクエストを書き換える必要があります。
  
  
• タイプBLOBのデータを使用した作業の最適化。 JimはBLOBを自分の子供として愛しているため、FalconはBLOBを扱うように最適化されています。たとえば、データベースへのBLOBの直接書き込みが実装されています。 この最適化の結果を実際に見るのは面白いでしょう。
  
  

ドキュメントで情報が見つからなかったもう1つの興味深い点は、断片化処理です。行を更新するとどうなりますか-更新された行は同じ場所に保存されますか、それとも新しい行に保存されますか？ MyISAMの場合のように、行はいくつかの部分に分割されていますか、それとも常にコンパクトに格納されていますか？ これらは、エンジンのI / Oパフォーマンスに関する非常に重要な質問です。



PS翻訳者からのPS：現在、エンジンは4年以上開発されており、ベータ版はまだ粗末なため、Falconは「祖父母」InnoDBだけでなくMyISAMに対してもほとんどすべてのテストを失います。 同時に、Mariaエンジンは非常に高速に開発されています（このエンジンはInnoDBではなくMyISAMの開発であり、完全にトランザクション型であり、すべてのACIDプロパティを備えています）。機会。