database - example - nosql descargar

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

He estado escuchando mucho sobre sistemas de bases de datos sin esquema (a menudo distribuidos) como MongoDB, CouchDB, SimpleDB, etc.

Si bien puedo entender que pueden ser valiosos para algunos propósitos, en la mayoría de mis aplicaciones estoy tratando de persistir objetos que tienen un número específico de campos de un tipo específico, y solo pienso automáticamente 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 sencillas interfaces JSON / RESTful de estos nuevos sistemas, no entiendo cómo los valores hash de clave / valor tipeados libremente 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 en el 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.

La principal preocupación debería ser qué necesitas 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 NOSQL o sin NOSQL .

La mayoría de los entornos que conozco usando soluciones NOSQL también usan una solución RDBMS de alguna forma o 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 está basado en transacciones, pero necesita escalar o escalar rápidamente, una solución NOSQL puede ser deseable.

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)

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

No digo que no tengan un uso válido ... simplemente dicen 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.

Schemaless es genial por dos razones:

Cerebro optimizando la intuición del almacenamiento de documentos
Resuelve los problemas de almacenamiento de Sparse-Matrix y Entity-Attribute-Value .

He usado 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, ja! Otro seguidor de la tendencia que no sabe nada y se sube al ú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 para optimizar el cerebro fue mi experiencia con el sistema de comercio electrónico de Magento. 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:

nombre del producto
Precio
Tipo de producto (

Luego se hace más difícil y se cubre con notas, códigos de colores y enlaces a otras tablas (sí ... relaciones)

Color (solo algunos productos)
Tamaño (X grande, grande, pequeño): solo para productos 8''9''10, los palos de golf usan una escala diferente
Color 2. Los collares de gato tienen dos opciones de color.
Potencia
Tipo de fijación (hombre, mujer)

Por lo tanto, termina en un terrible lío de tablas de Excel que no tienen sentido para mí y no tienen mucho sentido para las personas que trabajan con los productos día tras día. ¡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.

Solo jugué con MongoDB, pero una cosa que realmente me interesaba era cómo 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.

Voy a mencionar una o dos razones comunes (estoy seguro de que la gente va a escribir respuestas de ensayo)

Con sistemas altamente distribuidos, cualquier conjunto de datos dado puede distribuirse en varios servidores. Cuando eso sucede, las restricciones relacionales que el motor de DB puede garantizar se reducen en gran medida. Parte de su integridad referencial deberá manejarse en el código de la aplicación. Al hacerlo, descubrirá rápidamente varios puntos dolorosos:
- su lógica se extiende a través de múltiples capas (aplicación y db)
- su lógica se extiende a través de múltiples idiomas (SQL y el idioma de su aplicación preferido)
El resultado es que la lógica está menos encapsulada, es 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.
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.
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.
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 licencias de base de datos pueden alcanzar o superar los costos de hardware. Los costos son lo suficientemente altos como para cambiar drásticamente las consideraciones normales de compilación / compra hacia la creación de una solución personalizada además de una oferta OSS (todas las ofertas significativas de NOSQL son OSS)