¿Hay algo innovador sobre NoSQL? [cerrado]

Soy un tipo de base de datos relacional muy sólido y entiendo todo el camino hasta la tercera forma normal, aprecio las raíces de la teoría de conjuntos algebraicos de SQL y probablemente pueda relacionalizar un corazón roto (o no).

No he descubierto una estructura de base de datos relacional PARA las noches de citas con mi esposa, pero HE pensado en proyectos de bases de datos relacionales para las noches de citas con mi esposa.

Ahora estoy escuchando sobre NoSQL e investigándolo. Para ir al grano, ¿hay algo sobre NoSQL que sea innovador, matemáticamente novedoso o un "oye, realmente no necesitas organizar tus datos relacionalmente, este es un enfoque mucho más fácil"?

¿Es NoSQL como un super shell para la estructura de datos? En mi opinión, los datos deben tener una estructura para ser recuperados y la recuperación debe definirse en un lenguaje de algún tipo.

NoSQL es más evolutivo que revolucionario. Básicamente combina las ideas existentes de "almacenamiento de bases de datos externas" con "el uso de estructuras de datos familiares, no tablas relacionales".

Hay más tipos de bases de datos que relacionales, por ejemplo , bases de datos jerárquicas . Si bien es arcaico para los estándares actuales, encaja muy bien con las estructuras de datos de sus datos (por ejemplo, registros COBOL ). El punto es que los datos en la base de datos se modelaron de cerca a la forma en que se presentaron los registros en los lenguajes de programación que los usaron.

Avancemos rápidamente a la invención de bases de datos relacionales , donde finalmente la base de datos separó las preocupaciones y, cuando se normalizó adecuadamente, es una excelente manera de visualizar la mayoría de los tipos de datos y las relaciones entre los datos. Es realmente fácil de entender en comparación con otros tipos de bases de datos. Sin embargo, lo que falla es almacenar datos de una manera que refleje objetos y clases en un programa. Por lo tanto, la invención del mapeo objeto-relacional . En otras palabras, el diseño de la base de datos es en realidad un obstáculo para el diseño del programa que lo utiliza, por lo que necesitamos bibliotecas ORM como Hibernate. Si bien es limpio y consistente, siempre hay esa persistente duda en el fondo de mi mente de que algo no está del todo bien.

Esto dio lugar a dos tipos más de bases de datos, bases de datos de objetos y NoSQL .

Ambos intentan resolver los problemas introducidos por las bases de datos relacionales sin exponernos a los horrores alucinantes de las bases de datos jerárquicas. Los datos todavía se presentan en repositorios que se asemejan vagamente a tablas, pero en realidad son más como estructuras de datos de programación que tablas relacionales. Si bien las bases de datos de objetos siguen principalmente reglas bien definidas, entiendo que NoSQL es bastante arbitrario. Por ejemplo, una tabla puede visualizarse como una tabla hash o una matriz. No existe una manera fácil y bien definida de consultarlos utilizando una herramienta arbitraria análoga a Oracle SQL Developer o SQL Server Management Studio .

La idea es que uno pueda definir estructuras de datos que se busquen fácilmente en el código, en lugar de juntar consultas SQL que se adapten mejor a un motor de base de datos SQL en lugar de expresar la consulta que uno desea. Por ejemplo, las coincidencias difusas o parciales son más difíciles y funcionan peor en una base de datos relacional, mientras que una base de datos NoSQL puede tener una estructura que está optimizada para dicha búsqueda y se completa en una fracción del tiempo.

Hay lenguajes para consultar NoSQL. Sin embargo, no existe un lenguaje universal como el SQL para las bases de datos relacionales.

Edición tardía:

Si bien estoy lo suficientemente familiarizado con las bases de datos NoSQL, esta pregunta fue el impulso para comprar un libro de calidad sobre el tema y comenzar a leerlo con el objetivo final de ser un verdadero experto en el tema. Los comentarios restantes se basan en NoSQL Distilled: una breve guía para el mundo emergente de la persistencia políglota por Pramod Sadalage y Martin Fowler .

Los autores afirman que las bases de datos relacionales no se adaptan bien a los clústeres capaces de servir los datos necesarios para sitios como Amazon y Google: NoSQL se desarrolló para ajustarse a este nicho, relajando la concurrencia y la durabilidad en ACID para atender un gran número de consultas que utiliza en gran medida datos estáticos (por lo tanto, las transacciones ACID no son tan importantes).

Además, afirman que las bases de datos NoSQL operan sin un esquema (página 10) que permite que las bases de datos NoSQL modifiquen la estructura de datos más fácilmente. No estoy seguro de que la presencia o ausencia de un esquema formal sea importante a este respecto, ya que las bases de datos SQL también permiten modificar esquemas. En cualquier caso, los dos autores de renombre hacen el reclamo, por lo que vale la pena examinarlo.

