¿Cuáles son las ventajas de usar bases de datos NoSQL? He leído mucho sobre ellos últimamente, pero todavía no estoy seguro de por qué querría implementar uno y bajo qué circunstancias me gustaría usar uno.
141
Las bases de datos relacionales hacen cumplir ACID . Por lo tanto, tendrá almacenes de datos orientados a transacciones basados en esquemas. Está probado y es adecuado para el 99% de las aplicaciones del mundo real. Prácticamente puedes hacer cualquier cosa con bases de datos relacionales.
Pero, existen limitaciones en cuanto a velocidad y escala cuando se trata de almacenes de datos masivos de alta disponibilidad. Por ejemplo, Google y Amazon tienen terabytes de datos almacenados en grandes centros de datos. La consulta y la inserción no funcionan en estos escenarios debido a la naturaleza de bloqueo / esquema / transacción de los RDBM. Esa es la razón por la que han implementado sus propias bases de datos (en realidad, almacenes de valores clave) para una ganancia masiva de rendimiento y escalabilidad.
Las bases de datos NoSQL han existido durante mucho tiempo, solo que el término es nuevo. Algunos ejemplos son bases de datos de gráficos, objetos, columnas, XML y documentos.
Para su segunda pregunta: ¿está bien usar ambos en el mismo sitio?
Por qué no? Ambos sirven para diferentes propósitos ¿verdad?
Las soluciones NoSQL generalmente están destinadas a resolver un problema para el que las bases de datos relacionales no son adecuadas, demasiado caras de usar (como Oracle) o requieren que implemente algo que rompa la naturaleza relacional de su base de datos de todos modos.
Las ventajas suelen ser específicas para su uso, pero a menos que tenga algún tipo de problema para modelar sus datos en un RDBMS, no veo ninguna razón por la que elija NoSQL.
Yo mismo uso MongoDB y Riak para problemas específicos donde un RDBMS no es una solución viable, para todas las demás cosas uso MySQL (o SQLite para las pruebas).
Si necesita una base de datos NoSQL que generalmente conoce, las posibles razones son:
Si no necesita una solución NoSQL, tenga en cuenta que estas soluciones no fueron reemplazadas por un RDBMS, sino más bien como alternativas en las que la primera falla y, lo que es más importante, que son relativamente nuevas como tal, todavía tienen muchos errores y características faltantes
Ah, y con respecto a la segunda pregunta, está perfectamente bien usar cualquier tecnología junto con otra, por lo que, para ser completos, según mi experiencia, MongoDB y MySQL funcionan bien juntos siempre que no estén en la misma máquina
fuente
Martin Fowler tiene un excelente video que brinda una buena explicación de las bases de datos NoSQL. El enlace va directo a sus razones para usarlos, pero todo el video contiene buena información.
Tiene grandes cantidades de datos, especialmente si no puede ajustarlos todos en un servidor físico, ya que NoSQL fue diseñado para escalar bien.
Desajuste de impedancia relacional de objeto : sus objetos de dominio no se ajustan bien en un esquema de base de datos relacional. NoSQL le permite conservar sus datos como documentos (o gráficos) que pueden correlacionarse mucho más estrechamente con su modelo de datos.
fuente
NoSQL es un sistema de base de datos donde los datos se organizan en el documento (MongoDB), par clave-valor (MemCache, Redis), forma de estructura gráfica (Neo4J).
Tal vez aquí hay posibles preguntas y respuestas para "Cuándo elegir NoSQL":
¿Requiere un esquema flexible o tratar con datos similares a árboles?
En general, en el desarrollo ágil, comenzamos a diseñar el sistema sin conocer todos los requisitos por adelantado, donde más adelante, a lo largo del desarrollo, el sistema de base de datos puede necesitar cambios de diseño frecuentes, mostrando MVP (producto mínimamente viable). O está tratando con un esquema de datos que es de naturaleza dinámica. Por ejemplo, los registros del sistema, un ejemplo muy preciso son los registros de AWS Cloudwatch.
El conjunto de datos es vasto / grande?
Sí No La base de datos SQL es el mejor candidato para aplicaciones donde la base de datos necesita administrar millones o incluso miles de millones de registros sin comprometer el rendimiento.
Compensación entre escalado sobre coherencia A diferencia del RDMS, la base de datos NoSQL puede perder pequeños datos aquí y allá (Nota: la probabilidad es .x%), pero es fácil de escalar en términos de rendimiento. Ejemplo: Esto puede ser bueno para almacenar personas que están en línea en la aplicación de mensajería instantánea, tokens en db, registrando las estadísticas de tráfico del sitio web.
Realización de operaciones de geolocalización: MongoDB hash rico soporte para realizar operaciones de GeoQuerying y Geolocalización. Realmente me encantó esta característica de MongoDB.
En pocas palabras, MongoDB es ideal para aplicaciones donde puede almacenar datos estructurados dinámicos a gran escala.
fuente
Falta información esencial para responder la pregunta: ¿Qué casos de uso debe poder cubrir la base de datos? ¿Deben realizarse análisis complejos a partir de datos existentes ( OLAP ) o la aplicación debe poder procesar muchas transacciones ( OLTP )? ¿Cuál es la estructura de datos? Eso está lejos del final del turno de preguntas.
En mi opinión, es un error tomar decisiones tecnológicas sobre la base de palabras de moda audaces sin saber exactamente qué hay detrás de ellas. NoSQL es a menudo elogiado por su escalabilidad. Pero también debe saber que el escalado horizontal (en varios nodos) también tiene su precio y no es gratuito. Luego tiene que lidiar con problemas como la consistencia eventual y definir cómo resolver los conflictos de datos si no se pueden resolver a nivel de la base de datos. Sin embargo, esto se aplica a todos los sistemas de bases de datos distribuidas.
La alegría de los desarrolladores con la palabra "sin esquema" en NoSQL al principio también es muy grande. Esta palabra de moda se desencanta rápidamente después del análisis técnico, porque correctamente no requiere un esquema al escribir, pero entra en juego al leer. Es por eso que debería ser correctamente "esquema de lectura". Puede ser tentador poder escribir datos a su propia discreción. Pero, ¿cómo manejo la situación si hay datos existentes pero la nueva versión de la aplicación espera un esquema diferente?
El modelo de documento (como en MongoDB, por ejemplo) no es adecuado para modelos de datos donde hay muchas relaciones entre los datos. Las uniones deben hacerse a nivel de aplicación, lo cual es un esfuerzo adicional y por qué debería programar cosas que la base de datos debería hacer.
Si argumenta que Google y Amazon han desarrollado sus propias bases de datos porque el RDBMS convencional ya no puede manejar la avalancha de datos, solo puede decir: usted no es Google ni Amazon. Estas compañías son la punta de lanza, alrededor del 0.01% de los escenarios donde las bases de datos tradicionales ya no son adecuadas, pero lo son para el resto del mundo.
Lo que no es insignificante: SQL ha existido durante más de 40 años y millones de horas de desarrollo se han dedicado a grandes sistemas como Oracle o Microsoft SQL. Esto debe ser logrado por algunas bases de datos nuevas. A veces también es más fácil encontrar un administrador SQL que alguien para MongoDB. Lo que nos lleva a la cuestión del mantenimiento y la gestión. Un tema que no es exactamente sexy, pero que es parte de la decisión tecnológica.
fuente
Encontré esta pregunta mientras buscaba motivos convincentes para desviarse del diseño RDBMS.
Hay una gran publicación de Julian Brown que arroja luces sobre las restricciones de los sistemas distribuidos. El concepto se llama Teorema CAP de Brewer, que en resumen dice:
Y así es como lo resumí para mí:
fuente
Diseñé e implementé soluciones con bases de datos NoSQL y aquí está mi lista de puntos de control para tomar la decisión de usar SQL o NoSQL orientado a documentos .
NO HACER
SQL no es obsoleto y sigue siendo una mejor herramienta en algunos casos. Es difícil justificar el uso de un NoSQL orientado a documentos cuando
Hacer
Si no tiene esas condiciones o puede mitigarlas, aquí hay 2 razones por las que puede beneficiarse de NoSQL:
Más información
En mis publicaciones de blog explico las razones con más detalles:
Nota: lo anterior es aplicable solo a NoSQL orientado a documentos. Hay otros tipos de NoSQL, que requieren otras consideraciones.
fuente
Manejo de una gran cantidad de operaciones de lectura y escritura
Mire hacia las bases de datos NoSQL cuando necesite escalar rápidamente. ¿Y cuándo generalmente necesita escalar rápido?
Cuando hay una gran cantidad de operaciones de lectura y escritura en su sitio web y cuando se trata de una gran cantidad de datos, las bases de datos NoSQL se ajustan mejor en estos escenarios. Dado que tienen la capacidad de agregar nodos sobre la marcha, pueden manejar más tráfico concurrente y gran cantidad de datos con una latencia mínima.
Flexibilidad con modelado de datos
La segunda señal es durante las fases iniciales de desarrollo cuando no está seguro sobre el modelo de datos, el diseño de la base de datos, se espera que las cosas cambien a un ritmo rápido. Las bases de datos NoSQL nos ofrecen más flexibilidad.
Consistencia eventual sobre consistencia fuerte
Es preferible elegir bases de datos NoSQL cuando está bien que renunciemos a la coherencia fuerte y cuando no requerimos transacciones.
Un buen ejemplo de esto es un sitio web de redes sociales como Twitter. Cuando explota un tweet de una celebridad y a todos les gusta y lo re-tuitean desde todo el mundo. ¿Importa si el recuento de me gusta sube o baja un poco por un corto tiempo?
A la celebridad definitivamente no le importaría si en lugar de los 5 millones 500 me gusta reales, el sistema muestra el recuento de me gusta como 5 millones 250 por un corto tiempo.
Cuando se implementa una gran aplicación en cientos de servidores repartidos por todo el mundo, los nodos distribuidos geográficamente tardan un tiempo en alcanzar un consenso global.
Hasta que lleguen a un consenso, el valor de la entidad es inconsistente. El valor de la entidad finalmente se vuelve consistente después de un corto tiempo. Esto es lo que es la consistencia eventual.
Aunque la inconsistencia no significa que haya algún tipo de pérdida de datos. Simplemente significa que los datos tardan un poco en viajar por todo el mundo a través de los cables de Internet debajo del océano para alcanzar un consenso global y volverse coherentes.
Experimentamos este comportamiento todo el tiempo. Especialmente en YouTube. A menudo verías un video con 10 vistas y 15 me gusta. Como es esto posible?
No es. Las vistas reales ya son más que los me gusta. Es solo que el recuento de vistas es inconsistente y tarda un poco en actualizarse.
Ejecución de análisis de datos
Las bases de datos NoSQL también se ajustan mejor a los casos de uso de análisis de datos, donde tenemos que lidiar con una afluencia de grandes cantidades de datos.
fuente