2

私はmongodbが初めてです。ローカル サーバーとリモート サーバーがあります。mongodump/ツールを使用してmongoデータベースをローカルサーバーからリモートサーバーに移行した後、リモートサーバーmongorestoreでデータベースのサイズが大きくなることがわかりました。

ここに私のサンプルがあります:

ローカルサーバー (Ubuntu 14.04.2 LTS、mongo 3.0.5):

> show dbs
Daily_data      7.9501953125GB
Monthly_data    0.453125GB
Weekly_data     1.953125GB

リモートサーバー (CentOS 6.7、mongo 2.4.3):

> show dbs
Daily_data      9.94921875GB
Monthly_data    0.953125GB
Weekly_data     3.9521484375GB

比較する 1 つのコレクションのステータスも確認しました。カウントは同じですが、サイズ ( indexSize、totalIndexSizeなど) が変更されています。

これは、ローカル サーバーでの収集のステータスです。

> db.original_prices.stats()
{
    "ns" : "Daily_data.original_prices",
    "count" : 9430984,
    "size" : 2263436160,
    "avgObjSize" : 240,
    "numExtents" : 21,
    "storageSize" : 2897301504,
    "lastExtentSize" : 756662272,
    "paddingFactor" : 1,
    "paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. It remains hard coded to 1.0 for compatibility only.",
    "userFlags" : 1,
    "capped" : false,
    "nindexes" : 2,
    "indexDetails" : {

    },
    "totalIndexSize" : 627777808,
    "indexSizes" : {
        "_id_" : 275498496,
        "symbol_1_dateTime_1" : 352279312
    },
    "ok" : 1
}

これは、リモート サーバーでの収集のステータスです。

> db.original_prices.stats()
{
    "ns" : "Daily_data.original_prices",
    "count" : 9430984,
    "size" : 1810748976,
    "avgObjSize" : 192.00000508960676,
    "storageSize" : 2370023424,
    "numExtents" : 19,
    "nindexes" : 2,
    "lastExtentSize" : 622702592,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 639804704,
    "indexSizes" : {
        "_id_" : 305994976,
        "symbol_1_dateTime_1" : 333809728
    },
    "ok" : 1
}

mongodump/ mongorestoremongo データベースを移行するための適切な保存方法は?

4

2 に答える 2

3

ここですでに気づいているように、ここでの問題は、ここで成長したのは indexSize であることが明確に示されているインデックスであり、完全に論理的な説明があります。

復元を実行すると、インデックスが再構築されますが、復元操作で発生する他の書き込み操作をブロックしないようにします。これは、ドキュメントで説明されているバックグラウンドでのインデックスの構築で採用されているプロセスと似ていますが、まったく同じではありませんが、近いものです。

最適なインデックス サイズを取得するには、最初にターゲット データベースからインデックスを削除--noIndexRestoreし、コマンドでオプションを使用することをお勧めしmongorestoreます。これにより、データのロード中にインデックスが作成されなくなります。

次に、完了したらcreateIndex、「バックグラウンド」オプションの使用を除外して通常の実行を実行できるため、インデックスがフォアグラウンドで作成されます。その結果、インデックスの作成中にデータベースの読み取りと書き込みがブロックされますが、結果のインデックスのサイズは小さくなります。

一般的な方法としては、「再構築」の過程で他のデータ サイズが実際には「小さく」なり、データが復元されたときにソースに存在するスラック スペースが作成されないことに注意してください。

からのデータはバイナリ形式であり、もちろん 1 つの MongoDB インスタンスからデータを取得して別のインスタンスで使用する場合は、および relatedmongodumpのテキスト形式よりも常に優先して使用する必要があります。これは、これらのツールの目的ではないためです。mongoexportmongoimport

他の代替手段は、LVM スナップショットなどのファイル システム コピーです。これはもちろん、バックアップ コピーが作成されたときとまったく同じ状態で復元されます。

于 2015-09-19T08:15:53.387 に答える
1

コレクションのディスク サイズに影響を与える要因には、基盤となるハードウェア、ファイル システム、および構成が含まれます。あなたの場合、一般的な要因は、ローカル サーバーとリモート サーバーで使用されるストレージ エンジンの違いにあるようです。ローカル サーバーは Mongo 3.0 を実行していますが、リモート サーバーは古いバージョンを実行しています。これはプロパティの存在に基づいて明らかですが、両方の環境でpaddingFactorNote実行することで確認できます。db.version()

Mongo 2.4/2.6 と Mongo 3.0 の間で、コレクションの保存方法にいくつかの重要な変更がありました。特に、デフォルトの mmapv1 ストレージ エンジンの代替として WiredTiger ストレージ エンジンが追加されました。ドキュメントサイズの増加に対応するために、割り当て中にドキュメントをパディングする方法にも変更がありました。

サイズの違いのもう 1 つの主な理由は、mongorestore. 通常の使用では、mongo データベースはディスク使用量を最小限に抑える方法で保存されません。ただし、データベース/コレクションをコンパクトな方法で再構築します。これが、投稿したコレクションのリモートが小さいmongorestore理由です。storageSize

于 2015-09-19T08:15:40.773 に答える