mongodb - uso - nosql pdf

NoSQL: ¿Qué significa para MongoDB o BigTable no estar siempre disponible? (2)

El teorema de la PAC se aplica a los sistemas informáticos distribuidos. MongoDB admite dos formas distintas de computación distribuida: fragmentación para la escala horizontal y conjuntos de réplicas para conmutación por error / alta disponibilidad. Los dos se pueden utilizar juntos o de forma independiente. Creo que el teorema de la PAC se aplica de manera ligeramente diferente a las dos formas:

Nivel de fragmentación : MongoDB almacena datos en un máximo de un fragmento autorizado.

Consistencia fuerte: existe un dato de datos sobre un fragmento como máximo. Los datos incorrectos / obsoletos no existen.
Tolerancia de partición fuerte: incluso si la red está particionada, las solicitudes nunca devuelven datos incorrectos / obsoletos. Los fragmentos continúan trabajando independientemente de otros fragmentos.
Disponibilidad débil: las lecturas / escrituras de datos en un fragmento caído fallarán.

Nivel de conjunto de réplica : MongoDB replica datos dentro de un fragmento, lo que garantiza la coherencia a través de un único nodo primario autorizado.

Consistencia fuerte: todas las lecturas / escrituras manejadas por el nodo primario.
Tolerancia de partición fuerte: si hay suficientes nodos inaccesibles, se elige una nueva primaria. El proceso de elección garantiza que siempre haya como máximo un nodo primario.
Débil disponibilidad: las lecturas / escrituras fallarán cuando no exista ningún primario, aunque se pueda acceder a los datos a través de nodos secundarios.

La opción slaveOK / ReadPreference.SECONDARY sacrifica cierta consistencia (se pueden leer datos obsoletos) para aumentar el rendimiento y la disponibilidad.

Leyendo la Guía visual de Nathan Hurst para sistemas NoSQL , incluye el triángulo CAP :

C onsistencia
A vailibilidad
P artition Tolerancia

Con SQL Server es un sistema de AC , y MongoDB es un sistema de CP .

Estas definiciones provienen de Eric Brewer, profesor de UC Berkley, y de su charla en PODC 2000 (Principios de computación distribuida):

Disponibilidad
La disponibilidad significa simplemente eso: el servicio está disponible (para funcionar completamente o no como se indicó anteriormente). Cuando compra el libro, desea obtener una respuesta, no un mensaje del navegador que indique que el sitio web no es comunicativo. Gilbert & Lynch en su prueba del CAP El teorema señala que la disponibilidad lo deja más a menudo cuando más lo necesita: los sitios tienden a caer en los períodos de mayor actividad precisamente porque están ocupados. Un servicio que está disponible pero que no se accede no beneficia a nadie.

¿Qué significa, en el contexto de MongoDB, o BigTable, que el sistema no esté "disponible"?

¿Se conecta (por ejemplo, a través de TCP / IP) y el servidor no responde? ¿Intenta ejecutar una consulta, pero la consulta nunca devuelve - o devuelve un error?

¿Qué significa no estar disponible?

La disponibilidad en este caso significa que, en el caso de una partición de red , el servidor al que se conecta un cliente puede no ser capaz de garantizar el nivel de coherencia que el cliente espera (o que el sistema está configurado para proporcionar).

Suponiendo que tiene 3 nodos, A, B y C, en un sistema hipotético distribuido. A, B y C se ejecutan en su propio rack de servidores, con 2 conmutadores entre ellos:

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]

Ahora suponga que dicho sistema está configurado de manera que se GARANTIZA que cualquier escritura irá a al menos 2 nodos antes de que se considere comprometido. Ahora, supongamos que el conmutador # 2 se desenchufa y que algún cliente está conectado al nodo C:

[Node A] <- Switch #1 -> [Node B] [ Node C ] <-- Some client

Ese cliente no podrá emitir escrituras consistentes, porque el sistema distribuido se encuentra actualmente en un estado particionado (es decir, el Nodo C no puede ponerse en contacto con otros nodos suficientes para garantizar la consistencia de 2 nodos requerida).

Agregaría a esto que algunas bases de datos NoSQL permiten una selección muy dinámica de los atributos de CAP. Cassandra, por ejemplo, permite que los clientes especifiquen la cantidad de servidores a los que debe ir una escritura antes de que se confirme por escritura. Las escrituras que van a un solo servidor son "AP", las escrituras que van a un quórum (o todos los servidores) son más "CA".

EDITAR - de los comentarios a continuación:

En MongoDB, solo puede tener una configuración maestro / esclavo dentro de un conjunto de réplicas. Lo que esto significa es que la elección de AP vs CP la realiza el cliente en el momento de la consulta. El cliente puede especificar slaveOk, que leerá desde un esclavo seleccionado arbitrariamente (que puede tener datos obsoletos): mongodb.org/display/DOCS/…. Si el cliente no está bien con datos obsoletos, no especifique slaveOk y la consulta irá al maestro. Si el cliente no puede alcanzar el maestro, obtendrá un error. No estoy seguro de cuál será exactamente ese error.