Ich habe eine Sammlung mit 100 Millionen Geometriedokumenten.
Ich habe eine zweite Sammlung mit Zeitdaten, die mit jeder der anderen Geometrien verknüpft sind. Dies werden 365 * 96 * 100 Millionen oder 3,5 Billionen Dokumente sein.
Anstatt die 100 Millionen Einträge (365 * 96) mehr als nötig zu speichern, möchte ich sie in separaten Sammlungen aufbewahren und einen Typ von JOIN / DBRef / Was auch immer ich in MongoDB machen kann.
Zuerst möchte ich eine Liste von GUIDs aus der Geometriesammlung erhalten, indem ich eine geoIntersection verwende. Dadurch wird es auf 100 Millionen bis 5000 gefiltert. Dann verwende ich diese 5000 Geometrien-Guides. Ich möchte die 3,5 Billionen Dokumente basierend auf den 5000 Goemetries und zusätzlichen Datumskriterien, die ich spezifiziere, filtern und die Daten zusammenfassen und den Durchschnitt finden. Ihnen bleiben 5000 Geometrien und 5000 Mittelwerte für die von Ihnen angegebenen Datumskriterien.
Dies ist im Grunde ein JOIN, wie ich es in SQL kenne, ist das in MongoDB möglich und kann es in weniger als 10 Sekunden optimal gemacht werden.
Klären: Wie ich verstehe, ist das, wofür DBrefs verwendet wird, aber ich habe gelesen, dass es überhaupt nicht effizient ist, und mit so vielen Daten umzugehen, dass es nicht gut passt.
Wenn Sie sich mit einer Geometrie und ihrer Zeitreihendaten beschäftigen, ist es sinnvoll, sie im selben Dokument zu speichern. Ein Jahr lang Daten in 15-Minuten-Schritten sind kein Mörder - und Sie wollen definitiv kein Dokument für jeden Eintrag in der Zeitreihe! Da Sie alles, was Sie bearbeiten möchten, als einzelnes Geometriedokument abrufen können, ist das ein großer Gewinn. Beachten Sie, dass Sie damit auch fehlende Daten aufsparen können. Sie können die Daten anders codieren, wenn sie spärlich sind, anstatt sie in ein 35040-Slot-Array zu indexieren.
A $ geoIntersects auf einem großen Stapel von Geometriedaten sind jedoch ein Leistungsproblem. Stellen Sie sicher, dass Sie eine Indizierung auf (wie 2dsphere) haben, um die Dinge zu beschleunigen.
Wenn es irgendeinen Weg gibt, wie Sie zusätzliche Qualifier in die Anfrage einbauen können, die Mitglieder aus der teureren Suche billig eliminieren könnten, könnten Sie Dinge zipper machen. Zum Beispiel wird die Suche Staaten in den USA treffen. Sie könnten die Suche zuerst mit Zustandsgrenzen überschneiden, um die Zustände zu finden, die die Geodaten enthalten, und eine Postleitzahl verwenden, um die Dokumente zu qualifizieren. Das wäre eine sehr schnelle Vorsuche gegen 50 Dokumente. Wenn zuerst festgestellt wurde, dass eine Suchgrenze zwei Zustände erreicht hat und die Geodatensätze ein Zustandsfeld enthielten, wurden einfach 96 Millionen Datensätze (vor dem teureren Geoteil der Abfrage) entfernt. Wenn Sie sich mit kleineren Gitterkoordinaten überschneiden, können Sie sie möglicherweise noch weiter untersuchen, bevor Sie die Geodaten berücksichtigen.
Natürlich bringt das zu weitgehende Overhead. Wenn Sie das System richtig auf die Dichte der 100 Millionen Geometrien abstimmen können, können Sie die Zeiten möglicherweise ziemlich niedrig halten. Aber ohne tatsächlich mit den Besonderheiten des Problems zu arbeiten, ist es schwer zu wissen. So viele Daten erfordern wahrscheinlich einige spezifische Experimente, anstatt sich auf eine allgemeine Lösung zu verlassen.