そのため、少なくとも、通常の「フラット」（「2D」）データを提供するにはデータベースが必要になります。 一部の識別子IDはデータフィールドにマップされます。
データフィールドの1つを検討しているのはなぜですか？ なぜなら：
- 選択はIDフィールドによってのみ行われ、データは検索されません。 これには専用のインデックスがあります-そうでなければ、そのような情報量ではほとんど意味がありません
- 任意の数のフィールドを1つにパッケージ化できます。これにより、「ひざまずく」小さなアプリケーションライブラリのセットを作成しました。特に、CRCデータはパッケージ化中に保存されるため、神は禁止します
データを操作するためのコードの行数を最小限に抑えるタスクと少しの利便性を自分で設定しない場合、ほとんどすべてのタスクをこれらのポイントで十分なものに減らすことができます。 そして、最適性と速度に関するこのような高い要件の場合、私の意見ではこれはかなり正当化されます。
このようなデータベーステーブルの主な操作は次のとおりです。
- ID選択
- データベース全体を順番に（メモリまたはハッシュで）読み取ります
- IDによるレコードの更新
- 最後に新しいものを挿入し、IDを取得します
データをディスクごとにページごとに保存、書き込み、読み取りする「ページタイプ」テーブルを使用するのが最適であることがわかりました。 各ページには一定数のエントリがあります。 固定のレコードサイズを事前に知っていれば非常に簡単です。ただし、レコードサイズが変更されても、テーブルはさらに高速に動作します。基本的に処理に変更はありません。 更新、最後への追加はメモリ内のページ内で行われ、ページはディスクに書き込まれます。 テーブルファイルでは、ページは順番に保存されます。
問題が発生します：サイズが変更されたときにテーブルの中央のレコードを更新する方法-テーブル全体が10-20-200 GBを超える場合、テーブルの半分を一時ファイルにコピーすると、数時間かかりますか？ この質問をファイルシステムに置き、すべてのページをブロックに分割しました。 1ブロック-ディスク上の1ファイル、1テーブル内のファイル数は制限されていません。 各ファイルには、限られた固定数のページが順番に保存されます。 次に、テーブルの中央のレコードを更新する必要がある場合は、はるかに小さく、多くの場合、限られたボリュームの1つのファイルのみを変更する必要があります。 ファイルシステムに何かバカなことをしないように依頼する責任は、最初に最初に、次に最後に、次に最初に再び書くことです。 サーバーに負担をかけないために、私は常にバッチで書き込みます。対応する機能は可能な限り最適化され、すべてがメモリ内で発生します。 もちろん、検索エンジンモジュールのシステム全体は、1000レコードを末尾に書き込む方が先頭に1を書き込むよりも高速であることに基づいて構築されています。したがって、先頭に書き込む場合、テーブルのコピーを作成する方が簡単な場合があります。
OK、通常のテーブルが決定しました。 現在、説明されているデータベースは非常に優れており、特に、検索プロセスで35 GBのテキストを処理し、任意の選択を行います。
しかし、そのようなテーブルに対応を保つための制限があります：各単語について、その単語が見つかったドキュメントのリスト（追加情報と一緒に）は実際には不可能です-各単語に多くのドキュメントがあるため、ボリュームは膨大になります
したがって、そのようなデータベースでどのような操作を行う必要があります：
- 目的の任意の単語のリストの先頭から退屈するまでの連続した選択
- 良いことであれば、その単語のドキュメントのリストを変更する必要がありますが、ここではフェイントを作成できます-データベースの最後にのみ挿入してください
そのようなインデックスを更新する方法は？ 明らかに、インデックスが空で、最初の単語から最後の単語で終わるドキュメントのリストの挿入を開始する場合、ファイルの最後にのみ書き込みます。 さらに、各単語に物理的に別々のブロックを書き込むかどうかは、ディスク上で別々に開発者次第ですが、どちらの場合でも、次のブロックがどこで終了し、その長さを最も単純なリストに保存することを覚えています。 その後、シーケンシャルリーディング手順は次のようになります：目的のワードのリストの先頭にファイルを移動し、次のワードのリストが始まるまでシーケンシャルに読み取ります：1シーク、そして必要な読み取りの最小数は勝利です（ここではファイルシステム自体の操作を特に考慮しません-最適化を個別に処理できます）
さて、明らかに、新しくインデックス付けされたページに関する情報をインデックスに追加する場合、新しい情報を個別に保存し、現在のインデックスを読み取り用に開き、書き込み用に新しいインデックスを作成し、追加する必要がある情報を最初の単語から順番に読み書きすることができますそして最後に終わる。 リストにドキュメントを追加する順序についての質問は、インデックスの作成について話すときに少し後で検討します。
検索エンジンに関する私の記事の全内容とリストはここで更新されます： http : //habrahabr.ru/blogs/search_engines/123671/