¿Qué es NoSQL, cómo funciona y qué beneficios ofrece? [cerrado]


168

He estado escuchando cosas sobre NoSQL y que eventualmente puede convertirse en el reemplazo de los métodos de almacenamiento de SQL DB debido al hecho de que la interacción de DB es a menudo un cuello de botella para la velocidad en la web.

Así que solo tengo algunas preguntas:

  1. ¿Qué es exactamente?

  2. ¿Como funciona?

  3. ¿Por qué sería mejor que usar una base de datos SQL? ¿Y cuanto mejor es?

  4. ¿La tecnología es demasiado nueva para comenzar a implementar todavía o vale la pena echarle un vistazo?


Muchas buenas respuestas aquí. También encontré respuestas útiles sobre otras preguntas similares: (1.) más de 150 votos a favor sin sql explicados con una metáfora del automóvil y muchas referencias (2.) más de 70 upvtes nosql explicados con la historia explicando cómo / por qué se creó nosql y un poco sobre por qué existe hoy
Trevor Boyd Smith

Respuestas:


110
  1. ¿Qué es exactamente?

    Por un lado, un sistema específico , pero también se ha convertido en una palabra genérica para una variedad de backends de almacenamiento de datos nuevos que no siguen el modelo de base de datos relacional.

  2. ¿Como funciona?

    Cada uno de los sistemas etiquetados con el nombre genérico funciona de manera diferente, pero la idea básica es ofrecer una mejor escalabilidad y rendimiento mediante el uso de modelos de base de datos que no admitan toda la funcionalidad de un RDBMS genérico, pero aún así suficiente funcionalidad para ser útil. En cierto modo, es como MySQL, que en un momento carecía de soporte para transacciones pero, precisamente por eso, logró superar a otros sistemas de base de datos. Si pudieras escribir tu aplicación de una manera que no requiriera transacciones, sería genial.

  3. ¿Por qué sería mejor que usar una base de datos SQL? ¿Y cuanto mejor es?

    Sería mejor cuando su sitio necesita escalar tan enormemente que el mejor RDBMS que se ejecuta en el mejor hardware que puede permitirse y optimizado tanto como sea posible simplemente no puede mantenerse al día con la carga. Cuánto mejor depende del caso de uso específico (mucha actividad de actualización combinada con muchas combinaciones es muy difícil en los RDBMS "tradicionales"), podría ser un factor de 1000 en casos extremos.

  4. ¿La tecnología es demasiado nueva para comenzar a implementar todavía o vale la pena echarle un vistazo?

    Depende principalmente de lo que intentes lograr. Ciertamente es lo suficientemente maduro para usar. Pero pocas aplicaciones realmente necesitan escalar eso masivamente. Para la mayoría, un RDBMS tradicional es suficiente. Sin embargo, con el uso de Internet cada vez más omnipresente todo el tiempo, es muy probable que las aplicaciones que lo hacen se vuelvan más comunes (aunque probablemente no dominantes).


2
¿Qué se entiende por transaction?
Shawn Mclean el


El enlace "variedad de backends de almacenamiento de datos nuevos" está
inactivo

1
@csguy gracias, reemplazado por uno menos propenso a desaparecer
Michael Borgwardt

135

¡No hay tal cosa como NoSQL!

NoSQL es una palabra de moda.

Durante décadas, cuando la gente hablaba de bases de datos, se referían a bases de datos relacionales. Y cuando la gente hablaba de bases de datos relacionales, se referían a las que controlas con el lenguaje de consulta estructurado de Edgar F. Codd. ¿Almacenar datos de alguna otra manera? ¡Locura! Cualquier otra cosa son solo archivos planos.

Pero en los últimos años, la gente comenzó a cuestionar este dogma. La gente se preguntaba si las tablas con filas y columnas son realmente la única forma de representar datos. La gente comenzó a pensar y codificar, y se le ocurrieron muchos conceptos nuevos sobre cómo se podrían organizar los datos. Y comenzaron a crear nuevos sistemas de bases de datos diseñados para estas nuevas formas de trabajar con datos.

