Necesito un consejo sobre NoSQL / MongoDb y la estructura de datos / modelos

Question

Recientemente estoy explorando las bases de datos NoSQL. Necesito un consejo sobre cómo almacenar datos de la manera más óptima y eficiente para un problema determinado. Estoy apuntando a MongoDB, ahora. Sin embargo, debería ser lo mismo con CouchDB.

Digamos que tenemos estos 3 modelos:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

Quiero poder hacerle a la base de datos estas preguntas:

• ¿Quién ha votado por esta historia?
• ¿Por qué ha votado este usuario?

Estoy haciendo uniones simples mientras trabajo con una base de datos relacional. La pregunta es, ¿cómo debo almacenar los datos de esos objetos para ser más eficiente?

Por ejemplo, si almaceno los objetos Votar como una subcolección de Historias, no será fácil obtener la información - "Lo que un usuario ha votado".

Answer 1

Sugeriría almacenar los votos como una lista de historias _id s en cada usuario. De esa manera, puede averiguar qué historias ha votado un usuario simplemente mirando la lista. Para obtener los usuarios que votaron por una historia, puede hacer algo como:

db.users.find ({stories: story_id})

donde story_id es el _id de la historia en cuestión. Si crea un índice en el campo stories , ambas consultas serán rápidas.

Answer 2

• no se preocupe si sus consultas son eficientes hasta que comience a importar
• según la cita a continuación, lo estás haciendo mal

  

La forma en que he estado yendo sobre el   cambiar de opinión es olvidarse de la   base de datos en conjunto. En el   mundo db relacional siempre tienes que   preocuparse por la normalización de datos y   La estructura de su mesa. Deshazte de todo.   Simplemente diseñe su página web. Colocarlos   completamente. Ahora míralos. Tu   Ya 2/3 allí. Si olvidas el   idea de que el tamaño de la base de datos es importante y   los datos no deben duplicarse que su   3/4 allí y ni siquiera tuviste que   escribe cualquier código! Deje que sus puntos de vista dicten   sus modelos No tienes que tomar   tus objetos y hazlos 2   dimensional ya como en el   mundo relacional Puedes almacenar   objetos con forma ahora.

how-to-think-in-data-stores -en lugar de bases de datos

Answer 3

Ok, no ha dado un modelo de datos normalizado como lo haría en una configuración SQL.

Según tengo entendido, no haces esto en MongoDB. Puede almacenar referencias, pero no por razones de rendimiento en el caso general.

No soy un experto en el área NoSQL de ninguna manera, pero ¿por qué no simplemente sigue sus necesidades y almacena el usuario (id) que ha votado por una historia en la colección de historias y la historia (id) ¿Ha votado un usuario en la colección de usuarios?

Answer 4

En CouchDB esto es muy simple. Una vista emite:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.story_id, doc.user_id);
 }
}

Se emite otra vista:

function(doc) {
 if(doc.type == "vote") {
   emit(doc.user_id, doc.story_id);
 }
}

Ambas son consultas extremadamente rápidas ya que no hay unión. Si necesita datos de usuario o datos de historia, CouchDB admite la obtención de documentos múltiples. También es bastante rápido y es una forma de hacer una " unirse " ;.

Answer 5

Últimamente he estado buscando mucho en MongoDB y CouchDB, pero mi visión es limitada. Aún así, al pensar en almacenar los votos dentro del documento de la historia, es posible que deba preocuparse por alcanzar el límite de tamaño de documento de 4 MB. Incluso si no lo hace, puede aumentar constantemente el tamaño del documento lo suficiente como para hacer que se mueva y, por lo tanto, ralentizar sus escrituras (vea cómo se dimensionan los documentos en MongoDB).

En cuanto a CouchDB, este tipo de cosas son bastante simples, elegantes y bastante rápidas una vez que se calculan los índices de visualización. Personalmente, sin embargo, he dudado en hacer un proyecto similar en CouchDB debido a los puntos de referencia que muestran que se desacelera progresivamente en un grado considerable a medida que crece la base de datos (y crecen los índices de visualización). Me encantaría ver algunos puntos de referencia más recientes que muestran el rendimiento de CouchDB a medida que aumenta el tamaño de la base de datos. QUIERO probar MongoDB o CouchDB, pero SQL todavía parece tan eficiente y lógico, así que me quedaré con él hasta que el proyecto se ajuste a la tentación.