¿Cuál es la atracción de los sistemas de bases de datos sin esquema?

Question

He estado escuchando un montón de hablar sin esquema (a menudo distribuido) como sistemas de bases de datos MongoDB, CouchDB, SimpleDB, etc ...

Mientras que puedo entender que podría ser valiosa para algunos propósitos, en la mayoría de mis aplicaciones que estoy tratando de persistir los objetos que tienen un determinado número de campos de un tipo específico, y sólo pienso automáticamente en el modelo relacional. Siempre estoy pensando en términos de filas con los identificadores únicos enteros, null / no campos nulos, tipos de datos SQL, y para consultas de selección para encontrar conjuntos.

Mientras que me siento atraído a la naturaleza distribuida y fácil JSON / REST las interfaces de estos nuevos sistemas, no entiendo cómo los hashes de clave / valor ligeramente mecanografiadas me ayudará con mi desarrollo. ¿Por qué una con tipo, sistema sin esquema suelta ser bueno para mantener limpios los conjuntos de datos? ¿Cómo puedo, por ejemplo, encontrar todos los artículos con fechas entre X e Y, cuando tal vez no tengan fechas? ¿Hay algún concepto de una unión?

Me entender muchos sistemas tienen sus propias diferencias y los puntos fuertes, pero me pregunto a la diferencia de paradigma. Supongo que esto es una pregunta abierta, pero tal vez las respuestas y los caminos de la comunidad a la que he visto personalmente las ventajas de estos sistemas ayudarán ilumíneme y otros acerca de cuándo me gustaría hacer uso de ellos (más de la cadera es cierto) sistemas en lugar de el RDBMS tradicional.

Answer 1

Voy a llamar a cabo una o dos razones comunes (estoy seguro que las personas van a escribir las respuestas de desarrollo)

1. Con los sistemas altamente distribuidos, cualquier conjunto de datos dado puede ser propagación a través de múltiples servidores. Cuando esto sucede, las restricciones relacionales que pueden garantizar el motor de base de datos se reducen considerablemente. Algunos de tendrá que ser manejado de código de la aplicación de su integridad referencial. Al hacerlo, usted descubrirá rápidamente varios puntos de dolor:

   • su lógica es la propagación a través de múltiples capas (app y db)
   • su lógica es la propagación a través de múltiples idiomas (SQL y su idioma aplicación de elección)

   El resultado es que la lógica se encapsula menos, menos portátil, y mucho más caro al cambio. Muchos desarrolladores se encuentran escribiendo más lógica en el código de la aplicación y menos en la base de datos. Llevado al extremo, el esquema de base de datos se convierte en irrelevante.

2. gestión, en especial de esquema en sistemas donde el tiempo de inactividad no es una opción, es difícil. la reducción de la complejidad del esquema reduce esa dificultad.

3. ACID no funciona muy bien para sistemas distribuidos ( BASE , PAC , etc). El lenguaje SQL (y todo el modelo relacional, en cierta medida) está optimizado para un mundo ÁCIDO transaccional. Así que algunos de lenguaje SQL características y las mejores prácticas son inútiles mientras que otros son realmente perjudiciales. Algunos desarrolladores se sienten incómodos "contra la corriente" y prefieren dejar SQL totalmente a favor de un lenguaje que fue diseñado desde el principio para sus necesidades.

4. Costo: la mayoría de los sistemas RDBMS no son libres. Los líderes de escalamiento (Oracle, Sybase, SQL Server) son todos los productos comerciales. Cuando se trata de grandes ( "escala Web") los sistemas, los costos de licencias de bases de datos pueden cumplir o exceder los costos de hardware! Los costos son altos suficiente para cambiar la acumulación normal de / Comprar consideraciones drásticamente hacia la construcción de una solución personalizada en la parte superior de una oferta OSS (todas las ofertas NoSQL son significativos OSS)

Answer 2

sin esquema es grande por dos razones:

1. Cerebro optimizar la intuición de almacenamiento de documentos
2. Sparse-Matrix y Entidad-Atributo-Valor problemas de almacenamiento.

Yo he usado tanto SQL y n-SQL para aplicaciones de producción en Ruby on Rails. No soy un experto en la base de datos y tengo que confesar a googlear términos de ácido y similares, ya que no son familiares para mí.

"Ah, ja! Otro ignorante seguidor de tendencia que salta en el último vagón" se puede decir. Pero, en realidad, estoy muy contento con mi decisión de usar MongoDB en nuestra más reciente aplicación de 2 años y he aquí por qué ...

La otra cara de la intuición cerebro-optimización fue mi experiencia con el sistema de comercio electrónico Magento. No quiero para golpear porque me sirvió bien en el momento pero realmente dio en el procesador duro tratando de calcular los atributos para cada producto. La razón subyacente era el almacén de la entidad-atributo-valor de los datos del producto. Cache o ser condenado era la solución.

