Casos de uso de NoSQL [cerrado]

Estoy desarrollando una aplicación para el simposio de investigación de estudiantes de mi universidad sobre la idea de la persistencia políglota. Leí el libro de Martin Fowlers y realicé algunas otras investigaciones en línea sobre los diferentes tipos de bases de datos NoSQL. Tengo curiosidad sobre cuáles son los diferentes casos de uso para las diferentes bases de datos NoSQL.

Actualmente tengo lo que Fowler ha señalado (otra investigación se realizó principalmente en API).

Valor clave:

• datos de sesión
• perfil del usuario
• carrito de compras
• básicamente cualquier cosa que tenga una única clave única que se pueda generar y replicar fácilmente

Documento:

• el registro de eventos
• CMS / blogging
• comercio electrónico (después de que se haya completado la transacción)
• analista de la red

Familia de columna:

• el registro de eventos
• CMS / blogging
• contadores
• uso que expira

Grafico:

• datos conectados
• servicios basados ​​en la localización
• motor de recomendación

Entonces, ¿qué otros casos de uso hay? Más específicamente, ¿cuáles son los casos de uso para cada tipo de NoSQL db que son mejores que un modelo relacional?

Una lista muy grande de casos de uso de NoSQL

Esa lista es útil de vez en cuando, y también señala cuándo una determinada solución NoSQL está especializada para ese caso de uso específico. El hilo original de HackerNews (vinculado en la parte inferior de esa página) también es útil para comentarios extendidos.

Creo que has cubierto casi todo. Puedo ofrecerle uno más sobre la base de datos Graph. He visto a personas o investigadores usar la base de datos de gráficos para el análisis semántico o también para almacenar ontología para el procesamiento del lenguaje natural.

Y como he estado usando mucho Graph db, creo que lo que Graph db ofrece es mucho más de lo que puede ofrecer el modelo relacional. Por ejemplo, si tengo una aplicación web y conecto a todos mis amigos de Facebook y Twitter en función de su ubicación o intereses. Puedo hacerlo en una consulta. Sin embargo, también puede hacerlo en SQL si realmente lo desea, pero el SQL puede ser un A4 de largo o más que eso si desea hacerlo correctamente.

¿Por qué no hacer esto más axiomáticamente? Por ejemplo, ¿por qué "CMS / blogging" se adapta mejor a las bases de datos de documentos (o lo que sea)? ¿Cuáles son las propiedades comunes de estas aplicaciones que te hacen pensar que son más adecuadas para una u otra tecnología?

Considere las fortalezas de cada tecnología DBMS y, de hecho, la teoría en la que se basa cada una. ¿Qué modelo de datos implementan? (¿De hecho, cada uno tiene un modelo de datos?) ¿Cuáles son las propiedades de cada modelo de datos y cómo se correlacionan las propiedades de la aplicación con las del modelo de datos? Si desarrolla un mapa de este tipo, tendrá una forma de caracterizar cualquier aplicación, incluso una de la que nunca haya oído hablar o una que aún no se haya inventado.

Codd definió un modelo de datos que comprende tres características entrelazadas: estructura, operaciones y restricciones. El modelo relacional tiene los tres en espadas. Si observa de cerca las alternativas, encontrará que faltan al menos una y generalmente dos de ellas. Cualquier tecnología no basada en el modelo relacional es ipso facto menos funcional. Por esa razón, es seguro decir que todas las aplicaciones pueden ser compatibles con el modelo relacional (si no con productos relacionales existentes). El modelo relacional está aún más desarrollado, es más poderoso y, sin embargo, es más simple que cualquier otro que se haya ideado. Será difícil mejorar porque se basa en la lógica de predicados y la teoría de conjuntos.

Quizás pueda identificar aplicaciones para las cuales, por ejemplo, las operaciones bien definidas no importan. Pero debe estar muy seguro de comprender primero por qué son importantes en general antes de poder decir con certeza por qué no son necesarios (o incluso útiles) para una aplicación en particular.

Tarde o temprano, alguien le dirá "la relación no escala" y que la tecnología X es rápida. Cuando lo hagan, recuerden que han renunciado implícitamente a características que la tecnología X carece en relación con el modelo relacional, características que bien podrían importar. Además, un modelo de datos no es rápido ni lento, solo lo es una implementación. Cada vez que hay más programadores que máquinas, es más barato comprar hardware más rápido que contratar más programadores.