Ich arbeite an einem Projekt, bei dem wir regelmäßig große Mengen von E-Mails über IMAP oder POP sammeln, Analysen durchführen (z. B. in Konversationen gruppieren, wichtige Sätze extrahieren usw.) und dann Ansichten über das Web präsentieren an den Endbenutzer.
Die Hauptansicht ist eine Facebook-ähnliche Profilseite für jeden Kontakt der letzten (20 oder so) Konversationen, die jeder von der E-Mail hatte, die wir erfassen.
Für uns ist es wichtig, die Profilseite und die letzten 20 Artikel häufig und schnell abrufen zu können. Möglicherweise fügen wir auch aktuelle E-Mails häufig in diesen Feed ein. Dafür scheinen der Dokumentenspeicher und die kostengünstigen atomaren Schreiboperationen von MongoDB ziemlich attraktiv.
Allerdings haben wir auch eine große Menge an alten E-Mail-Konversationen, auf die nicht häufig zugegriffen wird (da sie nicht in den letzten 20 Nachrichten erscheinen, sehen die Leute sie nur, wenn sie nach ihnen suchen, was relativ selten sein wird). Darüber hinaus wird die Größe dieser Daten im Laufe der Zeit schneller wachsen als im Kontaktspeicher.
Nach dem, was ich gelesen habe, scheint MongoDB mehr oder weniger zu erfordern, dass der gesamte Datensatz im RAM bleibt, und die einzige Möglichkeit, dies zu umgehen, ist die Verwendung von virtuellem Speicher, der einen erheblichen Overhead mit sich bringen kann. Insbesondere, wenn Mongo nicht in der Lage ist, zwischen den flüchtigen Daten (Profile / Feeds) und den nichtflüchtigen Daten (alten E-Mails) zu unterscheiden, könnte dies sehr unangenehm werden (und da es die virtuelle Speicherzuweisung an das Betriebssystem zu übertragen scheint), Ich sehe nicht, wie das für Mongo möglich wäre).
Es scheint, dass die einzige Wahl darin besteht, (a) genügend RAM zu kaufen, um alles zu speichern, was für die flüchtigen Daten gut ist, aber kaum kosteneffizient, um TB von E-Mails zu erfassen, oder (b) virtuellen Speicher zu verwenden und lesen / schreiben auf unseren flüchtigen Daten langsam zu einem Crawling.
Stimmt das, oder fehlt mir etwas? Würde MongoDB gut zu diesem speziellen Problem passen? Wenn ja, wie würde die Konfiguration aussehen?
MongoDB verwendet mmap, um Dokumente in virtuellen Speicher (nicht physischen RAM) zuzuordnen. Mongo benötigt nicht das gesamte Dataset im RAM, aber Sie möchten, dass Ihr 'Arbeitssatz' im Speicher ist (Arbeitssatz sollte eine Teilmenge Ihres gesamten Datasets sein).
Wenn Sie verhindern möchten, dass große Mengen an E-Mails in virtuellen Speicher mapped werden, könnte Ihr Profildokument ein Array von ObjectIds enthalten, die auf die in einer separaten Sammlung gespeicherten E-Mails verweisen.
MongoDB erfordert nicht ", dass der gesamte Datensatz im RAM verbleibt". In Ссылка finden Sie eine Erklärung, warum / wie der virtuelle Speicher so verwendet wird, wie er es tut.
Für diese Anwendung wäre das in Ordnung. Wenn Ihre Sortierung und Filterung komplexer waren, könnten Sie zum Beispiel eine Map-Reduce-Operation verwenden, um eine Sammlung zu erstellen, die "Anzeige bereit" ist, aber für ein einfaches geordnetes Datum funktionieren die vorhandenen Indizes gut.
@Andrew J Normalerweise benötigen Sie genug Arbeitsspeicher, um Ihre Arbeitsmenge zu speichern. Dies gilt sowohl für MongoDB als auch für RDBMS. Wenn Sie die letzten 20 E-Mails für alle Benutzer speichern möchten, ohne auf die Festplatte zu gehen, benötigen Sie so viel Speicherplatz. Wenn dies den Speicher auf einem einzelnen System übersteigt, können Sie die Sharding-Funktion von MongoDB verwenden, um Daten auf mehrere Rechner zu verteilen und somit die Speicher-, CPU- und E / A-Bandbreite der Maschinen im Cluster zu aggregieren.
@mP Mit MongoDB können Sie als Anwendungsentwickler die Dauerhaftigkeit Ihrer Schreibvorgänge angeben, von einem einzelnen Knoten im Speicher bis hin zu mehreren Knoten auf der Festplatte. Die Wahl hängt davon ab, was Ihre Bedürfnisse sind und wie wichtig die Daten sind. Nicht alle Daten werden gleich erstellt. Zusätzlich können Sie in MongoDB 1.8 --dur angeben, das eine Journaldatei für alle Schreibvorgänge schreibt. Dies verbessert die Dauer der Schreibvorgänge weiter und beschleunigt die Wiederherstellung im Falle eines Absturzes.
Tags und Links database mongodb database-design storage data-paging