2011-02-11 19 views
10

al tratar con mongodb, ¿cuándo debería usar {safe: true} en las consultas?mongodb: si siempre utilizo la opción 'segura' en las actualizaciones

Ahora uso la opción 'segura' solo para comprobar si mis consultas se insertaron o actualizaron con éxito. Sin embargo, siento que esto podría ser más de matar.

¿Debo suponer que el 99% del tiempo, mis consultas (suponiendo que estén escritas correctamente) serán insertadas/actualizadas, sin tener que preocuparse por comprobar si se ingresaron correctamente?

thoughts?

Respuesta

24

Suponiendo que cuando diga consultas realmente quiere decir escrituras/inserciones (la redacción de su pregunta me hace pensar esto), entonces se puede usar Write Concern (safe, none, fsync, etc.) para obtener más velocidad y menos seguridad cuando eso es aceptable, y menos velocidad y más seguridad cuando sea necesario.

Como ejemplo, una hipotética aplicación estilo Facebook podría utilizar una escritura insegura para "Me gusta", mientras que usaría una escritura muy segura para cambios de contraseña. La lógica detrás de esto es que habrá miles de actualizaciones tipo "Me gusta" que suceden por un segundo, y no importa si se pierde, mientras que las actualizaciones de contraseñas ocurren con menos frecuencia, pero es esencial que tengan éxito.

Por lo tanto, intente adaptar su elección de escribir preocupación al tipo de actualización que está realizando, según los requisitos de velocidad e integridad de datos.

2

La seguridad solo es necesaria en las escrituras, no en las lecturas. Las consultas son solo lecturas.

6

Aquí hay otro caso de uso en el que las escrituras inseguras son una elección adecuada: está realizando una gran cantidad de escrituras en poco tiempo. En este caso, puede realizar varias escrituras y luego llamar al último error para ver si alguna de ellas falló.

collection.setWriteConcern(WriteConcern.NORMAL) 
collection.getDB().resetError() 
List< 
for (Something data : importData) { 
    collection.insert(makeDBObject(data)) 
} 
collection.getDB().getLastError(WriteConcern.REPLICAS_SAFE).throwOnError() 

Si este bloque tiene éxito sin excepción, entonces todos los datos se insertaron correctamente. Si hubo una excepción, entonces una o más de las operaciones de escritura fallaron, y tendrá que volver a intentarlas (o verificar una violación única del índice, etc.). En la vida real, puede llamar a getLastError cada 10 escrituras, para evitar tener que volver a enviar muchas solicitudes.

Este patrón es muy agradable para el rendimiento al realizar inserciones masivas de grandes cantidades de datos.

+0

Dado que los errores deben regresar de forma asincrónica, ¿cómo sabe que ha esperado lo suficiente para que llegue un error? – Leopd

+0

Leopd: los errores no vuelven de forma asincrónica. Los bloques de llamada getLastError hasta que se recibe una respuesta. –

+0

Pero las escrituras se están cometiendo de forma asincrónica. Por lo tanto, a menos que getLastError vacíe el búfer de escritura, solo informará de los errores que hayan ocurrido y no podrá conocer las escrituras que aún no han finalizado. – Leopd

Cuestiones relacionadas