¿Tiene sentido combinar NoSQL y SQL? ¿Por qué?

Tiene mucho sentido. Al menos así es como hago lo mejor de ambas tecnologías.

NoSQL : rápido y simple, pero tiene poca o ninguna estructura para imponer restricciones en los datos.

RDBMS : satisface todas las propiedades de ACID, manteniendo sus datos seguros y limpios. Pero el rendimiento disminuye rápidamente a medida que aumenta el tráfico y el tamaño del conjunto de datos.

Para la mayoría de los proyectos, puede permitirse el lujo de tener una base de datos relacional gruesa, no distribuida y sin escala como el único punto de verdad en su sistema. Es, con mucho, la forma más fácil de mantener los datos coherentes y mantener consultas complejas posibles.

Puede permitírselo siempre que su capa NoSQL logre interceptar la mayor parte del tráfico dirigido al RDBMS.

Hay muchos trucos para hacer eso usando una solución NoSQL:

• almacenamiento en caché de entidades desnormalizadas (indexar por ID el contenido de tablas previamente unidas en un almacén de valores clave),
• Hospedar todos los datos derivados (como matrices de recomendación precalculadas)
• Hospedar todos los datos temporales que cambian rápidamente (como sesiones de usuario, carritos de compras)

A veces, puede decidir omitir por completo la parte RDBMS, ya que su conjunto de datos es particularmente grande y decide que puede renunciar a las garantías de consistencia, o simplemente, sus datos no tienen una estructura compleja y con mucho gusto lo mantienen simple.

A veces, en cambio, necesita estructura y tiene grandes conjuntos de datos, luego sus mejores tomas son eventualmente sistemas de almacenamiento columnar consistentes como Cassandra o Hbase.
Pero son soluciones muy complejas que son muy caras de mantener.

Buena pregunta.

Una diferencia fundamental entre los dB de SQL y NOSQL es el soporte para transacciones.

Imagine que está escribiendo una aplicación bancaria que mantiene los saldos de las cuentas. No podrá lograr valores de saldo precisos a menos que use transacciones. Esto es común en todas las bases de datos SQL que admiten la semántica ACID.

Sin embargo, el soporte para transacciones no está disponible en NOSql. Por lo tanto, NOSql no es adecuado para ningún proyecto que necesite transacciones.

Dicho esto, si la misma aplicación bancaria necesita una escala tremenda, se puede construir de tal manera que todos los datos no transaccionales o los datos que puedan tolerar la “coherencia eventual” puedan usar NOSql y los datos que necesitan soporte de transacciones se puedan almacenar en una base de datos SQL.

La ventaja de este diseño sería el beneficio de la división o división automática de datos que proporcionan los DB de NOSql que les permite escalar fácilmente. En efecto, las necesidades de mantenimiento de la base de datos pueden reducirse significativamente eligiendo un modelo híbrido como este.

Por supuesto, las bases de datos NOSql también reducen la necesidad de soporte HA y DR al proporcionarlo de forma inmediata (en la mayoría de los casos).

Creo que sí. De hecho, estoy desarrollando activamente esta solución con mi base de datos de código abierto Concourse. La idea es tener la flexibilidad y la escalabilidad simple de una solución sin esquema mientras se preserva el soporte para transacciones totalmente ACID que se encuentran en un RDMBS.

Esta pregunta me hace pensar que el autor cree que NoSQL == No SQL en lugar de NoSQL == No SOLO SQL.

Por cierto, hay algunas soluciones NoSQL que ya pueden usar SQL.

Ahora, muchas de estas discusiones realmente hablan sobre cuántas ‘Herramientas’ podemos usar. En el mundo empresarial, se supone que Less Tools == Lower TCO. En el mundo de inicio más pequeño, es común que los desarrolladores principales tengan algunas herramientas favoritas y solo uno o dos problemas para resolver. Por defecto, hay menos herramientas por diseño orgánico.

Creo que hay algo de sentido común en este pensamiento de Less Tools, pero el dogma que lo rodea es una tontería. Pocas organizaciones saben cuál es su TCO real. Simplemente siguen las reglas sobre las que leyeron en la revista CTO o algún estudio de Gartner y nunca hicieron sus propios números.

La realidad es que si tiene un problema complejo, probablemente necesite un kit de herramientas complejo. Las soluciones híbridas están bien si no son ideales para resolver problemas complejos. Eso significa que las plataformas RDBMS y las plataformas NoSQL están sobre la mesa.

Sí, es posible que deba contratar a más de una persona inteligente. Es correcto. Es posible que no pueda utilizar exclusivamente las herramientas estándar. Está bien si su empresa no es una empresa de software. No te matará desarrollar una o dos cosas desde cero. Algunos desarrolladores pueden necesitar aprender una nueva habilidad. Solo concéntrate y no hagas tonterías.

Más específico a la pregunta que uso las herramientas RDBMS cuando me importan los datos.

Sistema de registro
Cualidades ACID
Rhode Island
Seguridad
Analítica Estratégica

Uso herramientas NoSQL cuando necesito resolver problemas difíciles de Dev-Ops.

> = 100k escribe un segundo y HA
> = triplete dígitos peta bytes
Tactical Analytics casi en tiempo real en transacciones de gran volumen (> = 100k escribe por segundo)

Ahora también uso las herramientas NoSQL cuando necesito resolver problemas gráficos.

Creo que RDBMS es el enfoque seguro para entregar transacciones más seguras y consistentes. Hoy en día ya no nos encontramos con problemas técnicos como vimos hace 10 años. Las bases de datos como MySQL, MS SQL … ahora son cada vez más confiables, más rápidas … Por lo tanto, una base de datos diseñada en MS SQL puede acomodar millones de registros y manejar consultas complejas sin afectar el rendimiento.

Soy más apto para el enfoque híbrido. El mundo de la tecnología se ha desplazado rápidamente a un microservicio que se compone de diferentes datos de almacenamiento, separación de preocupaciones y sistemas en capas para RESTful API. Elegiría el RDBMS para un conjunto de datos de alta intensidad, mientras que NoSQL actúa como un back-end (tipo de autocontenedor). NoSQL es extremadamente útil para el análisis de datos, así como para la minería de datos, la visualización de datos, la inteligencia artificial … ya que tenemos más control sobre las operaciones en este almacenamiento de fondo, por ejemplo, ejecutar el programa / cronjob para volcar datos, actualizar la caché / sesión o incluso retrasar las operaciones durante hora pico … en períodos de intervalo.

Es bastante común que las aplicaciones web utilicen una memoria caché NoSQL rápida y residente en memoria que persiste regularmente en una base de datos SQL.

En mi práctica, el almacenamiento en caché fuera de una base de datos siempre ha sido una mala idea, ya que esto lleva a una inconsistencia de datos. No importa lo que esté usando SQL o NoSQL, ambos son almacenamientos de datos autorizados para mí.

Pues sí y no. Para tablas relativamente más pequeñas, puede usar SQL para varias consultas de relación. Para tablas más grandes (miles de millones de filas) puede usar NoSQL. La base de datos Jaguar de DataJaguar ofrece una combinación de tablas. Por supuesto, join funciona solo para tablas más pequeñas. Entonces el sí es para mesas pequeñas; No para mesas grandes.

Sí, creo que Linkedin tiene muchos servicios que trabajan con DBMS y otros que trabajan con NoSQL y todos los servicios están completamente integrados entre sí.