Kilka sugestii:
Możesz użyć kombinacji adresu URL i daty, do której uzyskano dostęp (przynajmniej część obiektu datetime) jako identyfikatora tych obiektów, ponieważ z tego, co mogę powiedzieć, planujesz przeszukiwać każdy adres URL raz w miesiącu.
Przykład:
{
"_id": {
"url": "www.google.com",
"date": ISODate("2013-03-01"),
},
// Other attributes
}
Daje to wydajność, unikalność i dywidendę zapytań (patrz ten post na blogu 4sq ). Możesz zapytać, wykonując coś takiego:
db.collection.find({
"_id": {
"$gte": {
"url": yourUrl,
"date": rangeStart
},
"$lt": {
"url": yourUrl,
"date": rangeEnd
},
}
})
Co daje doskonałe, ładnie posortowane (według adresu URL NASTĘPNIE według daty, która wydaje się być tym, czego chcesz) wyniki. Możesz również użyć tego indeksu do wykonywania zapytań objętych zakresem (nad polem _id), jeśli potrzebujesz tylko ładnego zestawu wszystkich adresów URL i miesięcy, które zebrałeś (może to dobrze ustawić, aby przejść przez każdy adres URL pojedynczo) .
Jeśli masz określone atrybuty dokumentu, które chcesz porównać (headers.server
na przykład) i konkretne porównanie, które chcesz dla nich zrobić (na przykład szukając jakiegokolwiek przyrostu numerów wersji), użyłbym jakiegoś wyrażenia regularnego, aby pobrać elementy istotne dla numeru wersji (szybkie i brudne może po prostu pobrać wszystkie elementy numeryczne) i narysuj je dla każdego adresu URL (zakładam, że pozwoli to na wizualizację zmian w oprogramowaniu serwera w czasie). Możesz równie łatwo zgłosić każdą zmianę tych atrybutów, skanując je w kolejności i uruchamiając jakieś zdarzenie, gdy ciągi nie były identyczne (być może wtedy zgłaszając zmianę lub część liczbową zmiany).