sql - español - ¿Sería MongoDB una buena idea para un sitio de red social(desarrollado en Ruby on Rails)?

mongodb rails 5

Question

Mi proyecto (en Ruby on Rails 3) es desarrollar un sitio de "redes sociales" con las siguientes características:

• Los usuarios pueden ser amigos. Es amistades mutuas; No asimétrico como Twitter.
• Los usuarios pueden publicar enlaces, para compartirlos. Los amigos de un usuario pueden ver lo que este usuario ha compartido.
• Los amigos pueden comentar sobre esos enlaces compartidos.

Básicamente tenemos Usuarios, Enlaces y Comentarios, y todo lo que está conectado. Algo interesante en las redes sociales es que la tabla Usuario tiene una relación de muchos a muchos consigo misma.

Creo que puedo manejar ese nivel de complejidad con SQL y RoR.

Mi pregunta es: ¿sería una buena idea usar MongoDB (o CouchDB) para tal sitio?

Para ser honesto, creo que la respuesta es no. MongoDB no parece encajar muy bien con las relaciones de muchos a muchos. No puedo pensar en una buena forma de implementar las relaciones de amistad en MongoDB. Y he leído que Diaspora comenzó con MongoDB pero luego volvió a usar el SQL clásico.

Pero algunos artículos en la web defienden a MongoDB para las redes sociales y, sobre todo, quiero tomar una decisión bien informada y no perder un aspecto realmente genial de MongoDB que cambiaría mi vida.

Además, he escuchado sobre el gráfico DB, que probablemente son geniales, pero realmente me parecen muy jóvenes, y no sé cómo encajarían con RoR (y no mencionar heroku).

Entonces, ¿me estoy perdiendo algo?

Gracias,

Arturo

Answer 1

Lo siento, pero tienes que empezar a aprender sobre gráficos. Use bases de datos de gráficos que distribuyen datos en formato JSON y escríbalos en su base de datos de Mongodb. Está tratando con una red, lo que significa que debe haber un gráfico de algún tipo que le permita crear un ego (usuario, por ejemplo) o punto focal o centro lógico, que está conectado a otros nodos a su alrededor. Los nodos podrían ser propiedades de un usuario en particular, como nombre, me gusta, amigos, imágenes, etc. Un gráfico de ego se asemejaría a un centro y radios si lo dibujara.

Para obtener más información, puede consultar cómo implementó Facebook su API Graph: https://developers.facebook.com/docs/graph-api/overview/

Aquí hay un intento de conectar la base de datos de gráficos Mongodb y Neo4j: https://neo4j.com/developer/mongodb/

Answer 2

Me gusta MongoDB y lo uso mucho, pero soy de la opinión de que si está tratando con datos relacionales, debe utilizar la herramienta adecuada para ello. Tenemos bases de datos relacionales para eso. Mongo y Couch son tiendas de documentos.

Mongo tiene una seria desventaja si va a mantener muchos enlaces entre documentos. Sólo se garantiza que las escrituras sean atómicas para un documento. Por lo tanto, podría tener actualizaciones inconsistentes para las relaciones si no es cuidadoso con su esquema.

Lo bueno de MongoDB es que es muy bueno para escalar. Puedes fragmentar y crear conjuntos de réplicas. Foursquare actualmente usa MongoDB y ha estado funcionando bastante bien para ellos. MongoDB también hace map-reduce y tiene una integración geoespacial decente. El equipo que desarrolla MongoDB es excelente, y vivo en Nueva York, donde tienen su sede y los he conocido. Probablemente no vas a tener problemas de escala, aunque creo que empezar.

En cuanto al cambio de diáspora ... No quisiera seguir nada de lo que están haciendo :)

Su comentario sobre el gráfico dbs es interesante sin embargo. Probablemente tampoco usaría una base de datos gráfica como mi base de datos principal, pero al tratar con relaciones, puedes hacer cosas increíbles con ellas. De hecho, por lo general, la demostración que los individuos de las compañías de DB de gráficos le darán está extrayendo el conocimiento de las relaciones de una red social. Sin embargo, no hay nada que le impida jugar con ellos en el futuro para el análisis de la red.

En conclusión, cuando está comenzando aquí, todavía no se encuentra con los problemas de escala masiva, y probablemente tenga limitaciones de tiempo y dinero. Tenga en cuenta que incluso Facebook no usa solo una tecnología, básicamente se han expandido a NoSQL para ciertas funcionalidades (como la mensajería de Facebook). No hay nada que le impida en el futuro el uso de, por ejemplo, Mongo y gridFS para manejar las cargas de imágenes o la ubicación geográfica, etc. Es bueno crecer a medida que cambian sus necesidades. Creo que su instinto de tener una aplicación SQL aquí es correcta, y los beneficios obtenidos con MongoDB no se realizarán por un tiempo.

Answer 3

Mi consejo sería usar lo que sea más familiar para que pueda comenzar a trabajar rápidamente. Por su pregunta, parece que sería SQL en lugar de MongoDB.

Answer 4

Una posibilidad interesante para esto es Riak . Es un cruce entre un almacén de valores clave y una base de datos gráfica. El ID de usuario podría ser su clave y los comentarios y enlaces podrían almacenarse en su valor. Pero Riak también tiene un linking clave a clave. Esto podría ser usado para conectar a tus usuarios como amigos. La vinculación es asimétrica, por lo que debería tratar de agregar y eliminar en ambas direcciones, pero eso no debería ser demasiado difícil.

Pero tenga en cuenta que Riak no es un almacén de datos de documentos, lo que significa que es independiente del valor, lo que significa que no le ayudará a extraer partes internas de su valor, lo que significa que si desea extraer un comentario, primero deberá recuperarlo. Cada comentario y enlace que se almacena con el usuario.

También puede consultar otras bases de datos de gráficos. Los gráficos sociales son el caso de uso prototípico de una base de datos de gráficos.