Ácido frente a los almacenes de datos de base

Un sello distintivo de los sistemas de bases de datos relacionales se conoce algo tan Cumplimiento de ACID. Como ya habrán adivinado, ACID es un acrónimo - las letras individuales, la intención de describir una característica de las transacciones de bases de datos individuales, se pueden ampliar como se describe en esta lista:

• Atomicidad: La transacción de base de datos debe tener éxito por completo o totalmente fallar. No se permite el éxito parcial.

• Consistencia: Durante la transacción de base de datos, el RDBMS progresa de un estado a otro válida. El Estado nunca es válido.

• Aislamiento: Transacción de la base de datos del cliente debe ocurrir en forma aislada de otros clientes que tratan de negociar con el RDBMS.

• Durabilidad: La operación de datos que fue parte de la transacción debe reflejarse en almacenamiento no volátil (memoria del ordenador que puede recuperar la información almacenada incluso cuando no está alimentado - como un disco duro) y persistir después de la transacción se completa correctamente. Fracasos de transacción no pueden dejar los datos en un estado parcialmente comprometida.

Ciertos casos de uso de RDBMS, como el procesamiento de transacciones en línea, dependen de las transacciones ACID compatibles entre el cliente y el RDBMS para que el sistema funcione correctamente. Un gran ejemplo de una transacción ACID-compliant es una transferencia de fondos de una cuenta bancaria a otra.

Esto se descompone en dos operaciones de base de datos, donde la cuenta de origen muestra una retirada, y la cuenta de destino muestra un depósito. Obviamente, estas dos operaciones tienen que ser atados juntos con el fin de ser válido por lo que si uno de ellos falla, toda la operación debe dejar de garantizar tanto los saldos siguen siendo válidas.

Sí Hadoop no tiene ningún concepto de las operaciones (o incluso los registros, para el caso), por lo que claramente no es un sistema compatible con ACID. Pensando más en concreto sobre el almacenamiento de datos y procesamiento de los proyectos en todo el ecosistema Hadoop, ninguno de ellos es totalmente compatible con ACID, tampoco. Sin embargo, hacer reflejar las propiedades que a menudo se ve en almacenes de datos NoSQL, por lo que hay algunos precedentes al enfoque Hadoop.

Un concepto clave detrás de los almacenes de datos NoSQL es que no todas las aplicaciones verdaderamente necesita transacciones ACID conformes. Relajarse en ciertas propiedades ACID (y alejándose del modelo relacional) ha abierto un gran abanico de posibilidades, que han permitido a algunos almacenes de datos NoSQL para lograr escalabilidad masiva y rendimiento para sus aplicaciones de nicho.

Mientras que el ácido define las características clave necesarias para el procesamiento de transacciones fiable, el mundo NoSQL requiere características diferentes para permitir la flexibilidad y la escalabilidad. Estas características opuestas son capturados hábilmente en el acrónimo BASE:

• BasicallyLAvailable: El sistema está garantizado para estar disponible para la consulta de todos los usuarios. (Sin aislamiento aquí.)

• Soft Estado: Los valores almacenados en el sistema pueden cambiar debido a la consistencia eventual modelo, como se describe en la siguiente bala.

• Eventually Consistente: Como los datos se añade al sistema, el estado del sistema se replica gradualmente a través de todos los nodos. Por ejemplo, en Hadoop, cuando un archivo se escribe en el HDFS, las réplicas de los bloques de datos se crean en diferentes nodos de datos después de que los bloques de datos originales se han escrito. Para el corto periodo antes de que se replican los bloques, el estado del sistema de archivos no es consistente.

El acrónimo BASE es un poco artificial, como la mayoría de los almacenes de datos NoSQL no abandonan por completo todas las características ACID - en realidad no es el concepto opuesto polar que el nombre implica, en otras palabras. Asimismo, el Estado Suave y características Eventualmente consistentes equivalen a lo mismo, pero el punto es que al relajar la consistencia, el sistema puede horizontalmente escala (muchos nodos) y asegurar la disponibilidad.

Ninguna discusión de NoSQL estaría completa sin mencionar el teorema de la PAC, que representa a los tres tipos de garantías que los arquitectos tienen como objetivo proporcionar a sus sistemas:

• Consistencia: Similar al C en ACID, todos los nodos en el sistema tendría la misma vista de los datos en cualquier momento.

• Disponibilidad: El sistema siempre responde a las solicitudes.

• La tolerancia de reparto El sistema permanece en línea si se producen problemas en la red entre los nodos del sistema.

El teorema de la PAC establece que en los sistemas en red distribuidos, los arquitectos tienen que elegir dos de estas tres garantías - no se puede prometer a sus usuarios de los tres. Eso te deja con las tres posibilidades que se muestran:

• Los sistemas que utilizan tecnologías relacionales tradicionales normalmente no se particionan tolerante, para que puedan garantizar la coherencia y la disponibilidad. En resumen, si una parte de estos sistemas de tecnologías relacionales tradicionales no está en línea, todo el sistema está desconectado.

• Los sistemas donde la tolerancia de la partición y la disponibilidad son de importancia primaria no puede garantizar la coherencia, ya que las actualizaciones (que destructor de consistencia) se pueden hacer en cualquier lado de la partición. Las tiendas de valores clave Dynamo y CouchDB y la tienda de la columna familiar Cassandra son ejemplos populares de tolerancia / disponibilidad (PA) sistemas de partición.

• Los sistemas donde la tolerancia partición y la consistencia son de importancia primaria no puede garantizar la disponibilidad porque los sistemas devuelven errores hasta que se resuelva la situación con particiones.

  Almacenes de datos basada en Hadoop se consideran sistemas de CP (consistent y partition tolerantes). Con los datos almacenados de forma redundante a través de muchos nodos esclavos, interrupciones en el servicio a grandes porciones (particiones) de un cluster Hadoop puede tolerarse. Hadoop se considera que es coherente porque tiene un almacén de metadatos central (la NameNode) que mantiene una sola vista, consistente de los datos almacenados en la agrupación.