¿En qué situaciones es NoSQL mejor que las bases de datos relacionales como SQL? ¿Cuáles son ejemplos específicos de aplicaciones donde el cambio a NoSQL arrojó ventajas considerables?

Tendrás que ser más específico sobre a qué base de datos NoSQL te refieres. Hay docenas de diferentes bases de datos NoSQL, y son útiles para diferentes trabajos. Consulte Bases de datos NOSQL para obtener una lista de diferentes productos NoSQL.

Pero, en general, las bases de datos NoSQL son como bases de datos relacionales desnormalizadas, en el sentido de que se optimizan para ciertas consultas en su aplicación. Es decir, conoce las consultas para las que desea optimizar, por lo que decide un producto NoSQL y un diseño de datos para admitir las consultas que ejecutará.

Mientras que una base de datos relacional normalizada está diseñada para almacenar los datos con un mínimo de anomalías de datos y para maximizar la integridad de los datos. Obviamente, este es un buen objetivo, pero es ortogonal al rendimiento, algo que a la mayoría de la gente le importa mucho.

Entonces, mi respuesta sería que una base de datos NoSQL es mejor si desea optimizar ciertas consultas en una determinada aplicación. Una base de datos SQL es mejor si desea una base de datos que sea más segura para sus datos y que admita la mayor variedad de consultas con respecto a esos datos (por ejemplo, si aún no sabe qué consultas necesitará ejecutar su aplicación).

Soy nuevo en NoSQL pero mientras trabajaba con algunos (Cassandra y Mongodb) llegué a las conclusiones

Puntuaciones NoSQL sobre bases de datos relacionales en situaciones donde:

1. No necesita datos relacionales (por ejemplo, almacenar el recuento de palabras para cada palabra en un documento).

2. Sus datos tienen un esquema flexible, es decir, el esquema de un documento (en una colección) que contiene pares clave-valor es independiente del esquema de cualquier otro documento en la misma colección o en una colección diferente.

Los ejemplos de uso probable de NoSQL serían:

1. Twitter, modelo de amigo seguidor en Facebook: ¿Quiénes son los amigos de mi amigo con los que soy amigo?

2. Modelos de notificación de Facebook: ¿Cuáles son las notificaciones “comentadas” durante la última hora?

3. Modelo de preguntas y respuestas de Quora: ¿Cuántos comentarios para la respuesta ‘X’ para la pregunta ‘Y’ formulada por ‘Z’?

etc …

Si cree que la normalización de sus datos en una base de datos relacional afecta gravemente el rendimiento de las consultas que se unen a tablas normalizadas, en lugar de beneficiarse del dolor de cabeza de la desnormalización, entonces debería optar por NoSQL.

Existen métodos para superar los dolores de cabeza por desnormalización en las bases de datos relacionales también (como los desencadenantes y los procedimientos almacenados para MySQL), pero ¿por qué haría un trabajo adicional si pudiera hacer lo mismo con facilidad en NoSQL? Además, reduce la sobrecarga de la aplicación de sus bases de datos relacionales. Ya en implementación.

Usar MongoDB para tales tareas parece muy intuitivo.

En primer lugar, creo que NoSQL es un término casi sin sentido. El concepto probablemente debería llamarse No solo relacional, ya que es perfectamente posible tener bases de datos relacionales que no usen SQL y viceversa (al menos en teoría).

Cuando la mayoría de las personas discuten las bases de datos NoSQL, a lo que realmente se refieren son a las bases de datos de documentos (a veces llamadas bases de datos de objetos o almacenes de clave / valor). Asumiré que esta pregunta es acerca de la idoneidad de tales bases de datos de documentos.

Sugeriría que tales bases de datos de documentos podrían * potencialmente * ser útiles al menos en las siguientes circunstancias:

1. Almacenamiento de datos semiestructurados. es decir, donde las entidades que se almacenarán tienen una amplia variedad de atributos posibles, pero es probable que cualquier entidad dada solo tenga un pequeño subconjunto de esos atributos. Por ejemplo, almacenar detalles de objetos del mundo real con fines de inteligencia artificial.

