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

Question

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

Aunque puedo entender que podría ser valiosa para algunos propósitos, en la mayor parte de mis aplicaciones, intento persistir objetos que tienen un número específico de campos de un tipo específico, y pienso de manera automática en el modelo relacional. Siempre estoy pensando en términos de filas con identificadores enteros únicos, campos nulos/no nulos, tipos de datos SQL y consultas seleccionadas para encontrar conjuntos.

Si bien me atraen la naturaleza distribuida y las interfaces jSON/RESTful fáciles de estos sistemas nuevos, no entiendo cómo los valores hash de clave/valor mecanografiados vagamente me ayudarán con mi desarrollo. ¿Por qué un sistema de tipo suelto y sin esquema sería bueno para mantener conjuntos de datos limpios? ¿Cómo puedo, por ejemplo, encontrar todos los elementos con fechas entre xey cuando es posible que no tengan fechas? ¿Hay algún concepto de unirme?

Entiendo que muchos sistemas tienen sus propias diferencias y puntos fuertes, pero me pregunto cuál es la diferencia de paradigma. Supongo que esta es una pregunta abierta, pero quizás las respuestas de la comunidad y las formas en que personalmente hayan visto las ventajas de estos sistemas ayudarán a iluminar a mí y a otros sobre cuándo querría utilizar estos sistemas (más modernos) en lugar de el RDBMS tradicional.

Answer 1

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

1. Con los sistemas altamente distribuidos, cualquier conjunto de datos dado se puede propagar a través de múltiples servidores. Cuando eso sucede, las restricciones relacionales que el motor de DB puede garantizar se reducen en gran medida. Algunos de su integridad referencial deberán manejarse en el código de la aplicación.Al hacerlo, usted descubrirá rápidamente varios puntos de dolor:

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

   El resultado es que la lógica es menos encapsulada, menos portátil y MUCHO más costosa de cambiar. 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 la base de datos se vuelve irrelevante.

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

3. ACID no funciona muy bien para sistemas distribuidos (BASE, CAP, etc.). El lenguaje SQL (y el modelo relacional completo en cierta medida) está optimizado para un mundo ACID transaccional. Por lo tanto, algunas de las características del lenguaje SQL y las mejores prácticas son inútiles, mientras que otras son realmente dañinas. Algunos desarrolladores se sienten incómodos con "a contrapelo" y prefieren dejar SQL completamente a favor de un lenguaje que fue diseñado desde cero para sus requerimientos.

4. Costo: la mayoría de los sistemas RDBMS no son gratuitos. Los líderes en escalado (Oracle, Sybase, SQL Server) son todos productos comerciales. Cuando se trata de sistemas grandes ("escala web"), los costos de licencia de la base de datos pueden alcanzar o superar los costos de hardware. Los costos son lo suficientemente alto como para cambiar la estructura 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 significativos son OSS)

Answer 2

Solo he jugado con MongoDB pero una cosa que realmente me interesaba era cómo se podían anidar documentos. En MongoDB, un documento es básicamente como un registro. Esto es realmente bueno porque tradicionalmente, en un RDBMS, si necesitabas sacar un registro de "Persona" y obtener la dirección asociada, la información del empleador, etc. con frecuencia tendrías que ir a varias tablas, unirlas, hacer una base de datos múltiple llamadas. En una solución NoSQL como MongoDB, puede anidar los registros asociados (documentos) y no tener que meterse con claves externas, uniéndose, múltiples llamadas a la base de datos. Todo lo que está asociado con ese registro se tira.

Esto es especialmente útil cuando se trata de objetos. En muchos casos, solo puede almacenar un objeto como una serie de documentos anidados.

Answer 3

Normalmente la atracción es la del aceite de serpiente: la mayoría de las personas que los favorecen no tienen ni idea sobre el teorema relacional y hablan SQL en un nivel que hace vomitar a los profesionales. No tengo idea de cuáles son las condiciones de ACI, ehy son importantes, etc.

No digo que no tienen usos válidos .... simplemente diciendo que la mayoría de la atracción es que las personas no saben lo que deben saber y hacen conclusiones estúpidas. Una vez más, no todos son así, pero la mayoría de los desarrolladores que los favorecen son - no es bueno en su comprensión de lo que es responsable un sistema de base de datos.

