16mbサイズを超えるドキュメントのMongoDB回避策？

この問題を修正するには、データ構造に小さな修正を加える必要があります。その音からすると、ドキュメントが16 MBの制限を超えるには、センサーデータを1つのドキュメントのアレイに埋め込む必要があります。

ここでGridFSを使用することはお勧めしません。これが最善の解決策であるとは思いません。その理由は、ここにあります。

センサーの読み取り値を基本的に個別のドキュメントに分割し、この問題を解決する、バケット化と呼ばれる手法があります。

仕組みは次のとおりです：

次のような特定のセンサーの読み取り値が埋め込まれたドキュメントがあるとします。

{
    _id : ObjectId("xxx"),
    sensor : "SensorName1",
    readings : [
        { date : ISODate("..."), reading : "xxx" },
        { date : ISODate("..."), reading : "xxx" },
        { date : ISODate("..."), reading : "xxx" }
    ]
}

上記の構造では、すでに大きな欠陥があり、読み取り値の配列が指数関数的に大きくなり、16MBのドキュメント制限を超える可能性があります。

したがって、私たちにできることは、構造を少し変更して次のようにし、countプロパティを含めることです。

{
    _id : ObjectId("xxx"),
    sensor : "SensorName1",
    readings : [
        { date : ISODate("..."), reading : "xxx" },
        { date : ISODate("..."), reading : "xxx" },
        { date : ISODate("..."), reading : "xxx" }
    ],
    count : 3
}

この背後にある考え方は、読み取り値を埋め込み配列に$ pushすると、実行されるプッシュごとにカウント変数をインクリメント（$ inc）することです。また、この更新（プッシュ）操作を実行するときは、この「カウント」プロパティにフィルターを含めます。これは次のようになります。

{ count : { $lt : 500} }

次に、「upsert」を「true」に設定できるように更新オプションを設定します。

db.sensorReadings.update(
    { name: "SensorName1", count { $lt : 500} },
    {
        //Your update. $push your reading and $inc your count
        $push: { readings: [ReadingDocumentToPush] }, 
        $inc: { count: 1 }
    },
    { upsert: true }
)

MongoDb UpdateとUpsertオプションの詳細については、こちらをご覧ください：

MongoDBアップデートドキュメント

何が起こるかというと、フィルター条件が満たされない場合（つまり、このセンサーの既存のドキュメントがない場合、またはカウントが500以上の場合-アイテムがプッシュされるたびにインクリメントするため）、新しいドキュメントが作成され、読み取り値がこの新しいドキュメントに埋め込まれます。したがって、これを適切に行うと、16MBの制限に達することはありません。

これで、特定のセンサーの読み取り値についてデータベースにクエリを実行すると、そのセンサーの複数のドキュメントが返される場合があります（すべての読み取り値が含まれる1つだけではなく）。たとえば、読み取り値が10,000の場合、20のドキュメントが返されます。、それぞれ500回の読み取り値があります。

次に、集計パイプラインと$ unwindを使用して、読み取り値を独自の個別のドキュメントであるかのようにフィルタリングできます。

くつろぎの詳細については、こちらをご覧ください。非常に便利です

MongoDB Unwind

これがお役に立てば幸いです。