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

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.

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).

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.

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.

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.

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.

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.

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).

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.