Tengo una base de datos general de la estructura de la pregunta. En mi escenario que se me ocurre estar usando mongodb.

Estoy creando una aplicación en la que un usuario puede cargar una lista de canciones (título, artista, etc.) pero no estoy seguro de si debería tener una lista de canciones de la colección para todos los usuarios o con una lista de canciones.usuario# colección para cada usuario individual. Los usuarios solo pueden tener consulta de canciones asociadas a ellos por lo que Un usuario NUNCA se sabe acerca del usuario B canciones.

Ejemplos De Código:

Varias colecciones por usuario

db.songList.userA.find()
{"title": "Some song of user A", "artist": "Some artist of user A"}

db.songList.userB.find()
{"title": "Some song of user B", "artist": "Some artist of user B"}
  • Pros
    • Menor tamaño de la colección de consulta
  • Contras
    • Mantenimiento
      • De 1.000 usuarios que significa 1.000 colecciones

vs colección única con un ser dueño de campo ‘usuario’

db.songList.find({"user":"A"})
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"}
  • Pros
    • Flexibilidad para consulta a través de los usuarios si es necesario cada vez que se plantea
  • Contras
    • Rendimiento

Estoy tratando de construir un favor/en contra de la lista, pero todavía en la valla. Dado que cada usuario las canciones van a ser aislados unos de otros, cuál es el mejor procedimiento? Mi principal preocupación es el mantenimiento y el rendimiento de las consultas.

Gracias de antemano.

  • En lugar de preocuparse por cosas como esta, construir algo. Usted probablemente encontrará lo que va a funcionar mejor por la construcción de ésta, en lugar de preocuparse por los detalles.
  • De acuerdo con @SomeKittens. Dicho esto, me gustaría hacerlo por usuario, porque es más fácil cometer un error y mostrar Una de las canciones de los a B. de todos Modos, me preocuparía de optimización, si/cuando he tenido suficiente de los usuarios.
  • Seguridad-sabio, tener una colección por usuario hace posible el uso de Mongodb del nivel de colección de mecanismos de control de acceso. De esta manera, se podrá garantizar en el nivel de base de datos que un usuario nunca accesos otro de datos.
  • Tengo curiosidad por saber que el diseño que se fue con como estoy también se enfrenta a un dilema similar en el momento.
  • Colección única
InformationsquelleAutor Steven | 2012-12-10

2 Comentarios

  1. 12

    Yo recomendaría NOT para hacer la recogida selectiva por usuario.

    Leer el documentación

    Por defecto MongoDB tiene un límite de aproximadamente 24.000 espacios de nombres por
    la base de datos. Cada espacio de nombres es de 628 bytes, el .ns archivo es de 16 mb por
    por defecto.

    Cada colección cuenta como un espacio de nombres, como lo hace cada índice. Por lo tanto si
    cada colección tenía un índice, se pueden crear hasta 12.000
    las colecciones. El –nssize parámetro permite aumentar este límite
    (ver más abajo).

    Ser conscientes de que existe un cierto mínimo de sobrecarga por una colección —
    pocos KB. Además, cualquier índice se requieren por lo menos de 8 kb de espacio de datos como
    el b-árbol de tamaño de página es de 8KB. Ciertas operaciones puede obtener lento si no
    son un montón de colecciones y los meta datos se paginado.

    Entonces usted no será capaz de tratar correctamente si el usuario supera el límite de espacio de nombres. También no va a ser alto rendimiento con el crecimiento de su base de usuarios.

    ACTUALIZACIÓN

    Como @Henry Liu se menciona en los comentarios. Para Mongodb 3.0 o superior con WiredTiger motor de almacenamiento, dejará de ser el límite.

    docs.mongodb.org/manual/reference/limits/#namespaces

    • Gracias por la info, pero leyendo el siguiente párrafo describe cómo –nssize puede ser utilizado para este límite Máximo .ns tamaño del archivo es de 2 gb). Así que si cada lista de canciones de la colección tiene sólo 1 índice I pueden, en teoría, han de 240.000+ colecciones antes de acercarse a los 2GB. (Este límite es casi cortado por la mitad si tengo 2 índices por la colección).
    • Es obvio que se puede modelar cualquier manera que usted desea. Todo lo que hice fue recomendado un elegante enfoque 🙂
    • Gracias, tu aporte fue muy útil, después de leer esta información de múltiples colección no parece necesario ya que puedo hacer lo que necesito en una sola colección, evitando los límites de espacio de nombres.
    • Como de mongodb 3.0 o superior y si uso WiredTiger motor de almacenamiento, dejará de ser el límite. docs.mongodb.org/manual/reference/limits/#namespaces
    • Gracias @HenryLiu escribí la respuesta camino de regreso en el 2012. Gracias por la actualización de la información. He añadido la actualización en mi respuesta.
  2. 9

    MongoDB es grande en el escalado horizontal. Puede fragmento de una colección a través de una dinámica de clúster para producir un rápido, querable recogida de sus datos.

    Así que tener un menor tamaño de la colección no es realmente un pro y no estoy seguro de que esta teoría viene que es, no lo es en SQL y no en MongoDB. El rendimiento de la fragmentación, si se hace bien, en relación con el rendimiento de la consulta de una sola pequeña colección de datos (con una pequeña sobrecarga). Si no es así entonces usted tiene la configuración de su fragmentación mal.

    MongoDB no es muy grande, en la escala vertical, como @Sushant citado, el ns tamaño de MongoDB sería una grave limitación. Una cosa que cita no menciona es que el tamaño del índice y contar también el efecto de la ns tamaño de ahí, por qué se describe que:

    Por lo tanto si cada colección tenía un índice, se pueden crear hasta 12.000 colecciones. El –nssize parámetro permite aumentar este límite (ver más abajo).

    • Yo había leído this lo que me llevó a creer que yo iba a ver un aumento de rendimiento significativo con múltiples colecciones de menor tamaño. Estás diciendo que si yo fuera a tener una colección con un fragmento de la clave en el campo de usuario debería ver una similar ganancia de rendimiento?
    • Hay demasiadas incógnitas decir exactamente por qué él estaba recibiendo esos tiempos, los tiempos de las consultas son tan dependientes de hardware, índices, datos, normalización, etc. Sin embargo, él tiene en cuenta que la consulta fue rápido cuando él tenía un gran número de registros, el problema era que cuando él estaba usando un pequeño número de selectividad en su índice (bajo número de registros de tipo con precios > 100) que me lleva a creer que su índice no era bueno para su consulta.
    • Sí, un fragmento clave en algo como user_id (un poco de adivinar aquí, usted debe realmente reallllllly de investigación para que sus datos), se produciría un retorno decente para las consultas que contienen un user_id. Sin embargo, no es la imagen completa con la fragmentación y me gustaría strongely recomendamos hacer una búsqueda en el aquí y en google antes al instante pensando que user_id va a resolver sus problemas de fragmentación.
    • Gracias a su aporte fue muy útil, si me necesita para optimizar el rendimiento de la consulta después de la aplicación de la única colección que voy a hacer más investigación y jugar con los fragmentos.

Dejar respuesta

Please enter your comment!
Please enter your name here