Las filosofías de todas estas bases de datos eran diferentes. Pero una cosa que todas estas bases de datos tenían en común era que el lenguaje de consulta estructurado ya no era adecuado para usarlas. Entonces, cada base de datos reemplazó SQL con sus propios lenguajes de consulta. Y así nació el término NoSQL, como una etiqueta para todas las tecnologías de bases de datos que desafían el modelo clásico de base de datos relacional.

Entonces, ¿qué tienen en común las bases de datos NoSQL?

En realidad, no mucho.

A menudo escuchas frases como:

  • ¡NoSQL es escalable!
  • ¡NoSQL es para BigData!
  • NoSQL viola ACID!
  • ¡NoSQL es un almacén de clave / valor glorificado!

¿Es eso cierto? Bueno, algunas de estas afirmaciones pueden ser ciertas para algunas bases de datos comúnmente llamadas NoSQL, pero cada una también es falsa para al menos otra. En realidad, lo único que tienen en común las bases de datos NoSQL es que son bases de datos que no usan SQL. Eso es. Lo único que los define es lo que los distingue unos de otros.

Entonces, ¿qué diferencia a las bases de datos NoSQL?

Así que dejamos en claro que todas esas bases de datos comúnmente conocidas como NoSQL son demasiado diferentes para evaluarlas juntas. Cada uno de ellos necesita ser evaluado por separado para decidir si son adecuados para resolver un problema específico. ¿Pero por dónde empezamos? Afortunadamente, las bases de datos NoSQL se pueden agrupar en ciertas categorías, que son adecuadas para diferentes casos de uso:

Orientado a documentos

Ejemplos: MongoDB, CouchDB

Fortalezas: datos heterogéneos, trabajo orientado a objetos, desarrollo ágil

Su ventaja es que no requieren una estructura de datos coherente. Son útiles cuando sus requisitos y, por lo tanto, el diseño de su base de datos cambia constantemente, o cuando se trata de conjuntos de datos que pertenecen juntos pero que aún se ven de manera muy diferente. Cuando tiene muchas tablas con dos columnas llamadas "clave" y "valor", entonces vale la pena analizarlas.

Bases de datos gráficas

Ejemplos: Neo4j, GiraffeDB.

Fortalezas: minería de datos

Si bien la mayoría de las bases de datos NoSQL abandonan el concepto de gestión de relaciones de datos, estas bases de datos lo abarcan aún más que las llamadas bases de datos relacionales.

Su objetivo es definir datos por su relación con otros datos. Cuando tiene muchas tablas con claves primarias que son las claves primarias de otras dos tablas (y tal vez algunos datos que describen la relación entre ellas), entonces estas podrían ser algo para usted.

Tiendas de valor clave

Ejemplos: Redis, Cassandra, MemcacheDB

Fortalezas: Búsqueda rápida de valores por claves conocidas

Son muy simplistas, pero eso los hace rápidos y fáciles de usar. Cuando no necesita procedimientos almacenados, restricciones, disparadores y todas esas características avanzadas de la base de datos y solo desea un almacenamiento y recuperación rápidos de sus datos, entonces esos son para usted.

Lamentablemente, suponen que sabes exactamente lo que estás buscando. ¿Necesitas el perfil de Usuario157641? No hay problema, solo tomará microsegundos. Pero, ¿qué sucede cuando desea los nombres de todos los usuarios que tienen entre 16 y 24 años de edad, que tienen "waffles" como su comida favorita y han iniciado sesión en las últimas 24 horas? Mala suerte Cuando no tiene una clave definida y única para un resultado específico, no puede sacarla de su tienda KV tan fácilmente.

¿SQL está obsoleto?

Algunos defensores de NoSQL afirman que su base de datos NoSQL favorita es la nueva forma de hacer las cosas, y SQL es cosa del pasado.

¿Tienen razón?

No, por supuesto que no lo son. Si bien hay problemas para los que SQL no es adecuado, todavía tiene sus puntos fuertes. Muchos modelos de datos simplemente se representan mejor como una colección de tablas que se refieren entre sí. Especialmente porque la mayoría de los programadores de bases de datos fueron entrenados durante décadas para pensar en los datos de una manera relacional, y tratar de presionar esta mentalidad en una nueva tecnología que no fue creada para ello rara vez termina bien.

Las bases de datos NoSQL no son un reemplazo para SQL, son una alternativa.

