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

relational-database key-value-store (4)

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

Lo que no entiendo es cómo esto mejora la eficiencia de las consultas. Según tengo entendido, va a desechar mucha información que ayudaría a hacer que las consultas sean más eficientes, simplemente convirtiendo su base de datos de estructura en una gran lista de claves y valores.

¿Me he perdido el punto por completo?

Aquí asumo que desea optimizar una consulta en particular, que simplemente está buscando un registro por clave. Un ejemplo de esto podría ser buscar un registro de información de usuario por nombre de usuario. Para algunos sistemas, una consulta como esta tiene que ser increíblemente rápida y todas las demás consultas no son importantes.

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, árboles B) que pueden recuperar datos no almacenados en I / Os O (log (n)). 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 forma más rápida.

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

Datos no normalizados. Poner todos los datos en una fila significa que no hay uniones.
Baja sobrecarga de la CPU. Un almacén de valor-clave evita el costo de CPU de procesamiento / optimización de consultas, verificaciones de seguridad, verificaciones de restricciones, etc.
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 valor clave, por lo que puede ver que esto elimina al intermediario.

Hay muchas buenas observaciones arriba y, a veces, demasiada pasión por parte de ambos proponentes. Volvamos a su pregunta original. Supongamos que haces un diseño en Cassandra y haces un diseño idéntico en un RDBMS. Digamos que tienes un conjunto de pares KV en Cassandra, y ve y haz un conjunto idéntico de pares KV en relacional. (En realidad, es posible hacer esto, por ejemplo, como un par de valores de nombre completamente desnormalizado en relacional). Aun así, la relación se ejecutará más lentamente simplemente debido a 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 de la familia de columnas, los datos se ordenan de forma lexigráfica; no está en 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 compró esto o aquello, construye su carrito de compras y su lista de deseos, todo lo cual se hará en NOSQL, cuando el usuario presione el botón de pago, la transacción se ejecutará en una base de datos relacional. ¿Por qué los supuestos expertos no nos damos cuenta de que no es uno frente a otro en este debate de base de datos, sino que hay un lugar para relaciones, como NOSQL, gráficos, bases de datos de columnas invertidas, multidimensionales, etc. e incluso? archivos.

La eficiencia proviene de tres áreas principales:

La base de datos tiene muchas menos funciones: no existe el concepto de una combinación y menos requisitos de integridad transaccional o menos. Menos función significa menos trabajo significa más rápido, al menos en el lado del servidor.
Otro principio de diseño es que el almacén de datos se encuentra en una nube de servidores, por lo que su solicitud puede tener múltiples encuestados. Estos sistemas también afirman que el sistema multiservidor mejora la tolerancia a fallos a través de la replicación.
Es totalmente compatible con buzzword, utilizando un montón de ideas y descripciones que aún no están completamente inventadas. Por ejemplo, Amazon actualmente está regalando sus servicios para comprender mejor cómo las personas podrían usarlos y obtener algo de experiencia para refinar la especificación.

A mi modo de ver, alguien que venga a usted con el requisito de que "nuestros nuevos datos serán demasiado para nuestro RDBMS" debería tener números para respaldar esa afirmación o admitir que solo quieren probar el nuevo brillo. Es noSQL meritless? Probablemente no. ¿Se va a poner el mundo al revés ya que Java 1.0 fue promocionado? Probablemente no.

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

La ventaja clave 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.

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 de todos modos). Incluso cuando tiene un índice, la capacidad de relacionarlo es difícil y en qué se destacan las bases de datos relacionales. Las soluciones NoSQL tienen una estructura novedosa que hace que muchos casos de uso sean trivialmente sencillos, por ejemplo, Redis es una base de datos orientada a la estructura de datos adecuada 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 por su rápido desarrollo. Las soluciones de BigTable son un poco menos estructuradas que eso, pero amplían la idea de una fila para tener familias de columnas: pares de valores clave contenidos en cada fila organizados de manera eficiente en el disco. Puedes construir un índice invertido sobre esto con una tecnología como ElasticSearch.

No todo necesita las garantías de consistencia o el diseño de 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 fragmentarse y escalarse horizontalmente fácilmente (¡no es tan fácil con SQL!). Cassandra, en particular, está diseñado para no SPOF. Además, los almacenes de datos orientados a columnas están diseñados para optimizar las velocidades del 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.

Hay ventajas y desventajas. Personalmente, uso una mezcla de ambos. Use la herramienta adecuada para el trabajo correcto, que puede terminar siendo PostgreSQL o MySQL más a menudo que no.

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

No sé si sus datos científicos son adecuados para la mayoría de las implementaciones de NoSQL, eso depende de los datos. Si observa HBase o Cassandra, es posible que se adapte a las necesidades de un científico (con el diseño adecuado de las teclas de hileras - la marca de tiempo no debe ser la primera, verifique OpenTSDB). Sé de muchas compañías que almacenan lecturas de sensores en Cassandra utilizando un particionador de orden aleatorio y el UUID del sensor para acumular lecturas en filas de grasa diarias. Cada día se crean nuevas bases de datos en torno a casos de uso específicos, por lo que la respuesta puede cambiar. Para casos de uso específicos, puede obtener grandes recompensas por el uso de almacenes de datos específicos al costo de la flexibilidad y las herramientas.