Pár návrhů:
Jako _id pro tyto objekty byste mohli použít kombinaci adresy URL a data, ke kterému se přistupovalo (alespoň část objektu datetime), protože z toho, co vám mohu říci, plánujete každou adresu URL seškrábat jednou za měsíc.
Příklad:
{
"_id": {
"url": "www.google.com",
"date": ISODate("2013-03-01"),
},
// Other attributes
}
To přináší výkon, jedinečnost a dividendy z dotazů (viz tento blogový příspěvek 4sq ). Mohli byste se dotazovat takto:
db.collection.find({
"_id": {
"$gte": {
"url": yourUrl,
"date": rangeStart
},
"$lt": {
"url": yourUrl,
"date": rangeEnd
},
}
})
Což přináší vynikající, pěkně seřazené (podle adresy URL PAK podle data, což se zdá být přesně to, co chcete) výsledky. Tento index můžete také použít k provádění zahrnutých dotazů (přes pole _id), pokud chcete jen pěknou sadu všech adres URL a měsíců, které jste seškrábli (to by vás mohlo pěkně nastavit tak, abyste procházeli každou adresu URL jednu po druhé) .
Pokud máte specifické atributy dokumentu, které chcete porovnat (headers.server
například) a konkrétní srovnání, které pro ně chcete provést (například hledat jakýkoli přírůstek v číslech verzí), použil bych nějaký druh regulárního výrazu k zachycení prvků relevantních pro číslo verze (rychlý a špinavý by mohl jednoduše získat všechny číselné prvky) a vykreslete je do grafu pro každou adresu URL (předpokládám, že by vám to umožnilo vizualizovat změny serverového softwaru v průběhu času). Kdykoli se kterýkoli z těchto atributů změnil, můžete stejně snadno nahlásit tím, že je naskenujete v pořadí a spustíte nějakou událost, kdy řetězce nebudou identické (možná pak nahlásíte změnu nebo číselnou část změny).