MongoDb vs CouchDb: velocidades de escritura para clientes geográficamente remotos

Question

Me gustaría que todos mis usuarios puedan leer y escribir en el almacén de datos muy rápidamente. Parece que MongoDb tiene lecturas increíbles, pero parece que las escrituras podrían ser muy lentas si el master db necesita ubicarse muy lejos del cliente. Couchdb parece que tiene lecturas lentas, pero ¿qué hay de las escrituras en el caso cuando el cliente está muy lejos del maestro? Con couchdb, podemos tener varios maestros, lo que significa que siempre podemos tener un nodo de escritura cerca del cliente. ¿Podría couchdb realmente ser más rápido para escribir que mongodb en el caso en que nuestra base de usuarios se extienda geográficamente?

Me encantaría usar mongoDb debido a su velocidad increíblemente rápida, pero algunos de mis usuarios muy lejos del master único tendrán una experiencia horrible. Para tipos de sistemas en todo el mundo, wouldn woulddDb ser mejor. ¿No está completamente excluido mongodb en caso de que tenga usuarios en todo el mundo? MongoDb, si está escuchando, ¿por qué no hace algunas configuraciones simples de múltiples maestros, donde la resolución de conflictos puede ser parte de la semántica de actualización? Esto parece ser lo único que se interpone entre mongoDb dominando por completo la cuota de mercado de nosql. Todo lo demás es muy impresionante.

Answer 1

Su pregunta a partir de ahora, está llena de especulaciones y conjeturas.

... por qué no podemos optar por la consistencia de ciertas escrituras, siempre y cuando estamos seguros de que la persona que escribió los datos será capaz de leer de forma consistente, mientras que otros observarán consistencia eventual

¿Qué pasa si esas escrituras afectan a otras escrituras? ¿Qué pasa si esas escrituras evitarían que otras personas hagan cosas? Es difícil decir el posible efecto secundario si no nos contó ninguna información específica.

Mi principal sugerencia para usted es que haga algunas pruebas. A menos que lo hayas probado, la especulación sobre los cuellos de botella es una completa pérdida de tiempo. No necesita probarlo a través de máquinas remotas, configurar algunas bases de datos locales y agregar un retraso artificial, luego ejecutar sus pruebas.

De esta manera puede probar las diferentes opciones que tiene, ver dónde MongoDB es mejor o dónde se destaca CouchDB. Entonces puede tomar uno de ellos e irse con los contras, o puede intentar modificar su propio modelo de base de datos y hacer más pruebas.

Aquí nadie será capaz de darle una solución general al problema específica (bien a menos que usted nos da todo su código y usted nos paga por trabajar en él: P) bases de datos no son fáciles, especialmente si usted necesita escalarlos bajo ciertos requisitos.

Answer 2

Para los tipos de sistemas de todo el mundo, wouldn woulddDb ser mejor. ¿No está completamente excluido mongodb en caso de que tenga usuarios en todo el mundo?

MongoDB admite sharding. Entonces no necesitas un solo maestro. De hecho, parece que tienes una clave de fragmento preparada (región).

MongoDB también admite conjuntos de réplicas junto con la fragmentación. Por lo tanto, si necesita ejecutar en varios centros de datos (DC), coloque un maestro y una de las réplicas en el mismo DC. De hecho, también sugieren agregar un tercer nodo a un DC separado como failover de respaldo en caliente.

Tendrá que profundizar en la configuración más detallada de MongoDB, pero definitivamente puede controlar dónde se almacenan los datos y puede priorizar que otras réplicas en un DC sean "próximas en línea" para la promoción a Máster.

En este punto, sin embargo, ya conoce bien los detalles de MongoDB y tendrá que cavar un poco y "jugar" un poco. Sin embargo, necesitará mucho "tiempo de reproducción" para cualquier solución que realmente se encargue de los maestros en los centros de datos.

Answer 3

Aquí hay un artículo detallado que 10gen ha creado, y da ejemplos de cuándo debe elegir MongoDB o CouchDB, por razones también.

http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

Editar

El enlace de arriba se mueve, sino que se puede ver aquí: http://web.archive.org/web/20120614072025/http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

Answer 4

Disclosure: Soy un fan MongoDB y el usuario, tengo cero experiencia con CouchDB.

Tengo una aplicación para trabajos pesados ​​que requiere mucha lectura y escritura. Yo diría que lee por encima de las escrituras en un factor de alrededor de 30: 1. La forma en que las lecturas diseñadas de mongo siempre van a ser mucho más rápidas de lo que escribe el truco (en mi experiencia) es hacer que tus escrituras sean tan eficientes que puedas dedicar un mayor porcentaje de tus recursos del sistema a las escrituras.

Al construir un producto encima de mongo, la clave para recordar es el campo _id. Este campo se genera automáticamente y se agrega a todos sus objetos JSON se verá algo como 47cc67093475061e3d95369d cuando diseñe sus consultas (Buscar) intente y consulte en este campo siempre que sea posible, ya que contiene la ubicación del equipo (¿y también la ubicación del disco? ? - debería comprobar esto) donde vive el objeto así que cuando utiliza un hallazgo o actualización utilizando este campo realmente acelerará su máquina. Considere esto en el diseño de su sistema.

Ejemplo:

2 de los clusters en mi base de datos son "usuarios" y "mensajes". Un usuario puede crear múltiples publicaciones. Estas dos colecciones tienen que referirse mucho en la implementación de mi aplicación.

En cada objeto de publicación, almaceno el _id del usuario principal. En cada objeto de usuario, almaceno una matriz de todas las publicaciones que el usuario ha creado.

Ahora en cada página de usuario puedo generar una lista de todas las publicaciones creadas sin una consulta estresante de recursos pero con una búsqueda directa de _id. Cuanto más grande sea el grupo mongo, mayor será la diferencia que esto supondrá.

Si está familiarizado con los rowids de ubicación física de oráculo, puede comprender este concepto solo que en mongo es mucho más impresionante y poderoso.

Tenía miedo el año pasado cuando decidimos finalmente deshacernos de MySQL para mongo, pero puedo decir lo siguiente sobre mi experiencia: - La transferencia de datos siempre es horrible, pero fue tan bien como podría haber imaginado. - Mongo es probablemente el DB NoSQL mejor documentado que existe y la comunidad Open Source es fantástica. - Cuando dicen rápido y escalable no es broma, vuela. - El diseño de esquema es muy fácil y mucho más natural y ordenado que el tipo clave/valor tipo db's en mi opinión. - Todo el sistema parece diseñado para la complejidad mínima del usuario, agregar nodos, etc. es muy fácil.

Ok, en serio juro que mongo no me pagó para escribir esto (lo deseo) pero me disculpo por el festival de amor.

Cualquiera que sea su elección, la mejor de las suertes.