¿El uso de las bases de datos NoSQL no es práctico para grandes conjuntos de datos donde necesita buscar por contenido?

51

He estado aprendiendo sobre las bases de datos NoSQL durante una semana.

Realmente entiendo las ventajas de las bases de datos NoSQL y los muchos casos de uso para los que son excelentes.

Pero a menudo las personas escriben sus artículos como si NoSQL pudiera reemplazar las Bases de datos relacionales. Y hay un punto en el que no puedo entender:

Las bases de datos NoSQL son (a menudo) almacenes de valores clave.

Por supuesto, es posible almacenar todo en un almacén de valores clave (codificando los datos en JSON, XML, lo que sea), pero el problema que veo es que necesita obtener una cantidad de datos que coincida con un criterio específico, en muchos casos de uso En una base de datos NoSQL, solo tiene un criterio que puede buscar de manera efectiva: la clave. Las bases de datos relacionales están optimizadas para buscar cualquier valor en la fila de datos de manera efectiva.

Por lo tanto, las bases de datos NoSQL no son realmente una opción para los datos persistentes que necesitan ser buscados por su contenido. ¿O he entendido mal algo?

Un ejemplo:

Necesita almacenar datos de usuario para una tienda web.

En una base de datos relacional, almacena a cada usuario como una fila en la userstabla, con un ID, el nombre, su país, etc.

En una base de datos NoSQL, almacenaría a cada usuario con su ID como clave y todos sus datos (codificados en JSON, etc.) como valor.

Entonces, si necesita obtener todos los usuarios de un país específico (por alguna razón, los expertos en marketing necesitan saber algo sobre ellos), es fácil hacerlo en la Base de datos relacional, pero no es muy efectivo en la Base de datos NoSQL, porque tiene que obtener todos los usuarios, analizar todos los datos y filtrar.

No digo que sea imposible , pero se vuelve mucho más complicado y supongo que no es tan efectivo si desea buscar en los datos de las entradas NoSQL.

Puede crear una clave para cada país que almacena las claves de cada usuario que vive en este país, y obtener los usuarios de un país específico obteniendo todas las claves que se depositan en la clave de este país. Pero creo que esta técnica hace que un conjunto de datos complejo sea aún más complejo: es más difícil de implementar y no tan efectivo como consultar una base de datos SQL. Así que creo que no es una forma en la que usarías en la producción. ¿O es eso?

No estoy realmente seguro si entendí mal algo o si pasé por alto algunos conceptos o mejores prácticas para manejar tales casos de uso. Tal vez podría corregir mis declaraciones y responder mis preguntas.

Leo Lindhorst
fuente
16
Esto se lee más como una queja que como una pregunta. Parece que tiene una buena comprensión de las ventajas y desventajas del almacenamiento de valores clave frente a los relacionales. Entonces, ¿cuál es exactamente la pregunta?
JacquesB
16
No es una diatriba en absoluto :) Las bases de datos NoSQL son increíbles, pero creo que las bases de datos relacionales no son tan malas como algunas personas afirman. Solo quiero descubrir, si mi tesis, que las bases de datos NoSQL no son la mejor opción si se trata de buscar en 'datarows' ... o si no entendí el tema correctamente.
Leo Lindhorst
2
programmers.stackexchange.com/q/54373/17853
Lightness compite con Monica el
55
¡Pero MongoDB es Webscale ! [advertencia: incluye algo de lenguaje NSFW]
Jerry Coffin
55
@DevWurm: No debes combinar las tiendas de valores clave con NoSQL en general. Por ejemplo, Google BigTable se considera una base de datos NoSQL, pero aún puede buscar y crear índices en múltiples campos. Un almacén de valores clave es apropiado cuando sabe que solo necesita buscar en un solo campo (la clave).
JacquesB

Respuestas:

40

Si bien estoy de acuerdo con su premisa de que NoSQL no es una panacea para todos los problemas de la base de datos, creo que entiende mal un punto clave.

En la base de datos NoSQL, solo tiene un criterio que puede buscar eficazmente: la clave.

Esto claramente no es cierto.