Answer 4

La principal preocupación debería ser ¿qué necesitas para hacer con tus datos Si tiene un gran conjunto de datos y encuentra que un RDBMS tradicional es un cuello de botella, entonces puede probar con una solución sin esquema o una NOSQL.

La mayoría de los entornos que conozco usando las soluciones NOSQL también usan una solución RDBMS de alguna forma. Las soluciones basadas en RDBMS son la norma donde la integridad de los datos es extremadamente importante y usted necesita transacciones ACID. Sin embargo, si su sistema no se basa en gran medida en transacciones, pero necesita escalar o escalar rápidamente, puede ser conveniente una solución NOSQL.

Answer 5

Las bases de datos NoSQL no son esquemáticas; el esquema está incrustado en los datos. Se llaman apropiadamente semiestructurados. Sin embargo, en algunos almacenes de datos KV, el esquema puede estar incluido en el código. La ventaja del enfoque semiestructurado es doble: flexibilidad en la que las columnas son parte de una fila (una fila puede tener 5 columnas y otra tener 5 columnas diferentes, y flexibilidad en las características de las columnas (por ejemplo, longitudes variables)

Answer 6

sin esquema es grande por dos razones:.

1. cerebro optimizar la intuición de almacenamiento de documentos
2. Sparse-Matrix Resuelve los problemas de almacenamiento y Entity-Attribute-Value

he utilizado bo th SQL y No-SQL para aplicaciones de producción en Ruby on Rails. No soy un experto en bases de datos y debo confesar que estoy buscando en Google ACID y términos similares, ya que no me resultan familiares.

"Ah, ah otro seguidor de la tendencia de saber-nada saltando en el último carro", puede decir. Pero, en realidad, estoy muy contento con mi decisión de usar MongoDB en nuestra aplicación más reciente de 2 años y he aquí por qué ...

La otra cara de la intuición de optimización cerebral fue mi experiencia con el Magento e- sistema de comercio. No quiero golpearlo porque me fue muy útil en ese momento, pero realmente golpeó duro al procesador al tratar de calcular los atributos para cada producto. El motivo subyacente fue el almacén Entity-Attribute-Value de los datos del producto. Caché o ser condenado fue la solución.

La mayor ventaja para mí es la optimización en el único lugar que realmente importa: tu propio cerebro. Muchas tecnologías son criticadas por su eficiencia en la memoria, los procesadores, el hardware y, sin embargo, tener una base de datos que sea extremadamente intuitiva para comprender trae sus propios méritos. Hemos encontrado que es rápido agregar funciones a nuestro código porque la base de datos simplemente se parece mucho al mundo real que estamos modelando. Cuando les pedí a los clientes de e-commerce que me presenten su lista de productos, naturalmente usarán Excel (piense en la tienda de mesas). Las primeras columnas son fáciles:

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

A continuación, se hace más difícil y cubierto de notas, códigos de colores y enlaces a otras tablas (sip .. relaciones)

4. color (Sólo algunos productos)
5. Tamaño (X grande, Sm todo) - solo para productos 8'9'10, los palos de golf usan una escala diferente
6. Color 2. Los collares de gato tienen dos opciones de color.
7. Potencia
8. tipo de fijación (Hombre, Mujer)

por lo 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 el día de los productos en y día afuera. ¡Lanzamos nuestros brazos al aire y decidimos revisar el catálogo y luego me golpea! ¿No sería genial si pudiera almacenar los datos tal como aparecen en el catálogo? Solo recopilaciones de registros de cada producto que solo enumera el atributo de ese producto. A continuación, puede seleccionar atributos comunes para indexar para su recuperación en una fecha posterior. Por supuesto, eso es una tienda de documentos.

En resumen, las tiendas de documentos son geniales cuando tiene un problema de matriz dispersa u objetos que mutan sus atributos a lo largo del tiempo. Habiendo vivido en un mundo sin SQL durante 2 años, no puedo pensar en una aplicación del mundo real que no tenga esas características porque el mundo en sí parece una tienda de documentos.