La mayoría de los ecosistemas de software en torno a las diferentes bases de datos NoSQL aún no son tan maduros. Si bien hay avances, aún no tiene herramientas adicionales que sean tan maduras y potentes como las disponibles para las bases de datos SQL populares.

Además, hay muchos más conocimientos para SQL. Generaciones de informáticos han dedicado décadas de sus carreras a la investigación centrándose en bases de datos relacionales, y muestra: La literatura escrita sobre bases de datos SQL y modelos de datos relacionales, tanto prácticos como teóricos, podría llenar múltiples bibliotecas llenas de libros. Cómo construir una base de datos relacional para sus datos es un tema tan bien investigado que es difícil encontrar un caso en el que no haya una práctica recomendada generalmente aceptada por el libro.

La mayoría de las bases de datos NoSQL, por otro lado, todavía están en su infancia. Todavía estamos descubriendo la mejor manera de usarlos.


Supongo que la respuesta a la pregunta ¿NoSQL significa base de datos no relacional? es No porque las bases de datos Graph también son NoSQL y son relacionales. ¿Correcto?
tomasb

1
@tomasb Depende de cómo se defina la "base de datos relacional". En las bases de datos de gráficos, las relaciones son aún más importantes que en aquellas bases de datos que generalmente se llaman relacionales.
Philipp

"No hay problema, solo tomará microsegundos". - ¿No puedo obtener el mismo rendimiento de lectura no transaccional en, por ejemplo, psql?
Nakilon

2
Buena respuesta, redactada casi exactamente como Adam Ruins todo, excepto "Philipp Ruins noSQL" ;-)
JGlass

2
Esta debería ser la mejor respuesta.

28

Como alguien dijo que mi publicación anterior estaba fuera de tema, trataré de compensar :-) NoSQL no tiene la intención, y nunca tuvo la intención de ser, de reemplazar a las bases de datos SQL más comunes, pero hay un par de palabras para obtener cosas en la perspectiva correcta.

En el corazón mismo de la filosofía NoSQL se encuentra la consideración de que, posiblemente por razones comerciales y de portabilidad, los motores SQL tienden a ignorar el tremendo poder del sistema operativo UNIX y sus derivados.

Con una base de datos basada en un sistema de archivos, puede aprovechar de inmediato las capacidades y el poder cada vez mayores del sistema operativo subyacente, que han aumentado constantemente durante muchos años de acuerdo con la ley de Moore. Con este enfoque, muchos comandos del sistema operativo se convierten automáticamente también en "operadores de bases de datos" (piense en "ls" "sort", "find" y las otras innumerables utilidades de shell de UNIX).

Con esto en mente, y un poco de creatividad, puede idear una base de datos basada en un sistema de archivos que sea capaz de superar las limitaciones de muchos motores SQL comunes, al menos para patrones de uso específicos, que es el punto central de la filosofía de NoSQL, la como yo lo veo.

Ejecuto cientos de sitios web y todos usan NoSQL en mayor o menor medida. De hecho, no alojan grandes cantidades de datos, pero incluso si algunos de ellos lo hicieran, probablemente podría pensar en un uso creativo de NoSQL y el sistema de archivos para superar cualquier cuello de botella. Algo que probablemente sería más difícil con las "cárceles" tradicionales de SQL. Le insto a que busque en Google "unix", "manis" y "shaffer" para que entienda lo que quiero decir.


9

Si recuerdo correctamente, se refiere a tipos de bases de datos que no necesariamente siguen la forma relacional. Me vienen a la mente las bases de datos de documentos, las bases de datos sin una estructura específica y que no usan SQL como un lenguaje de consulta específico.

Generalmente es más adecuado para aplicaciones web que dependen del rendimiento de la base de datos y no necesitan características más avanzadas de los motores de base de datos de relaciones. Por ejemplo, un almacén de clave-> valor que proporciona una consulta simple por interfaz de identificación podría ser 10-100x más rápido que la implementación del servidor SQL correspondiente, con un menor costo de mantenimiento del desarrollador.

Un ejemplo es este documento para un Almacén de tuplas OLTP , que sacrificó las transacciones para el procesamiento de un solo subproceso (sin problema de concurrencia porque no se permite la concurrencia), y mantuvo todos los datos en la memoria; lograr un rendimiento 10-100x mejor en comparación con un sistema similar RDBMS . Básicamente, se está alejando de la vista 'One Size Fits All' de SQL y sistemas de bases de datos.