2. Aplicaciones donde los “objetos” se normalizan y des-normalizan de forma repetitiva dentro y fuera de las tablas relacionales de tal manera que esto provoca un rendimiento inaceptablemente lento Y la aplicación puede vivir sin características relacionales como JOINS. Lo que no debe olvidarse (aunque es casi universal) es que muchas bases de datos relacionales admiten campos de valores múltiples que eliminan una capa completa (o dos) de sobrecarga en el almacenamiento de datos relacionales.

Un posible candidato para el uso eficaz de un almacén de datos no relacional (NoSQL, si es necesario) es MongoDB como caché de objetos para mejorar el rendimiento en Drupal, pero vale la pena señalar que en este caso gran parte de los datos de la aplicación permanecen en tablas relacionales .

Algunas personas argumentan que las bases de datos NoSQL son más adecuadas para datos GRANDES. Realmente no puedo comentar por experiencia ya que los conjuntos de datos más grandes con los que he trabajado están en el rango bajo de gigabytes. Sin embargo, aparentemente en 2008 Yahoo afirmó tener la base de datos más grande y ocupada del mundo con 2 Petabytes y 24 mil millones de eventos por día en una versión modificada de PostgreSQL. http://www.computerworld.com/s/a …

Si los datos permanecen en estado mayoritariamente desnormalizado, tiene sentido modelarlos con una tienda nosql. (Los requisitos habituales, como la necesidad de almacenamiento de datos distribuido, rendimiento, gran tamaño de base de datos, etc., son aplicables como siempre). Si observa las aplicaciones típicas, puede observar que los datos están disponibles / manipulados en 3 formas diferentes:

1. A nivel de aplicación, usaría alguna forma de Colecciones para administrar los datos. Las colecciones generalmente se crean / destruyen según sea necesario para atender las solicitudes.
2. En el nivel de almacenamiento en caché donde se almacenan en caché los datos de uso común. El formulario de datos puede ser el mismo que el utilizado en la aplicación o serializado en un formulario diferente en el caché.
3. Los datos persistentes: un RDBMS, nosql o alguna solución patentada para conservar los datos.

En las aplicaciones de escala web, la mayoría, si no todos, los datos se desean que residan en la memoria para un acceso más rápido. En tales aplicaciones, la serialización / deserialización innecesaria entre los 3 formularios descritos anteriormente también es menos deseable, ya que se suma a la sobrecarga al atender las solicitudes de los usuarios. Los almacenes de datos Nosql se ajustan bien a tales casos de uso, ya que dichos almacenes son almacenes de clave / valor o almacenes orientados a documentos, pero sin embargo, almacenes sin esquema. En mi propio trabajo, estamos usando Cassandra en nuestro servidor de Feed por las razones descritas anteriormente (datos desnormalizados, replicación de múltiples centros de datos, etc.)

Imagine un sitio que transmite programas de televisión. Donde cada entidad de una Serie tiene muchas estaciones, cada Temporada tiene muchos episodios. Cada episodio tiene muchos comentarios de los usuarios. De acuerdo con Sarah Mei, este es el ejemplo perfecto del uso de NoSQL: “Cada espectáculo era un documento, perfectamente autocontenido. Sin referencias a nada, sin duplicación, y no hay forma de que los datos se vuelvan inconsistentes “.

Luego procede a explicar el caso de uso ideal para las bases de datos NoSQL: “Aprendí algo de esa experiencia: el caso de uso ideal de MongoDB es incluso más limitado que nuestros datos de televisión . Lo único en lo que es bueno es almacenar piezas arbitrarias de JSON. “Arbitrario”, en este contexto, significa que no te importa en absoluto lo que hay dentro de ese JSON. Ni siquiera miras. No hay un esquema, ni siquiera un esquema implícito, como había en los datos de nuestro programa de televisión. Cada documento es solo un blob sobre cuyo interior no se hacen suposiciones ”.

El NoSQL (lenguaje de consulta no solo estructurado) es mejor cuando va a almacenar documentos de pares de valores clave como preguntas y respuestas y aplicaciones basadas en pares de nombre y valor como video y su ruta y detalles del autor, etc.

En general, la forma en formato JSON de almacenar aplicaciones prefiere NoSQL como back-end.

