Solo para iterar sobre los sockets frente a HTTP y fsync frente a la conversación en memoria.
De forma predeterminada, MongoDB no devuelve una respuesta en una llamada de escritura. Simplemente escribe sus datos en el socket y asume que está en la base de datos y disponible. Bajo carga concurrente, esto podría tener una copia de seguridad y no hay una buena manera de saber qué tan rápido Mongo realmente es a menos que use una llamada opcional que devolverá una respuesta para la escritura una vez que los datos estén disponibles.
No estoy diciendo que el rendimiento de inserción de Mongo no sea más rápido que Couch, insertar en la memoria es mucho más rápido que sincronizar con el disco, la mayor diferencia aquí está en la diferencia en los objetivos que tienen MongoDB y CouchDB sobre la consistencia y la durabilidad. Pero todas las herramientas de "rendimiento" que he visto para probar Mongo usan la API de escritura predeterminada, por lo que en realidad no está probando el rendimiento de inserción, está probando qué tan rápido puede vaciar en un socket.
He visto muchos puntos de referencia que muestran que Mongo es más rápido que Redis y Memcached porque no se dan cuenta de que Redis y Memcached devuelven una respuesta cuando los datos están en la memoria y Mongo no. Mongo definitivamente no lo es más rápido que Redis :)