La principal ventaja para mí es la optimización en el único lugar que realmente importa - su propio cerebro . Así que muchas tecnologías son criticadas por su eficiencia en la memoria, procesadores, hardware y sin embargo tener una base de datos que es extremadamente intuitiva para entender trae sus propios méritos. Hemos encontrado que sea rápido para añadir características a nuestro código, porque la base de datos simplemente se parece mucho a la realidad que estamos modelado. Cuando le he pedido a los clientes de comercio electrónico para mí presentar con su lista de productos que, naturalmente, tienden a utilizar Excel (creo tienda de la tabla). Las primeras columnas son fáciles:

1. Nombre
2. Precio
3. Tipo de Producto (

A continuación, se hace más difícil y cubierta en las notas, la codificación y enlaces a otras tablas (sip .. relaciones)

Color

4. Color (Sólo algunos productos)
5. Tamaño (X Grande, grande, mediano) - sólo para los productos 8'9'10, palos de golf utilizan una escala diferente
6. Color 2. Los collares para gatos tienen dos opciones de color.
7. Potencia
8. fijación de tipo (hombre, mujer)

Así que termina en un lío terrible de las tablas de Excel que no tienen sentido para mí y no mucho sentido para las personas que trabajan con productos del día a día. Tiramos nuestros brazos en el aire y decide ir a través del catálogo y luego me golpea! ¿No sería estupendo si pudiera almacenar los datos tal como aparece en el catálogo !? colecciones sólo de los registros de cada producto que las listas sólo el atributo de ese producto. A continuación, puede seleccionar atributos comunes a índice de recuperación en una fecha posterior. Por supuesto, eso es un almacén de documentos.

En resumen, almacenes de documentos son grandes cuando usted tiene un problema matriz dispersa u objetos que mutan sus atributos con el tiempo. Después de haber vivido en un mundo no-SQL durante 2 años, no puedo pensar en una aplicación real que no tiene esas características porque el mundo sí parece un almacén de documentos.

Answer 3

La principal preocupación debería ser ¿qué es lo que hay que hacer con sus datos. Si usted tiene un gran conjunto de datos y está encontrando un RDBMS tradicionales a ser un cuello de botella a continuación, es posible que desee experimentar con una o sin esquema AA solución NOSQL .

La mayoría de los ambientes que soy consciente de la utilización de soluciones NOSQL también utilizar una solución de RDBMS en alguna forma o la moda. soluciones basadas RDBMS son la norma, donde la integridad de datos es extremadamente importante y que necesitan transacciones ACID. Sin embargo, si el sistema no es muy transacción basada pero hay que ampliar o escalar muy rápido, un NOSQL solución puede ser deseable.

Answer 4

Sólo he jugado con MongoDB, pero una cosa que realmente me interesaba era cómo se puede anidar documentos. En un documento MongoDB es básicamente como un registro. Esto es muy agradable porque, tradicionalmente, en un RDBMS, si necesita sacar un disco "Persona" y obtener la dirección asociada, información del empleador, etc. frecuencia que le tiene que ir a varias tablas, unirlos, hacer múltiples bases de datos llamadas. En una solución NoSQL como MongoDB, sólo puede anidar los registros asociados (documentos) y no tiene que meterse con las claves externas, unirse, múltiples llamadas bases de datos. Todo lo relacionado con un registro que se tira.

Esto es especialmente útil cuando se trata de objetos. Puede que en muchos casos simplemente almacenar un objeto como una serie de documentos anidados.

Answer 5

bases de datos NoSQL no sin esquema son; el esquema se guardan en los datos. Ellos se llaman adecuadamente semiestructuradas. En algunos almacenes de datos KV, sin embargo, el esquema puede incluso ser embebido en el código. La ventaja del enfoque de semi-estructurada es doble: flexibilidad en la que las columnas son parte de una fila (una fila podría tener 5 columnas y otra tienen 5 columnas diferentes, y la flexibilidad en las características de las columnas (por ejemplo, longitudes variables)

Answer 6

Normalmente, la atracción es la de aceite de serpiente - la mayoría de la gente favourising ellos no tienen ninguna pista sobre el teorema relacional y hablan de SQL en un nivel que los profesionales de vomitar. Ni idea de lo que son condiciones ácidas, Ehy son importantes, etc.

No decir que no tienen usos válidos .... simplemente diciendo que la mayoría de la atracción es la gente sin saber lo que deben saber y hacer conclusiones estúpidas. Una vez más, no todo el mundo es así, pero la mayoría de los desarrolladores a favor de ellos son -. No es bueno en su entendimiento lo que es un sistema de base de datos; fuimos es responsable de