Recientemente, casi todas las aplicaciones de king of Node.js están utilizando NoSQL como base de datos back-end como MongoDB, Redis, Cassendra, etc. Sus volúmenes de datos altamente escalables y grandes se almacenan en bases de datos NoSQL.

Como no hay un solo tipo de base de datos NoSQL, creo que esta pregunta debe responderse a la inversa. ¿Cuándo debería usar una base de datos relacional?

Las bases de datos relacionales destacan en el almacenamiento de datos de manera eficiente en el espacio. No necesito todos los detalles de una persona en cada registro. Una identificación de 8 bytes puede reemplazar un conjunto mucho más grande de datos de campo que solo necesita almacenarse una vez. A cambio, muchas operaciones se vuelven más caras (se une, por ejemplo). Esta fue una compensación importante a principios de la década de 1970.

Desde entonces, algunas bases de datos relacionales se han vuelto sólidas en términos de autenticación / seguridad de datos y representan la lógica empresarial. El diseño relacional no se presta para funcionar mejor que otros, pero se ha fortalecido en estos dos mercados.

Dado que puede ver las ofertas de NoSQL para ver si una o más se ajustan mejor a la factura. Las bases de datos de gráficos pueden sobresalir cuando necesita caminar conexiones entre registros para operaciones de gráficos y análisis. Las bases de datos de documentos pueden ser una muy buena alternativa donde el espacio no es un problema, pero desea trabajar de manera fluida con los datos sin toneladas de uniones o indirecciones. Los almacenes de valores clave son justo cuando solo necesita buscar cosas con una sola referencia rápida, o el resto de la lógica es más fácil / rápida de implementar que lograr que el sistema relacional se ajuste a su problema.

Sin embargo, el término NoSQL también puede significar que no desea interactuar con sus datos en SQL. Esto puede ser cierto para cualquier tipo de base de datos. No hay nada mágico sobre SQL que no se pueda hacer, a menudo mejor, en otro idioma o API. SQL fue inventado para permitir a los usuarios trabajar con conjuntos de datos en lugar de esperar a que un programador escriba una aplicación. El hecho de que se haya convertido en la interfaz estándar de los programadores para las bases de datos es una triste situación.

Gran tema aquí …

Antes de responder con casos de uso específicos, es importante resaltar algunas características de la mayoría de las bases de datos NoSQL. Los motores NoSQL generalmente se distribuyen, son escalables horizontalmente y pueden manipular una gran cantidad de datos con excelentes rendimientos. Me gusta esta publicación de highscalability.com: http://highscalability.com/blog/ …

Entonces, cuando su aplicación requiera uno o más de estos puntos, NoSQL será la mejor solución. Algunos de los casos de uso donde NoSQL es claramente mejor:

– Aplicaciones sociales / Social Gaming : una aplicación social, si tiene éxito, puede pasar de cero a millones de usuarios en pocos días / semanas; Para gestionar este crecimiento, necesita una base de datos que pueda gestionar una gran cantidad de usuarios y datos, pero que también se pueda escalar horizontalmente fácilmente. (elasticidad dinámica, almacenamiento en caché de datos)

– Publicidad / orientación de contenido / BI : para tener éxito en la publicidad, es importante poder apuntar a usuarios específicos. La base de datos NoSQL lo ayudará a desarrollar e implementar su aplicación que debe manipular miles de millones de datos (eventos, contenido y usuarios que usan un esquema de datos flexible)

– Archivar datos : si desea archivar datos y mantenerlos disponibles para el usuario, las bases de datos NoSQL pueden ayudarlo. En primer lugar, puede almacenar y acceder a un gran volumen de datos cuando se almacena en NoSQL. Al usar el motor NoSQL orientado a documentos, como Couchbase, MongoDB, puede almacenar cualquier tipo de datos (esquema flexible / sin esquema) que le permite archivar cualquier cosa.

En algunos proyectos donde la evolución del esquema es un desafío, una base de datos NoSQL puede facilitar las cosas. En el video vinculado a continuación, el orador habla sobre sus experiencias usando MongoDB en una aplicación médica.

Las cosas pueden ponerse bastante complicadas cuando los desarrolladores no entienden las implicaciones de un esquema flexible.

