Warum MongoDB besser mit multi-threaded-client im Vergleich zu einer single-threaded-client?

Wir haben vor kurzem ein Benchmark von Oracle 10g und MongoDB mit YCSB ( https://github.com/brianfrankcooper/YCSB/wiki ), als wir versucht haben, erhöhen Sie die Anzahl der threads für 1.000.000 Datensätze, Oracle performance konstant geblieben, nach 4 threads jedoch MongoDB gehalten auf besser und besser, bis zu 8 threads-und danach liest nur besser waren, schreibt und updates (Operationen/sec) konstant blieb.

Liefen wir diesen Maßstab auf 2 CPU Xeon quad-core (insgesamt 8 Kerne) + 8 GB RAM auf LAN.

Was wir beobachtet haben, war, dass MongoDB durchgeführt, die besser mit multi-threaded-client-im Vergleich zu single-threaded-client, meine Frage ist: wenn MongoDB können besser mit mehr laden, warum kann Sie nicht das gleiche tun mit weniger Last (sagen wir nur ein paar threads) durch den Einsatz mehrerer Kerne?

  • keine Ahnung, was Sie wirklich bedeuten...
InformationsquelleAutor vikasing | 2011-07-01
  1. 6

    Es ist logischerweise sehr einfach in der Verarbeitung einer Anfrage auf einem single-core. Nur code, der die Anforderung empfängt, und beschäftigt sich mit ihm.

    Ist es nicht annähernd so einfach zu verarbeiten, eine einzelne Anforderung auf 2 Kernen, da dies erfordert, dass Sie zu brechen, bis Sie die Anfrage in Komponenten, die farm zu arbeiten, synchronisieren Sie die Antworten, und erstellen Sie dann eine einzige Antwort. Und wenn Sie diese Arbeit zu tun, während Sie kann reduzieren Wanduhr Zeit (wie viel Zeit die Uhr an der Wand sieht-pass), sind Sie immer gehen, um eine Anfrage zu mehr CPU-Zeit (CPU-Ressourcen verbraucht).

    In einem system wie MongoDB, wo Sie erwarten eine Menge von verschiedenen Kunden, die Anfragen, es gibt keine Notwendigkeit, zu versuchen zu parallelisieren, die Bearbeitung einer einzigen Anfrage, und jeden Grund, nicht zu.

    Die größere Frage ist, warum Oracle nicht erhöhen Parallelität nach 4 CPUs. Es gibt viele mögliche Gründe, aber eine vernünftige Vermutung ist, dass Sie auf irgendeine Art von Verriegelung, die ist notwendig, um zu gewährleisten Konsistenz. (MongoDB, nicht Ihnen Konsistenz, und so vermeidet diese Art der Flaschenhals.)

    • Ya, das ist, was ich vermutete, etwa Oracle, eine Sperre um die Konsistenz zu erhalten.
    • Dachte aus der Perspektive der Optimierung der mehrere Kerne, zum Beispiel, wenn es nur 2 parallel mongoDB-clients sollten in der Lage sein, zu optimieren, alle 8 Kerne auf 2 cpus zu geben, bessere Ergebnisse. Im vorliegenden Fall (2 parallelen clients) sonstige 6 Kerne untätig ist, und die anderen 2 Kerne wird mir nicht die Leistung, die 8-Kerne zusammen mir gegeben hätte, wie Ihr, unter Ausnutzung der CPUs bei geringer Last.
    • Oracle ist MVCC, es nicht sperren.
    • Sie sind absolut falsch, wenn Sie denken, dass Oracle nicht gesperrt. Oracle hat zu den großen Längen gegangen, haben viele feinkörnige kurzlebigen Schlösser maximieren die Parallelität. Aber unter der Haube ist es absolut mit Verriegelung zur Sicherstellung der Konsistenz, und ich habe persönlich gesehen, Oracle-Datenbanken fallen unter Last ohne Vorwarnung viele Male durch, um zu verschleiern, sperren Probleme. (Und wenn Sie lösen eine Verriegelung Problem, Sie stoßen werden eine andere.)
    • Was Sie sagen ist theoretisch möglich. Aber es zu tun, erfordert eine Menge Aufwand, der gibt wäre nicht so toll, und es würde die software noch schlimmer in der use-case, dass Sie versuchen, design für. Der aktuelle Entwurf führt zuverlässig in den low-load-Fall, und die Waage unter Belastung.
    • Es tut Verriegelung auf Speicher-Strukturen (shared cache von der bisher verwendeten sql-Anweisungen + Ausführungspläne), aber es macht nicht Daten sperren, die Konsistenz zu wahren. Liest blockieren Sie nicht schreibt.
    • Sie können die Splitter, die Sie mongodb-Datenbank in andere Datenbanken auf der gleichen Maschine. Für jeden Kern ein Splitter. Diese Art der write-locks weniger weh. Hier können Sie Lesen, wie man den max aus der MongoDB (nicht-trivialen Sachen): nosql.mypopescu.com/post/6314585322/...
    • Stimmt auch nur teilweise. In Oracle, unter Last, Zugriffe auf verschiedene Datenstrukturen erfordern vorübergehende sperren im index-Zugriffe von Tabellen. Das erfuhr ich, nachdem ein erfahrener DBA diagnostiziert und behoben, das problem, indem mehr Daten in den index, so dass die Abfrage nicht auf dem Tisch, das verkürzt das Schloss.

    InformationsquelleAutor btilly
  2. 3

    Oracle nicht sperren, Daten für Konsistenz, aber es macht das schreiben von Daten in die redo-und undo-Dateien für Transaktionen, die Lesen und Konsistenz. Oracle ist ein MVCC-system. Sehen http://en.wikipedia.org/wiki/Multiversion_concurrency_control .

    Verwenden Sie parametrisierte Abfragen zu machen Oracle schnell, sonst wird Oracle verbringen zu viel Zeit beim analysieren von Abfragen. Dies ist besonders wichtig, wenn viele kleine Abfragen, die gleichzeitig ausgeführt werden, die situation, die Sie testen.

    MongoDB hat lock-on schreibt.

    edit 1:

    Einen weiteren großen Unterschied zwischen Oracle und MongoDB ist die Haltbarkeit. MongoDB bietet keine Haltbarkeit, wenn Sie die Standardkonfiguration verwenden. Er schreibt einmal pro minute Daten auf die Festplatte. Oracle schreibt auf die Festplatte, die mit jedem commit. So Oracle nicht viel mehr fsyncing.

    • dies war nicht der Fall mit YCSB als seine client-code verwendet sicher schreibt in der Standardkonfiguration.
    • Zumindest mit Treiber Versionen zurück gehen, um im Herbst 2012 (vor 1,5 Jahren), das Standard-Verhalten von mongoDB ist, um die Zeitschrift zu schreiben, vor dem zurückgeben der Steuerung an den client schreiben, der fast identisch zu dem, was Oracle macht.
    InformationsquelleAutor TTT
Schreibe einen Kommentar