1
Su primer enlace que se refiere al significado de NoSQL (etiquetado "esto") parece estar muerto, corríjalo.
jobin

7

En la práctica, NoSQL es un sistema de base de datos que admite el acceso rápido a objetos binarios grandes (docs, jpgs, etc.) utilizando una estrategia de acceso basada en claves. Esta es una desviación del acceso SQL tradicional que solo es lo suficientemente bueno para los valores alfanuméricos. No solo la estrategia de acceso y almacenamiento interno, sino también la sintaxis y las limitaciones en el formato de visualización restringen el SQL tradicional. Las implementaciones BLOB de las bases de datos relacionales tradicionales también sufren estas restricciones.

Detrás de la escena es una admisión indirecta de la falla del modelo SQL para soportar cualquier forma de OLTP o soporte para nuevos formatos de datos. "Soporte" significa no solo almacenar sino también capacidades de acceso completo: mediante programación y consultas utilizando el modelo estándar.

¡Los entusiastas relacionales modificaron rápidamente la definición de NoSQL de Not-SQL a Not-Only-SQL para mantener SQL en la imagen! Esto no es bueno, especialmente cuando vemos que la mayoría de los programas Java hoy recurren a la asignación ORM del modelo relacional subyacente. Un nuevo concepto debe tener una definición clara. De lo contrario, terminará como SOA.

La base de los sistemas NoSQL reside en el par clave-valor aleatorio. pero esto no es nuevo. Los sistemas de bases de datos tradicionales como IMS e IDMS admitían claves ramdom hash (sin hacer uso de ningún índice) y aún lo hacen. De hecho, IDMS ya tiene una palabra clave NONSQL donde admiten el acceso SQL a su base de datos de red más antigua que denominaron como NONSQL.


5

Es como el jacuzzi: tanto una marca como un nombre genérico. No es solo una tecnología específica, sino más bien un tipo específico de tecnología, en este caso refiriéndose a "bases de datos" a gran escala (a menudo dispersas) como BigTable o CouchDB de Google.


5

NoSQL, el programa real parece ser una base de datos relacional implementada en awk usando archivos planos en el backend. Aunque profesan, "NoSQL esencialmente no tiene límites arbitrarios, y puede funcionar donde otros productos no pueden. Por ejemplo, no hay límite en el tamaño del campo de datos, el número de columnas o el tamaño del archivo", no creo que sea La base de datos a gran escala del futuro.

Como dice Joel, las bases de datos masivamente escalables como BigTable o HBase son mucho más interesantes. GQL es el lenguaje de consulta asociado con BigTable y App Engine. En gran medida, se modificó SQL para evitar características que Google considera cuellos de botella (como uniones). Sin embargo, no he oído hablar de esto como "NoSQL" antes.


5

NoSQL es un sistema de base de datos que no utiliza consultas SQL basadas en cadenas para obtener datos.

En su lugar, crea consultas utilizando una API que proporcionarán, por ejemplo, Amazon DynamoDB es un buen ejemplo de una base de datos NoSQL.

Las bases de datos NoSQL son mejores para aplicaciones grandes donde la escalabilidad es importante.


1

¿NoSQL significa base de datos no relacional?

Sí, NoSQL es diferente de RDBMS y OLAP. Utiliza modelos de consistencia más flexibles que las bases de datos relacionales tradicionales.

Los modelos de consistencia se usan en sistemas distribuidos como sistemas de memoria compartida distribuida o almacén de datos distribuidos.

¿Cómo funciona internamente?

Los sistemas de bases de datos NoSQL a menudo están altamente optimizados para operaciones de recuperación y anexos, y a menudo ofrecen poca funcionalidad más allá del almacenamiento de registros (por ejemplo, almacenes de valores clave). La flexibilidad reducida del tiempo de ejecución en comparación con los sistemas SQL completos se compensa con ganancias marcadas en escalabilidad y rendimiento para ciertos modelos de datos.

Puede funcionar en datos estructurados y no estructurados. Utiliza colecciones en lugar de tablas

¿Cómo se consulta dicha "base de datos"?

Vea SQL vs NoSQL: Battle of the Backends ; Lo explica todo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.