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.