jueves, 24 de marzo de 2011

MongoDB 1,8 agrega Journaling

10 Tenets Of Enterprise Data Management
(haga clic en la imagen para ampliarla)
Slideshow: 10 principios de la empresa datos ManagementAn a menudo solicitadas para sistemas NoSQL es el servicio de base de datos establecida de diario. En la versión 1.8 de MongoDB, "escritura anticipada" diario se ha agregado al sistema. En el caso de un accidente, una transacción varios pasos puede reconstruirse desde el diario.

Diario de escritura anticipada significa que los archivos se escriben en el diario antes de la escritura a la base de datos. Es una característica estándar de sistemas de base de datos relacional y puede encontrarse en Oracle, IBM DB2, Microsoft SQL Server y de código abierto MySQL.

"Definitivamente es nuestra característica solicitada número una. Representa una maduración del producto,"Dwight Merriman, fundador y Director General de 10Gen, la principal empresa detrás de MongoDB, dijeron en una entrevista.

Antes de que versión 1.8, un administrador de MongoDB podría recuperarse del accidente, pero el proceso fue mucho más dolorosa y lenta, explicó Merriman. La característica de diario de escritura anticipada es el mejor enfoque establecido para recuperaciones, permitiendo a cada evento que precedieron al accidente a reconstruirse y los datos restaurados.

Mientras sistemas relacionales tratan datos en filas y columnas, MongoDB es una base de datos de orientada al documento almacenar, no tantas documentos de texto como objetos JSON o JavaScript Object Notation. JSON es una alternativa a XML para crear "documentos" o fecha estructurado en objetos que pueden ser manipulados por equipo y compartidos por los servicios Web. Estos documentos pueden ser estructuras de datos simples, como enteros, cadenas, matrices o fechas.

Además, MongoDB 1,8 ha agregado índices cubiertos o índices que se pueden identificar como tener todas las claves del documento necesarias para satisfacer una consulta determinada. Sabiendo que es un índice que satisface que una consulta aumenta la eficiencia de un sistema de base de datos. "El índice es mucho menor (que los datos almacenados en su conjunto) y puede encontrarse en la memoria de acceso aleatorio", dijo Merriman, donde se puede acceder más rápidamente que el dibujo datos del disco.

La versión 1.8 de MongoDB también incluye índices dispersos, donde una colección de objetos de datos puede incluir subconjuntos que faltan uno o más campos encontrados el resto del conjunto. Un sistema de base de datos normalmente pone un valor null en el campo y, en algunos casos, un índice se llena con tantos valores NULL como valores declarados. Un índice de escaso es una optimización que permite que el sistema omite los valores NULL en el índice de la construcción, reduciendo su tamaño y lo que le permite responder más rápidamente a las preguntas.

Índices cubiertos y escasos índices fueron iniciados por sistemas relacionales. Su incorporación a un sistema de NoSQL representa un esfuerzo para agregar más relacional características a los sistemas que aún tienen sus propias propiedades únicas. En términos de similitudes, MongoDB usos consultan, inserción, actualizar y eliminar como comandos para administrar documentos JSON; un sistema relacional utiliza Select, Insert, Update y Delete para funciones equivalentes en el manejo de datos. Pero MongoDB puede modificar lo que considera un sistema relacional un esquema fijo y seguir añadiendo nuevos objetos a los archivos que está almacenando sin perder la pista de ellos.

Sistemas de NoSQL repartición también ellos mismos y sus datos en un clúster y controlador de almacenamiento y recuperación de funciones de servidor en paralelo, aumenta considerablemente la cantidad de datos que pueden tratar simultáneamente. Esa propiedad es lo que da a los sistemas de NoSQL la reputación de ser los sistemas "Grandes datos", con algunos casos petabytes de manejo.

Un área de diferencia continua con sistemas relacionales carece del sistema NoSQL de coherencia, o capacidad para responder a la consulta de dos diferentes partidos exactamente del mismo modo. Sistemas de NoSQL va a hacer lecturas de datos de una réplica ligeramente desfasada a fin de evitar la imposición de bloqueos que permiten nuevos datos se escriban en la única copia de los datos. Esto significa que un usuario puede obtener una respuesta de una réplica y otro usuario, una fracción de segundo más tarde, obtendría una respuesta diferente, basada en un sistema actualizado. En la mayoría de los casos, como en versiones de Facebook, redes sociales o juegos en línea, la diferencia es menor o no consecuentes. Pero eso significa que NoSQL sistemas no se utilizan en el comercio de equidad o comercio de bonos u otras configuraciones donde la consistencia es necesario en lugar de opcional.

Merriman dijo que los desarrolladores de MongoDB están trabajando con la idea de consistencia eventual, donde se puede ajustar el sistema a ser altamente eficiente en términos de satisfacer millones de solicitudes de datos, mientras que tolerar un bajo nivel de coherencia. O podría ser un poco menos eficiente pero más coherente en sus respuestas a las preguntas. En el mundo de NoSQL, la idea de coherencia puede colocarse en un control deslizante y se trasladó a otro, dependiendo de las necesidades del usuario en la configuración en la que funcionará.

Regulador de todavía no existe. Consistencia eventual es un concepto que regularmente se barajó por varios equipos de desarrollo de NoSQL, pero no hay calendario definitivo para cuando uno de ellos planes para implementarlo.

InformationWeek ha publicado un informe completo sobre la preserveration de datos y almacenamiento extendido. Descargar ahora. (Se requiere un registro gratuito).

No hay comentarios:

Publicar un comentario