記事から記事へとジャンプすると、「一括読み込み」という表現が随所に見られます。
それは本当に(技術的に)どういう意味ですか?
それは何を意味しますか?
ユースケースに基づいた説明を歓迎します。
インデックスは通常、一度に1行ずつ挿入するように最適化されています。一度に大量のデータを追加する場合、一度に1行ずつ挿入するのは非効率的です。たとえば、Bツリーの場合、単一のキーを挿入する最適な方法は、空のインデックスに大量のデータを追加する非常に貧弱な方法です。
代わりに、Bツリーで別の戦略を追求します。すべてのデータを事前に並べ替えて、ブロックにグループ化します。次に、ブロックをツリーノードに変換して、新しいBツリーを構築できます。どちらの手法も同じ漸近性能O(n log(n))を持っていますが、バルクロード操作の係数ははるかに小さくなっています。
一括読み込みは、データを(通常はデータベースに)「大きなチャンク」で読み込む方法です。顧客、注文書、または在庫内のアイテムに関する情報を一度に1つずつシステムに入力する場合、一括読み込みでは、これと同じ種類の情報のファイルが取得され、短時間で数百/数千/数百万のレコードが読み込まれます。 。
ある種類のDBMSから別の種類のDBMSに変換する場合、古いDBから新しいDBにすべての情報を入力しないでください。代わりに、古いDBから新しいDBが簡単に読み取れる形式のファイルに情報をダンプしてから、そのデータを新しいDBにインポートします。
それがバルクローディングに伴うものです(とにかく、35Kフィートレベルで)
バルクロードは、大量のデータをインポート/エクスポートするために使用されます。通常、一括操作はログに記録されず、トランザクションの整合性は期待どおりに機能しない可能性があります。多くの場合、一括操作では、トリガーなどの整合性チェックや制約などがバイパスされます。これにより、大量のデータのパフォーマンスが大幅に向上します。
覚えておくべきことの1つは、一括読み込みはソースからターゲットへのデータコンテンツが同じであることを意味しますが、これはソースシステムが取得されている場合にのみ当てはまります。どのデータソースでも、特に大きなデータの場合、ソースデータは、読み取られてデータ転送が行われた後に変更される可能性があります。従来のオンラインシステムでは、ソースと一致する正確な時点キャプチャが必要な場合、オフラインにするか更新を一時停止する必要があります。