Por ejemplo, MongoDB admite índices. (de https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Los índices admiten la ejecución eficiente de consultas en MongoDB. Sin índices, MongoDB debe realizar un escaneo de colección, es decir, escanear cada documento de una colección, para seleccionar aquellos documentos que coincidan con la declaración de consulta. Si existe un índice apropiado para una consulta, MongoDB puede usar el índice para limitar la cantidad de documentos que debe inspeccionar.

Los índices son estructuras de datos especiales [1] que almacenan una pequeña porción del conjunto de datos de la colección en una forma fácil de recorrer. El índice almacena el valor de un campo específico o conjunto de campos, ordenados por el valor del campo. El orden de las entradas de índice admite coincidencias de igualdad eficientes y operaciones de consulta basadas en rangos. Además, MongoDB puede devolver resultados ordenados utilizando el orden en el índice.

Al igual que couchbase (de http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Las vistas de Couchbase permiten la indexación y consulta de datos.

Una vista crea un índice en los datos de acuerdo con el formato y la estructura definidos. La vista consta de campos específicos e información extraída de los objetos en Couchbase.

De hecho, cualquier cosa que se llame a sí misma una base de datos NoSQL en lugar de un almacén de valores clave debería admitir algún tipo de esquemas de indexación.

De hecho, a menudo es la flexibilidad de estos esquemas de índice lo que hace que NoSQL brille. En mi opinión, el lenguaje utilizado para definir los índices NoSQL a menudo es más expresivo o natural que SQL, y dado que generalmente viven fuera de la tabla, no es necesario cambiar los esquemas de la tabla para admitirlos. (No quiere decir que no pueda hacer cosas similares en SQL, pero para mí parece que hay muchos más saltos de aro involucrados).

Michael Anderson
fuente
13
"... ya que generalmente viven fuera de la mesa, no necesitas cambiar los esquemas de tu mesa para admitirlos". Esa es la misma situación entre un índice no agrupado en una base de datos SQL y un índice para una base de datos noSQL, ¿verdad?
Jirka Hanika
Respuesta bastante sólida. Agregaría que NoSQL se basa en la idea de que si desea ir más rápido, debe realizar solicitudes de 90% ++ por una clave principal sin una combinación, y si desea hacer algo más, está en el mundo de escaneos de tablas e índices secundarios, que siempre tienen límites de rendimiento y escala. Una vez que está buscando un índice, o ha creado un grupo, simplemente no está en el área donde se puede alcanzar la velocidad (a excepción de pequeños conjuntos de datos de unos pocos millones de filas). Si codifica en el estilo donde las búsquedas alternativas son raras, terminará con un sistema operativo muy sólido.
Brian Bulkowski
40

En términos generales, si su flujo de trabajo es una combinación perfecta para consultas de bases de datos relacionales, encontrará que las bases de datos relacionales son el enfoque más eficiente. Es un poco tautológico, pero es cierto.

La afirmación que harían muchos defensores de NoSQL es que muchos flujos de trabajo realmente se aplicaron en forma relacional, y habrían sido más efectivos antes de tal masaje. La validez de esta afirmación es complicada de determinar. Claramente, hay trabajos que están muy bien descritos por las consultas SQL. Puedo decir por experiencia que mis tareas particulares de programación relacional podrían haberse realizado utilizando NoSQL con casi el mismo nivel de eficiencia, si no más. Sin embargo, esa es una declaración muy subjetiva basada en una experiencia limitada.

Tengo la sensación de que gran parte de la venta del enfoque NoSQL proviene de la suposición de grandes bases de datos. Cuanto más grande es la base de datos, más debe preparar su flujo de trabajo para admitir los conjuntos de datos más grandes. NoSQL parece ser mejor para apoyar ese esfuerzo de preparación. Por lo tanto, cuanto más grande es la base de datos, más importantes pueden ser las características de NoSQL.

Para usar el ejemplo, en SQL las consultas por país son tan lentas como el análisis NoSQL de todos los usuarios, a menos que explícitamente le indique a SQL que indexe la userstabla por país. NoSQL puede hacer lo mismo, donde crea una colección ordenada de clave-valor que es el índice (al igual que SQL lo hace bajo el capó) y la mantiene.

¿La diferencia? Los motores SQL tenían el concepto de indexar la tabla integrada. Esto significa que debe hacer menos trabajo (todo lo que tenía que hacer era agregar un índice a la tabla). Sin embargo, también significa que tenía menos control. Para la mayoría de los casos, esa pérdida de control es aceptable, a cambio de que el motor SQL haga el trabajo por usted. Sin embargo, en conjuntos de datos masivos, es posible que desee un modelo de coherencia diferente que el modelo típico de SQL ACID. Es posible que desee utilizar el modelo BASE que admite la coherencia eventual. Eso podría ser muy difícil en SQL, porque el motor SQL está haciendo el trabajo por usted, por lo que tiene que hacerlo según las reglas del motor SQL. En NoSQL, esas capas generalmente están expuestas, lo que le permite piratearlas.

Cort Ammon
fuente
2
En su ejemplo, usted afirma que " las consultas SQL por país son tan lentas como la exploración NoSQL de todos los usuarios ". ¿Tienes evidencia para apoyar esto? El NoSQL descrito en la pregunta es un par clave-valor, por lo que tendría que escanear el valor para obtener la ubicación del país y luego hacer la comparación. SQL ya sabe dónde están esos datos, por lo que puede seleccionarlos directamente desde el disco (omitiendo lo que no es necesario), luego verifique el valor. Si el país es una clave externa, es una comparación rápida de enteros. Esto no siempre será más rápido, ya que extrae menos del disco y la comprobación es más rápida.
Trisped
1
@Trisped Es difícil proporcionar evidencia, porque NoSQL es un enfoque, no un producto (lo mismo para SQL). Sin embargo, vale la pena señalar que BigTable, una implementación de NoSQL, tiene un concepto de columnas, al igual que las tablas SQL. Es el concepto de columnas que le permite omitir datos al saber dónde buscar, que se puede aplicar a cualquier implementación.
Cort Ammon
16

NoSQL es un término bastante vago, ya que básicamente cubre todos los sistemas de bases de datos que no son relacionales.

Lo que describe es un almacén de valores clave , que es un tipo de base de datos donde se almacena un blob de datos bajo una clave, y se puede buscar rápidamente si conoce la clave. Estas bases de datos son increíblemente rápidas si conoce la clave exacta, pero como usted mismo dice, si necesita buscar o filtrar múltiples propiedades en los datos, será lento y engorroso.

Nadie en su sano juicio afirmaría que las tiendas de valores clave pueden reemplazar las bases de datos relacionales en general. Sin embargo, puede haber casos de uso particulares en los que el almacenamiento de valores clave sea una buena opción. Los almacenes de valores clave se usan a menudo para el almacenamiento en caché, ya que generalmente almacena elementos en caché por id, pero no necesita realizar consultas ad-hoc sobre los cachés. Por ejemplo, el sitio Stackoverflow en sí usa Redis (una clave-valor db) ampliamente , pero solo para el almacenamiento en caché de salida. Los datos canónicos subyacentes aún persisten en una base de datos relacional.

Entonces, la respuesta es bastante obvia: use un almacén de valores clave si solo necesita almacenar y buscar con una sola clave. De lo contrario, use un tipo diferente de base de datos. Y si tiene dudas, use una base de datos relacional, ya que este es el tipo de base de datos más versátil, mientras que las bases de datos NoSQL a menudo están optimizadas para casos de uso muy particulares.

JacquesB
fuente
2
"NoSQL es un término bastante vago, ya que básicamente cubre todos los sistemas de bases de datos que no son relacionales". - Eso no es cierto. Cubre todos los sistemas de bases de datos que no son bases de datos SQL. Hay bases de datos relacionales que no usan SQL, como Rel y Tutorial D (bases de datos que están diseñadas para seguir el modelo relacional más de cerca sin el "ablandamiento" que hace SQL). Hay bases de datos hiperrelacionales. Realmente, NoSQL significa "No solo SQL", que significa "no asuma automáticamente SQL, elija el modelo de base de datos correcto que coincida con la estructura de su fecha ... que bien podría ser SQL".
Jörg W Mittag el
@ JörgWMittag Según su definición, si elijo MySQL porque es la mejor base de datos para que coincida con mis datos, esa es una solución NoSQL válida.
1
@ JörgWMittag: Thee no es una definición oficial del término NoSQL, pero generalmente se refiere a sistemas de bases de datos no relacionales. El "no solo Sql" -backronym es realmente un retcon más reciente para contrarrestar la inevitable reacción negativa. Pero de uso común, NoSQL se usa para describir sistemas como MongoDb, Bigtable, etc., no para decir el tutorial D (que ni siquiera es una base de datos).
JacquesB
2
@ JörgWMittag NoSQL originalmente significaba "no SQL" o "no relacional". "No solo SQL" sería NOSQL ya que es un acrónimo en lugar de la combinación de la palabra "No" y el acrónimo "SQL". Se hizo popular como un contador a la práctica general de poner todo en una base de datos (como se indica en el artículo de Wikipedia). Como comentaste, el campo es bastante más complejo ahora.
Trisped
Completamente de acuerdo. Parece que los patrones principales de NoSQL son el almacén de documentos de valores clave (por ejemplo, Redis) (por ejemplo, Mongo) y el gráfico (por ejemplo, Neo4J). Desearía que la gente abandonara NoSQL y usara uno de esos términos.
paj28
10

Sus afirmaciones sobre las bases de datos relacionales son verdaderas, hasta el punto en que tiene tantos datos que ya no puede caber una copia de ellos en un solo servidor. Entonces comienzas a encontrarte con todo tipo de problemas interesantes. ¿Cómo divide sus tablas para que la mayoría de sus consultas puedan ejecutarse en un solo servidor? ¿Cuántas copias de los datos haces? ¿Cómo manejas las inconsistencias entre esas copias? ¿Cómo mantiene los datos de un usuario en un centro de datos que está relativamente cerca de él geográficamente?

Estos objetivos a menudo entran en conflicto entre sí. Muchos usuarios de Twitter siguen a personas de todo el mundo. ¿Debería la base de datos de Twitter estar geográficamente optimizada para leer tweets o escribir tweets?

Resulta que cuando se trata con ese tipo de escala, comienza a inventar soluciones, agregar redundancias e imponer restricciones que se parecen mucho a una base de datos NoSQL. Si puede ajustar todos sus datos en una casilla, solo obtendrá las restricciones y no necesitará los beneficios.

Karl Bielefeldt
fuente
Leer 10TB en RAM lleva un tiempo @Daniel ... Un par de horas sería un resultado bastante bueno. Haría que recuperarse de un desastre sea relativamente desastroso.
Ben
1
Yo diría que Big Data es ciertamente un área donde las bases de datos NoSQL entran en juego, pero es solo una. También hay muchas otras razones por las que una base de datos NoSQL podría ser mejor para un problema. Si tiene gráficos de datos, tiene sentido usar una base de datos de gráficos, si tiene datos XML, tiene sentido usar una base de datos XML. No solo Big Data, sino también el modelo de datos es un criterio importante cuando se selecciona una base de datos apropiada (y, por supuesto, muchas veces las bases de datos SQL son la elección correcta, según el problema)
dirkk
55
Esto está mal. El enfoque de fragmentación como programación ha sido estándar en bases de datos a gran escala durante años y algunas bases de datos admiten clústeres con intercambio de datos transparente (Oracle RAC). ¿Cómo crees que funcionan todos los bancos? Y con una configuración adecuada, RARAMENTE restaura las copias de seguridad, lo que se deja como un verdadero escenario de "2 centros de datos quemados". Y sí, he estado trabajando en una base de datos de 30tb una vez, no tuvimos problemas.
TomTom
Sí, las bases de datos relacionales hacen un agrupamiento y agrupamiento de datos transparentes, pero es una abstracción muy permeable si te importa optimizar el rendimiento.
Karl Bielefeldt el
5

Las bases de datos NoSQL tienen muy poco que ver con " No SQL".

Se trata de admitir que no puede tener una base de datos a escala que sea siempre consistente y que soporte transacciones complejas y tenga durabilidad.

En una base de datos relacional normal, todos los índices se actualizan automáticamente dentro del alcance de una transacción, por lo que se pueden usar para cualquier consulta.

En una base de datos NoSQL, el programador es responsable de mantener muchos de los índices y se supone que los índices siempre estarán desactualizados.

Por ejemplo:

  • Un índice de personas por número de impuesto puede contener algunas personas que nunca completan el proceso de registro de impuestos.
  • Por lo tanto, el código que utiliza el índice debe poder hacer frente al registro incompleto de impuestos
  • Otra opción es tener momentos en que una persona que está registrada para impuestos no está en el índice. (Por lo tanto, su diseño tiene que hacer frente a la falta de datos consistentes y decidir cómo los datos no serán consistentes).

Como ejemplo real, Amazon preferiría mostrarme la descripción desactualizada de un libro que retrasar la visualización de la página web esperando que 106 computadoras confirmen que se ha eliminado el bloqueo correcto.

Por lo tanto.....

Si una única base de datos relacional normal puede contener todos sus datos y procesar cada transacción lo suficientemente rápido como para que el bloqueo no impida que su sistema realice un trabajo útil, la mejor opción es una base de datos relacional.

Pero tan pronto como tenga que comenzar a pensar en usar más de una base de datos relacional, o en dividir las transacciones para evitar errores de bloqueo, tendrá que lidiar con el tipo de problemas que tiene cuando usa las bases de datos "NoSQL".

Como las bases de datos "NoSQL" no ocultan estos problemas, pueden convertirse en la mejor opción cuando se escala un sistema. Pero recuerde que Stackoverflow todavía usa una base de datos relacional para almacenar todos sus datos, con un uso limitado de NoSQL en la capa de almacenamiento en caché, por lo que debe ser MUY grande antes de verse obligado a usar NoSQL para almacenar sus datos.

Ian
fuente
Ese último dato es muy interesante: ¿tiene un enlace a algún sitio de meta SO para que los lectores interesados ​​hagan clic para conocer el uso (no) de SOSQL de SO? ¡Gracias!
kcrisman
2

Las bases de datos relacionales están optimizadas para buscar cualquier valor en el datarow de manera efectiva.

No confunda la capacidad de buscar en "cualquier" valor en una fila con "cada" valor en una fila. La forma más efectiva de hacer esto requiere uno o más índices. Puede que los índices incluyan todos los campos, pero luego obstaculizó su capacidad para realizar cambios que requieren alterar el índice (inserciones, actualizaciones, eliminaciones). Usted (o su DBA) debe comprender los datos, el uso, los cuellos de botella, etc.

JeffO
fuente
Un buen ejemplo sería guardar chats. Podría ser necesario relacionarlos con otros datos y hacer todo tipo de análisis, pero durante la sesión de chat en sí, los usuarios apreciarán algo más rápido que no tiene toda la sobrecarga de un RDBMS, como una transacción o restricción.
JeffO
-1

Ya hay muchas respuestas, pero solo quería agregar mi resumen.

Claramente, el concepto NoSQL cubre una variedad de enfoques diferentes para organizar los datos en disco, en memoria y exponerlos a través de un lenguaje de consulta (¡algunos incluso son similares a SQL!). En mi opinión, la fuerza proviene de esta variedad de sistemas para que pueda elegir la mejor herramienta para el trabajo. Pero aún así, con suerte, puede cubrir una docena de necesidades diferentes con solo unas pocas soluciones diferentes, no querrá administrar una docena de sistemas diferentes.

Las bases de datos relacionales pueden llegar muy lejos y son una tecnología probada, pero al igual que la base de datos, es posible que desee elegir el lenguaje de programación en función de las necesidades de cada proyecto (pero teniendo en cuenta también la experiencia del equipo).

NikoNyrh
fuente
-2

He estado usando couchdb durante dos años. Se utiliza principalmente para la gestión y configuración de contenido.

Las relaciones jerárquicas son mucho más fáciles de administrar cuando puede visualizarlas. Para la mayoría de los datos leídos, es más fácil editar JSON que escribir una declaración UPDATE en muchos casos. En realidad, no se necesita un programador para editar JSON. Y SQL le proporciona filas y columnas, que luego debe asignar a algún tipo de estructura de objeto.

También obtienes un aumento de rendimiento porque no te unes a 10-20 tablas en consultas complejas. Las vistas de Couchdb son muy rápidas porque el javascript en el que se basan no se ejecuta en el momento de la consulta.

La mayoría de los programadores entienden Javascript, y la mayoría de los programadores luchan con SQL ocasionalmente.

En Couchdb, una vista puede considerarse como un resumen de un documento JSON. La forma en que se estructuran los datos de la vista depende de usted (no está limitado por la jerarquía original).

No usaría Couchdb para datos altamente transaccionales, pero para datos semiestáticos con una estructura de tipo explosión de piezas, es MUCHO más fácil trabajar con ellos que con SQL.

Sin embargo, tenga en cuenta que no existe una 'normalización' clara que pueda aplicarse (aunque evitar la duplicación de datos es un objetivo digno), y que existe una estrategia de actualización esencialmente y 'optimista' similar al bloqueo optimista.

Jeff Lowery
fuente