Por qué el par de valores clave noSQL db es más rápido que los DB relacionales tradicionales

Question

Se me recomendó que investigue los sistemas de datos pares de clave/valor para reemplazar una base de datos relacional que he estado usando.

Lo que no entiendo muy bien es cómo mejora la eficiencia de las consultas. Por lo que entiendo, estarás desperdiciando mucha información que ayudaría a que las consultas sean más eficientes, simplemente convirtiendo tu base de datos de estructuras en una gran lista larga de claves y valores.

¿He perdido el punto por completo?

Answer 1

La principal ventaja de una base de datos relacional es la capacidad de relacionar e indexar información. La mayoría de los sistemas 'NoSQL' no proporcionan un álgebra relacional o un gran lenguaje de consulta.

Lo que debe preguntarse es si el cambio tiene sentido para mi caso de uso previsto.

Te has perdido el punto. El punto es que a veces no tienes un índice (de la forma en que lo haces con un DB relacional general). Incluso cuando tiene un índice, la capacidad de relacionarlo entre sí es difícil y en qué bases de datos relacionales se destacan. Las soluciones NoSQL tienen una cantidad de estructura novedosa que hace que muchos usos sean trivialmente fáciles, p. Redis es una base de datos orientada a DB bien adaptada para construir rápidamente cualquier cosa con colas o su arquitectura pub-sub. MongoDB es una base de datos de documentos de forma libre que almacena documentos como JSON (BSON) y se destaca en el desarrollo rápido. Las soluciones de BigTable están un poco menos estructuradas que eso, pero amplían la idea de una fila para tener familias de columnas: pares clave de valores contenidos en cada fila organizados de manera eficiente en el disco. Puede construir un índice invertido además de esto con una tecnología como ElasticSearch.

No todo necesita las garantías de consistencia o el diseño del disco de un RDBMS tradicional. Otro caso de uso importante de NoSQL es la escalabilidad masiva, muchas soluciones (por ejemplo, BigTable - HBase/Cassandra) están diseñadas para fragmentar y escalar horizontalmente fácilmente (¡no tan fácil con SQL!). Cassandra en particular está diseñado para ningún SPOF. Además, los almacenes de datos orientados a columnas están destinados a optimizar las velocidades de disco a través de lecturas secuenciales (y reducir write-amplification). Dicho esto, a menos que realmente lo necesite, un servidor SQL tradicional generalmente es lo suficientemente bueno.

Tiene ventajas y desventajas. Personalmente, uso una mezcla de ambos. Use la herramienta adecuada para el trabajo correcto, que puede terminar siendo PostgreSQL o MySQL la mayoría de las veces.

Puede comparar un sistema básico de valores-clave para crear una tabla SQL con dos columnas, una clave única y un valor. Esto es bastante rápido. No necesita hacer ninguna relación, correlación o recopilación de datos. Solo encuentra el valor y devuélvelo. Esto es una simplificación excesiva, las bases de datos NoSQL tienen una gran cantidad de funcionalidades y aplicaciones interesantes más allá de las simples tiendas K, V.

No sé si sus datos científicos son adecuados para la mayoría de las implementaciones de NoSQL, eso depende de los datos. Si miras a HBase o Cassandra, es muy posible que se adapte a las necesidades de un científico (con el diseño adecuado de la clave de fila - la marca de tiempo no debe ser la primera, echa un vistazo a OpenTSDB). Conozco muchas empresas que almacenan lecturas de sensores en Cassandra mediante el uso de un particionador de orden aleatorio y el UUID del sensor para enrollar las lecturas en filas gordas diarias. Todos los días se crean nuevas bases de datos en torno a casos de uso específicos, de modo que la respuesta puede cambiar. Para casos de uso específicos, puede obtener enormes recompensas por el uso de almacenes de datos específicos a costa de flexibilidad y herramientas.

Answer 2

La eficiencia proviene de tres áreas principales:

1. La base de datos tiene muchas menos funciones: no existe el concepto de una combinación requisitos de integridad transaccional disminuidos o ausentes y. Menos funciones significa menos trabajo significa más rápido, en el lado del servidor al menos.
2. Otro principio de diseño es que el data store vive en una nube de servidores por lo que su solicitud puede tener múltiples respuestas. Estos sistemas también afirman que el sistema multiservidor mejora la tolerancia a fallas a través de la replicación.
3. Es completamente compatible con la palabra de moda, usando un montón de ideas y descripciones que aún no están completamente inventadas. Por ejemplo, Amazon actualmente está prestando sus servicios para comprender mejor cómo las personas pueden usarlos y obtener experiencia para refinar la especificación.

En mi opinión, alguien que acude a usted con la exigencia de que "nuestros nuevos datos serán demasiado para nuestro RDBMS" debe tener números para respaldar esa afirmación o admitir que solo quiere probar la nueva brillante. Es noSQL sin merito? Probablemente no. ¿Va a poner al mundo patas arriba, como se promocionó a Java 1.0? Probablemente no.

No hay nada de malo en investigar cosas nuevas, simplemente no apueste por la granja en favor de una tecnología bien establecida y bien establecida de 50 años de antigüedad.

Answer 3

Aquí supongo que quiere optimizar una consulta en particular, que es simplemente buscar un registro por clave. Un ejemplo de esto podría ser buscar un registro de userinfo por nombre de usuario. Para algunos sistemas, una consulta como esa tiene que ser increíblemente rápida y todas las demás consultas carecen de importancia.

El factor más importante en el rendimiento de la base de datos será el número de operaciones de E/S necesarias para leer/escribir datos. La mayoría de los sistemas de bases de datos utilizan estructuras de datos similares (es decir, b-trees) que pueden recuperar datos no almacenados en O (log (n)) E/S. Para proporcionar actualizaciones duraderas, los datos deberán escribirse en el disco: la mayoría de los sistemas lo hacen de forma secuencial, que es la manera más rápida.

Entonces, ¿dónde puede una tienda Key-Value obtener eficiencias?

1. Datos no normalizados. Poner todos los datos en una fila significa que no hay uniones.
2. Bajo consumo de CPU. Un almacén de valores clave evita el costo de CPU de procesamiento/optimización de consultas, comprobaciones de seguridad, comprobaciones de restricciones, etc.
3. Es más fácil tener la tienda en proceso (a diferencia de un servidor SQL que se ejecuta como un servicio separado) esto elimina la sobrecarga de IPC.

La mayoría de los sistemas RDBMS están construidos sobre algo que parece un almacén de valores-clave, por lo que podría ver esto como un recorte del intermediario.

Answer 4

Hay una gran cantidad de buenas observaciones por encima y, a veces un poco de pasión en ambos lados por ambos proponentes. Volvamos a tu pregunta original. Supongamos que hace un diseño en Cassandra y hace un diseño idéntico en un RDBMS. Supongamos que tiene un conjunto de pares KV en Cassandra, y vaya y haga un conjunto idéntico de pares KV en relación. (En realidad es posible hacer esto, por ejemplo, como un par de nombre de nombre totalmente desnormalizado en relacional). Aún así, relacional se ejecutará más lento simplemente por la sobrecarga del DBMS relacional: registro, acceso al catálogo, comprobación de integridad, atomicidad de la transacción, etc. Además, en el almacén de datos familiares de columna los datos se clasifican de forma lexicigráfica; no es relacional Creo que varios de los sitios de redes sociales hicieron esto, construyeron estructuras idénticas en ambos, pero el relacional fue más lento.Es importante recordar que después de que un usuario consulta la base de datos del producto, mira quién también compró esto o aquello, crea su carrito de compras y su lista de deseos, todo lo cual se hará en NOSQL, cuando el usuario acceda al botón de pago, la transacción se ejecutará en una base de datos relacional. ¿Por qué los supuestos expertos no podemos darnos cuenta de que no se trata de una cosa contra la otra en este debate de base de datos, sino que hay un lugar para relacional, como NOSQL, gráfico, bases de datos de columnas invertidas, multidimensional, etc. e incluso archivos.