可変長ファイルのデータベースへの書き込み

Question

学習/実験的な目的のために、私はデータベースを勉強して学んだいくつかの技術を模倣しようとしています。そして、私はMySQL（と多分他のデータベース）がこの特定の問題をどのように解決するかについて興味があります。

他のデータベースと同様に、レコードを1つのファイルに並べて保存するアプリケーションを作成しています。私は、レコードの位置を索引付けするために別のファイルを使用して、それらをすばやく検索します。現在のバージョンよりも長い行を更新する必要があるまでは、すべて正常に動作します。私はいくつかのアイデアを持っていますが、パフォーマンスにはやらないものはありません。

たとえば、1,000レコードのうち200レコードを更新したいとします。私のロジックでは、行の先頭にファイルカーソルを置き、データを書き込みます。行の現在のバージョンが100バイト長であるとします（そして101バイト目から次のレコードが始まるとします）。新しいデータの長さは150バイトなので、ファイルカーソルを使用して書き込むだけで、次のレコードのバイトが上書きされます。

私の知る限り、カーソルからファイル内のデータを「プッシュ」することはできません。もし可能であれば、最もパフォーマンスに優しい操作のようには見えません。

新しいデータを追加し、現在の行をNULLバイトで置き換えるオプションがあります。しかし、それは であるように思わa）はNULLバイトせずにファイルを再構築するために、マシンの多くの作業を必要とし、再びスペース B）の廃棄物、

そしてそこデフラグのオプションがありますが、私は準備ができていませんよまだその方向に行く。

他のデータベースがこれをどのように処理しているか誰かが知っていますか？

Answer 1

他のデータベースでは、これをいくつかの方法で処理しています。私はMySQLのために答えることができます。

• ファイル内の一部のスペースに初めてレコードを書き込むときに、少し余分なスペースを残してください。いくつかのレコードが収まる16KBの "ページ"にストレージを編成します。しかし、最初に1/16のスペースを空のままにして、行を広げることができます。要求に応じて各ページがRAMにロードされ、ページがディスクに書き戻される前に、そのページ内のレコードが少し再編成されます。

• レコードがページ内のスペースを超えて拡大すると、分割される可能性があります。一部のレコードは、かなり離れている可能性のある他の新しいページに再配置されることがあります。レコードの場所を追跡する索引付けでは、レコードを隣接させる必要はありません。

• すべてのレコードの再編成と分割によって残った空き領域は、断片化の原因になりますが、全体的にはストレージ全体のわずかな割合になる可能性があるため、心配しません。最終的には、断片化が悪化する可能性があるので、すべてのレコードの新しいコピーを新しいセットのページにし、より効率的に再編成してオリジナルを置き換えることは、時折、良い考えです。どのくらいの頻度でこれを行う必要があるかは、データベースでどのくらいのアクティビティを実行したかによって異なります。したがって、厳密なルールはありません。

• sparse filesまたはhole-punchingと呼ばれる比較的新しい最近の新機能があります。伝統的に、ファイルの連続したバイトはすべて、そのバイトに有益なデータを格納しているかどうかにかかわらず、ディスク上の領域を占有します。しかし、ファイル内の空き領域を空きディスク領域として扱うことができたらどうでしょうか？それでは、断片化については気にしません。これはすべてのファイルシステムでサポートされているわけではなく、一般に "ホール"はファイルシステムのブロックサイズの倍数（例えば4KB）に制限されています。

  MySQL 5。7は、page compressionフィーチャで穴あけを使用しています。 MySQLは依然として16KBのページにデータを格納しますが、ページ内のデータのオプションの圧縮を有効にすることができます。圧縮が4KB（ファイルシステムブロックのサイズ）の隙間を残す場合、圧縮はそれを穴として扱い、ファイルシステムの記憶域を開放します。

その他の多くのトリックが可能です。間もなく、別のデータ更新で元に戻す必要があるため、ストレージをバイトまで最適化しようとする価値はありません。完全なコンパクトなストレージよりも、迅速なアップデートのために最適化する方が良いでしょう。すべては、さまざまなタイプの効率（速度とストレージなど）のトレードオフになります。データベースにとって重要なことについていくつかの決定をする必要があります。