2017-09-25 7 views
0

質問を重複して記載する前に全文をお読みください。MyISAM/InnoDBは、効率的な方法で特定のテキストをファイルから削除しますか?

私は、Cのファイルから特定のテキストを削除する方法が1つしかないことを知っています。削除するテキスト以外のファイル全体を書き換えることです。ファイルがある場合、この方法はあまり効率的ではありません数千または数百万の行のテキストが含まれています。 MyISAMは数百万のレコードに使用され、C言語で作成されるため、効率的に作られなければならないので、ファイル全体を再度書き直すことなくどのようにしてこれを達成しますか?私は、MyISAMの開発者が特定のテキストをファイルから削除して、再度書き直すことなくテクニックを尋ねています。

+1

重複して表示されていませんが、代わりに「広すぎます」と表示されます。 ( –

+0

@MartinJamesで簡単に説明できます。ファイルの書き換えの問題を克服するために開発者が使用した解決策を求めています。 –

+0

@MartinJamesと同意します。 MySQLエンジンは何年もの間、多くの開発者の影響を受けています(マージン:何年にもわたって人によって掛け算されます - 「開発者の英語」での表現方法 - 私は英語ではありません) –

答えて

1

DOSの場合と同じように、「削除済み」ではなく「削除済み」とマークされているため、後続のすべての操作で削除された問題はなくなっているようです。

のMyISAM:

  • マーク、それは「削除」されていることを示すために、レコードの最初のバイト。
  • 各インデックスから適切なエントリを削除します。

のInnoDB:

  • ゴー(PRIMARY KEYによって索引付けデータB木で、)ブロックには、削除する行が含まれています。それを削除済みとしてマークします。
  • 後でROLLBACKが行を復活させる場合には、やり直し/元に戻すログインを追加します。
  • 変更されたルックアップで行が見つからないように、変更バッファにエントリを追加します。
  • 最終的に、実際のインデックスに変更バッファエントリをフラッシュします。
  • 最終的にブロックからデータレコードをクリアします。

いずれのエンジンでも、行を削除するためには、ほんの少しのIOP(BTreeドリルダウン、読み取り、書き込み、ログ)があります。 IOPの実際の数は、この削除を表の他の操作と組み合わせることにより、キャッシュに依存します。

MyISAMのデータはストリームファイルです。コードは1つのレコードの読み込みまたは書き込みを「シーク」します。

MyISAMのインデックスはBTreeで、 "key_buffer"(1KBブロック)にキャッシュされます。 InnoDBのデータとインデックスはBTreeで、 "buffer_pool"(16KBブロック)にキャッシュされます。すべての操作は1ブロックのシーク+リード/ライトです。

InnoDBのやり直し/元に戻すログは、私が思うに、ストリーミングされています。

InnoDBの「ダブルライト」バッファは、重複して書き込まれたブロックです。これは停電時にブロックが半分になる「破れたページ」に対するACID保護です。ほとんどのディスクの操作単位は512バイトの「セクタ」です。 MyISAM/InnoDBのユニットはいくつかあります。

長期的に

削除のレコードがのみマークされているのであれば、今までに回復しディスクスペースですか? RAMは単にキャッシュとして使用されるので、私は "メモリ" RAM上のディスクスペースを強調します。

まあ、それは異なります。データを削除して挿入すると、で解放された領域はINSERTで利用可能になります。しかし、レコードが配置される方法のために、INSERTは、最近解放されたスペースをDELETEで再利用することができます。しかし、長期的には、挿入物は削除によって残された「穴」を埋めるでしょう。しかし...

BTreesは本質的に小さな問題があります。各ノードは固定サイズのブロックです。いくつかの削除を実行すると、固定サイズは縮小されません。余りにも多くの挿入を行った後、ブロックは2つのブロック(同じ固定サイズのブロック)に「分割」されます。それでも、時間がたつにつれて、BTreeは満員になるでしょう。つまり、69個のフルブロックから始まるものは、同じ数のレコードを含んだまま、約100ブロックの定常状態に達します(大量の解凍後)。

したがって、テーブルは成長しますが、縮小することはありません。しかし、その成長は実際のデータサイズの数倍に制限されています。 ...

MyISAMとInnoDBの両方で、「最適化」して無駄なスペースをオペレーティングシステムに返す自動方法があります。ただし、これを行うSQL文があります。しかし、それを使用しないでください。努力する価値はありません。新しいテーブルが作成され、すべてのデータがコピーされ、インデックスが再構築され、元のテーブルに戻されます。たくさんの努力。ほとんど利点はありません。

もう1つの事柄... 2つの「隣接する」BTreeブロックの半分が満たされていない場合、ブロックは結合されます。 (これにより、特定のテーブルでブロックを再利用できるようになりますが、OSに戻すことはできません)。

「大企業」とは何ですか?答え:「何もない」私はそのように働いていたので、私は経験から話すことができます。 100台のシステムで10,000台のテーブルでは、私は 2つのケースで最適化を行う価値があると特定しました。唯一の毎月。 MyISAMではなく、InnoDBです。今日はMyISAMを使用すべきではありません。

+0

つまり、データは実際には削除されませんが、削除されたとマークされ、読み込みからスキップされます。その場合、メモリは解放されず、これらのストレージエンジンの短所の1つになり、長期的にはメモリを解放するためにファイルを書き直す必要があります。私は正しいですか、これは長い間一度書き直していますか?GoogleやFacebookのような大企業では本当に起こりますか? –

+1

@ChaitanyaVaishampayan - あなたのコメントに長い回答を追加しました –

関連する問題