Creo que estos dos puntos principales sirven solo para imponer mi punto principal de que NoSQL es evolutivo, no revolucionario. Todavía almacenan datos y realizan mejoras incrementales en la escala y modificabilidad. También señalan que NoSQL no busca usurpar bases de datos relacionales como el rey del almacenamiento de datos, solo para proporcionar un medio alternativo de almacenamiento de datos para los tipos de datos que necesitan escalar y transformarse de una manera que (creen) relacional Las bases de datos no son lo suficientemente compatibles.

Creo que definitivamente le gustaría ver este artículo de Erik Meijer y Gavin Bierman, titulado "Contrariamente a la creencia popular, SQL y NoSQL son en realidad solo dos caras de la misma moneda" . En resumen, afirma que matemáticamente hablando ambos enfoques se basan en la misma teoría, pero con algunas diferencias.

Un par de diferencias interesantes son, en mi opinión, las siguientes: la dirección de las dependencias de tipo cruzado (FK en SQL) es lo opuesto en SQL y NoSQL y el tipo de colecciones no se limita a establecer en NoSQL (y, por lo tanto, algunas operaciones teóricas de conjunto Es posible que ya no se aplique en el mundo NoSQL, pero algunos otros todavía son válidos). Otro punto interesante del artículo es el lenguaje de consulta único propuesto para consultar bases de datos SQL y NoSQL. Se llama LINQ, y si crees haber escuchado este nombre antes, estás en lo correcto: ese es el lenguaje de consulta de Microsoft de C #.

La respuesta de Snowman describe correctamente cómo SQL y NoSQL difieren en sus estructuras de datos y cómo se accede a ellas. Sin embargo, una diferencia probablemente aún más importante es su respectivo dominio del problema.

NoSQL no es un sucesor de SQL. Más bien, las diversas ramas de NoSQL sacrifican algunas cualidades de SQL para ser mejores en otras . El teorema de CAP establece que es imposible para cualquier sistema de base de datos distribuido satisfacer todas las siguientes propiedades:

• Consistencia
• Disponibilidad
• Tolerancia de partición

Por lo tanto, algunas variantes NoSQL siguen el principio BASE , que relaja la restricción de consistencia siempre completa de ACID , que es la base de las bases de datos SQL clásicas. Al perder algunas garantías de coherencia, obtienen la posibilidad de combinar alta disponibilidad y tolerancia de partición en sistemas ampliamente distribuidos, como los sitios web con grandes cantidades de datos y consultas de usuarios, pero poca demanda de coherencia perfecta. Por lo tanto, dichas bases de datos NoSQL están en el corazón de Google , Facebook y Amazon . Por lo tanto, para responder a su pregunta: Sí, NoSQL es innovador ya que prácticamente permite servicios web tan masivos.

Este es solo un ejemplo, ya que NoSQL es un campo diverso, y sus variantes cubren casi todas las combinaciones posibles de parámetros dentro del triángulo CAP .

Los casos de uso comunes de NoSQL son innovadores en sus ganancias de productividad en comparación con las bases de datos comunes basadas en SQL. Hay varios factores en esto.

Una es la limpieza. La mayoría de los NoSQL son de código abierto y se pueden instalar en una estación de trabajo o una VM con algunos comandos, y funcionan con valores predeterminados razonables listos para usar. En mi experiencia, incluso Postgres y MySQL no son así; La configuración suele ser necesaria para comenzar incluso en una estación de trabajo con fines de desarrollo.

Otro es el desarrollo conveniente, ya que otras respuestas han descrito en detalle. Las capacidades de indexación JSON de Mongo, o la semántica de clave / valor de redis y Riak, pueden ser ciertas ciertas aplicaciones web necesarias para hacer el trabajo, y las API son fáciles. Algunos NoSQL proporcionan sus propias API RESTful, mientras que con SQL generalmente tiene que escribirlas usted mismo.

Estos factores hacen que las bases de datos NoSQL sean atractivas para proyectos a pequeña escala. El tiempo de recogida tiende a ser bajo. Claro, cuando va a producción tiene que configurar la seguridad y la escala, pero la capacidad de comenzar a codificar y colaborar rápidamente es poderosa y, en mi opinión, innovadora.

Además, en relación con lo anterior, para aplicaciones a pequeña escala (como servicios internos de la empresa o de aplicación a aplicación), un equipo puede ser capaz de poner en marcha una base de datos NoSQL de producción sin involucrar a sus equipos de DBA y sin sufrir rendimiento o integridad problemas como resultado. Puede que a los DBA profesionales no les guste esto, pero los desarrolladores que ven a los DBA como una fuente de obstrucción (correcta o incorrecta) a veces ven a NoSQL como una forma de evitar tener que lidiar con ellos. Lo confieso: una vez cambié una aplicación a pequeña escala de Postgres a SQLite para eliminar el DBA adversario, y elegí implementarlo en Mongo en lugar de Oracle para evitar los procesos de aprobación de DBA y las restricciones de acceso. Sin consecuencias adversas en ninguno de los casos.