¿Es poco práctico el uso de las bases de datos NoSQL para grandes conjuntos de datos donde se necesita buscar por contenido?

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

  

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

Esto claramente no es cierto.

Por ejemplo, MongoDB admite índices. (de enlace )

  

Los índices admiten la ejecución eficiente de consultas en MongoDB. Sin   índices, MongoDB debe realizar un análisis de recopilación, es decir, analizar cada   documento en una colección, para seleccionar aquellos documentos que coinciden con el   declaración de consulta. Si existe un índice apropiado para una consulta, MongoDB   puede usar el índice para limitar el número de documentos que debe inspeccionar.

     

Los índices son estructuras de datos especiales [1] que almacenan una pequeña parte de   El conjunto de datos de la colección es 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 soporta   Igualaciones eficientes y operaciones de consulta basadas en rango. En   Además, MongoDB puede devolver los resultados ordenados usando el orden en   el índice.

Al igual que couchbase (de enlace )

  

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

     

Una vista crea un índice en los datos de acuerdo con el formato definido   y la estructura. La vista consta de campos específicos e información.   extraído 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 valor-clave realmente 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 es a menudo más expresivo o natural que SQL, y dado que generalmente viven fuera de la tabla, no es necesario cambiar los esquemas de tabla para admitirlos. (No quiere decir que no pueda hacer cosas similares en SQL, pero para mí, se siente como si hubiera mucho más involucrado).

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

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

Tengo la sensación de que gran parte de la venta del enfoque NoSQL proviene del supuesto de grandes bases de datos. Cuanto más grande sea 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 aseo. Por lo tanto, cuanto mayor sea la base de datos, las características más importantes de NoSQL pueden ser potencialmente.

Para usar el ejemplo, en la consulta de SQL por país es tan lento como el escaneo NoSQL de todos los usuarios, a menos que explícitamente le dijera a SQL que indexara la tabla users por país. NoSQL puede hacer lo mismo, donde creas una colección ordenada de valores-clave que es el índice (al igual que SQL lo hace bajo el capó) y lo mantienes.

¿La diferencia? Los motores SQL tenían el concepto de indexar la tabla incorporada. Esto significa que tenía que hacer menos trabajo (todo lo que tenía que hacer era agregar un índice a la tabla). Sin embargo, también significa que tienes 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 consistencia diferente al modelo típico de ACID de SQL. Es posible que desee utilizar el modelo BASE que admite la consistencia 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 normalmente están expuestas, lo que te 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 una gran cantidad 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 los almacenes de valores clave pueden reemplazar las bases de datos relacionales en general. Sin embargo, puede haber casos de uso particulares en los que una tienda de valor-clave sea una buena opción. Los almacenes de valor-clave se usan a menudo para el almacenamiento en caché, ya que normalmente se almacenan en caché los elementos por ID, pero no es necesario realizar consultas ad hoc en los cachés. Por ejemplo, el sitio Stackoverflow utiliza Redis (una base de datos de valores clave) extensivamente , pero solo para el almacenamiento en caché de resultados. 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 tecla. De lo contrario, utilice un tipo diferente de base de datos. Y si tiene dudas, utilice una base de datos relacional, ya que 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 todas ciertas, hasta el punto en el que tiene tantos datos que ya no puede colocar una copia en un solo servidor. Entonces empiezas a encontrarte con todo tipo de problemas interesantes. ¿Cómo se dividen las tablas para que la mayoría de sus consultas se puedan ejecutar en un solo servidor? ¿Cuántas copias de los datos haces? ¿Cómo lidias con las inconsistencias entre esas copias? ¿Cómo guarda los datos de un usuario en un centro de datos que está relativamente cerca de él geográficamente?

Estas metas 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 optimizada geográficamente para leer tweets o escribir tweets?

Resulta que cuando lidias con ese tipo de escala, comienzas a inventar soluciones, agregar redundancias e imponer restricciones que se parecen mucho a una base de datos NoSQL. Si puede guardar todos sus datos en una sola caja, solo está recibiendo las restricciones y no necesita 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 siempre sea consistente y admite transacciones complejas y tiene 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 tiene que ser capaz de hacer frente al registro incompleto de impuestos
• Otra opción es tener momentos en que una persona registrada para impuestos no se encuentre en el índice. (Por lo tanto, su diseño debe lidiar con 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 al esperar 106 computadoras para confirmar que se ha eliminado el bloqueo correcto.

Por lo tanto.....

Si una sola base de datos relacional normal puede contener todos sus datos y procesar cada transacción lo suficientemente rápido 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 tiene que comenzar a pensar en usar más de una base de datos relacional, o dividir las transacciones para evitar errores de bloqueo, está tomando el camino de tener que lidiar con el tipo de problemas que tiene al usar "NoSQL "Bases de datos.

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 tiene que ser MUY grande antes de ser forzado a usar NoSQL para almacenar sus datos.

  

Las bases de datos relacionales están optimizadas para buscar cualquier valor en el   Datarow con eficacia.

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. Es posible que los índices incluyan todos los campos, pero luego solo dificultó la capacidad de realizar cambios que requieren la modificación del í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 el disco, en la 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í, espero que pueda cubrir una docena de necesidades diferentes con solo unas pocas soluciones diferentes, no querría 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 que también tenga en cuenta la experiencia del equipo).

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

Las relaciones jerárquicas son mucho más fáciles de administrar cuando se pueden visualizar. Para leer principalmente datos, es más fácil editar JSON que escribir una instrucción UPDATE en muchos casos. No toma un programador, en realidad, 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 en el rendimiento porque no estás uniendo tablas 10-20 en consultas complejas. Las vistas de Couchdb son muy rápidas porque los javascript en los que se basan no se ejecutan 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 semi-estáticos con una estructura de tipo de explosión de partes, es MUCHO más fácil trabajar con SQL.

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