SQL es literalmente un lenguaje portátil de bases de datos, pero si intentas colgar una etiqueta exacta en NoSQL, fracasarás, porque las empresas se lanzaron a eso como una palabra de moda para promocionar lo que quisieran promocionar que no se ajustaba exactamente a un base de datos relacional tradicional.

La respuesta de Bill es bastante buena a este respecto: si un producto se promociona a sí mismo como NoSQL, entonces tiene alguna característica diferenciadora que proporciona grandes ganancias de rendimiento en casos específicos (que es donde espera estar en un mercado de productos maduros como bases de datos). Una base de datos NoSQL tiene una característica específica que proporcionará algunas mejoras extremas de rendimiento. Podría ser la velocidad real o podría estar funcionando con una API altamente eficiente y de mayor nivel.

¿Qué tan fácil es consultar datos NoSQL (se llama NoSQL por alguna razón)?
¿No es el esquema flexible el peor “diseño” posible (si se le puede llamar así), ¿cómo se asegura la consistencia de los datos?

La otra cara de la moneda es para qué casos de uso NoSQL no es adecuado.

El único buen caso de uso para NoSQL parece ser donde ACID y un buen diseño no son tan importantes como la escalabilidad / rendimiento.

SQL es mejor para datos estructurados. Nombre, dirección, ocupación, etc. NOSQL es mejor para datos no estructurados. Si escanea un montón de libros y luego raspa un montón más de páginas web y luego importa todos esos datos en una base de datos, las consultas NOSQL serían mejores para dar sentido a los datos que el SQL normal.

Hay más o menos dos instalaciones que los productos noSQL no abordan / proporcionan inherentemente. ‘Uniones’ y transacciones. Cualquier aplicación que no los necesite, o pueda evitar la falta de ellos de diferentes maneras, no tendrá ningún problema al utilizar dichos sistemas.
Las principales razones para utilizar un sistema de almacenamiento de datos distribuido y no compartido (‘noSQL’) son la escalabilidad y el rendimiento (aunque generalmente pierde en términos de rendimiento y gana en términos de escalabilidad).

Aquí hay otra publicación de blog que habla sobre los escenarios en los que NoSQL puede o no puede usarse. Cuándo usar NoSql

Antes de responder, aquí hay un descargo de responsabilidad: trabajo como Gerente de Producto para Oracle NoSQL Database y hablaré sobre Oracle NoSQL (ONDB). Oracle NoSQL DB es particularmente adecuado para IoT, información de portal de clientes centrada en la web y aplicaciones de captura de datos de sensores de fabricación que necesitan operaciones de lectura / escritura de alto rendimiento y baja latencia. NoSQL DB también está estrechamente integrado con la pila de tecnología de Oracle, lo que le permite aprovechar NoSQL y la mejor tecnología de gestión de datos de su clase en una sola aplicación.

Como ejemplo, SharePoint sería mucho mejor si se implementara utilizando NoSQL (algo así como MongoDB) en lugar de MS-SQL. En Mongo, los datos todavía están estructurados, pero no tienen un esquema, lo que sería ideal para almacenar listas en las que las definiciones se pueden cambiar por capricho.

Aquí hay una buena publicación que habla sobre varios casos de uso de NoSQL http://highscalability.com/blog/ …

1. No haga referencia a esquemas o no esquemas como un conjunto de NoSQL. En RDBMS, también puede guardar datos json / protobuf, como si no necesitara un índice secundario en estas columnas.
2. Facebook y Twitter usan NoSQL, también usan muchas instancias mysql.
3. Si su empresa necesita ACID, ¿cómo puede satisfacer las necesidades de ACID de su empresa?

Las bases de datos relacionales se basan en la teoría de conjuntos, que no es muy efectiva cuando se requiere la relación padre-hijo o distancia de las relaciones. Son excesivos (menos escalables) para los datos que se pueden usar de manera efectiva como pares clave-valor y poco útiles (bajo rendimiento) para los datos que necesitan más contexto.

Dependiendo del caso de uso, elija el tipo correcto de base de datos NoSQL que se divida principalmente en 4 categorías: http://www.bigdataeducation.in/n …