mongodb - español - límites del número de colecciones en las bases de datos
mongodb español (6)
¡No más límites!
Como han indicado otras respuestas, esto está determinado por el tamaño del archivo del espacio de nombres. Anteriormente, esto era un problema, ya que tenía un límite predeterminado de 16 mb y un máximo de 2 gb. Sin embargo, con el lanzamiento de MongoDB 3.0 y el motor de almacenamiento WiredTiger, parece que este límite se ha eliminado. WiredTiger parece ser mejor en casi todos los sentidos, así que veo pocas razones para que alguien use el viejo motor, excepto por razones de soporte heredado. Desde el sitio:
Para el motor de almacenamiento MMAPv1, los archivos de espacio de nombres no pueden tener más de 2047 megabytes.
Por defecto, los archivos de espacio de nombres son 16 megabytes. Puede configurar el tamaño con la opción nsSize.
El motor de almacenamiento WiredTiger no está sujeto a esta limitación.
¿Alguien puede decir que hay límites prácticos para la cantidad de colecciones en mongodb? Ellos escriben aquí http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections :
En general, tener una gran cantidad de colecciones no tiene una penalización de rendimiento significativa y da como resultado un muy buen rendimiento.
Pero por alguna razón mongodb estableció el límite 24000 para el número de espacios de nombres en la base de datos, parece que puede aumentarse, pero me pregunto por qué tiene algún límite en la configuración predeterminada si tener muchas colecciones en la base de datos no causa ningún rendimiento. ¿pena?
¿Significa que es una solución viable tener un número prácticamente ilimitado de colecciones en una base de datos, por ejemplo, tener una colección de datos de una cuenta en una base de datos para la aplicación multiusuario, teniendo, por ejemplo, cientos de miles de colecciones? en la base de datos? Si es la solución viable tener una gran cantidad de colecciones para una base de datos para cada inquilino, ¿cuáles son sus beneficios, por ejemplo, versus tener documentos de cada inquilino en una sola colección? Muchas gracias por sus respuestas.
Como otros mencionan, el tamaño de espacio de nombre predeterminado es de 16 MB y puede obtener alrededor de 24000 entradas de espacio de nombres. En realidad, mi instancia de 64 bits en Ubuntu alcanzó el 23684 usando el archivo de espacio de nombres predeterminado de 16MB.
Una cosa importante que no se menciona en las preguntas frecuentes es que los índices también usan ranuras de espacios de nombres.
Puede contar las entradas del espacio de nombres con:
db.system.namespaces.count()
Y también es interesante echar un vistazo a lo que hay allí:
db.system.namespaces.find()
Establezca su límite más alto de lo que cree que necesita porque una vez que se crea una base de datos, el archivo del espacio de nombres no se puede extender (por lo que yo entiendo, si hay alguna manera, ¡dígamelo!).
Esta respuesta es tardía, sin embargo, las otras respuestas parecen un poco ... débiles en términos de fiabilidad e información objetiva, así que intentaré remediar eso un poco.
Pero por alguna razón, mongodb estableció el límite 24000 para la cantidad de espacios de nombres en la base de datos,
Esa es simplemente la configuración predeterminada. Sí, hay una configuración predeterminada.
Sí dice en la página de límites que 24000 es el límite ( http://docs.mongodb.org/manual/reference/limits/#Number%20of%20Namespaces ), como si no hubiera forma de expandir eso, pero sí existe.
Sin embargo, hay un límite máximo de cuán grande puede ser un archivo de espacio de nombres ( http://docs.mongodb.org/manual/reference/limits/#Size%20of%20Namespace%20File ) que es de 2 GB. Eso le da aproximadamente 3 millones de espacios de nombres para jugar en la mayoría de los casos, lo cual es bastante impresionante y no estoy seguro de si muchas personas alcanzarán ese límite rápidamente.
Puede modificar el valor predeterminado para ir más allá de 16MB utilizando el parámetro nssize dentro de la configuración ( http://docs.mongodb.org/manual/reference/configuration-options/#nssize ) o en tiempo de ejecución manipulando el comando utilizado ejecutar MongoDB ( http://docs.mongodb.org/manual/reference/mongod/#cmdoption-mongod--nssize ).
No hay una razón real de por qué MongoDB implementa 16MB de forma predeterminada para su nssize hasta donde yo sé, nunca he oído sobre el lema de "no molestar al usuario con cada detalle", así que no compro ese.
Creo que, en mi opinión, la razón principal por la que MongoDB oculta esto es porque, a pesar de todo, como lo indica la documentación:
Las colecciones distintas son muy importantes para el procesamiento por lotes de alto rendimiento.
El uso de múltiples colecciones como medio para escalar verticalmente en lugar de horizontalmente a través de un clúster, como MongoDB está diseñado, se considera (bastante a menudo) una mala práctica para sitios web a gran escala; como tales, las colecciones de 12K normalmente se consideran algo que las personas nunca, y nunca deberían, determinar.
Parece que hay una sobrecarga masiva para mantener las colecciones. Acabo de reducir una base de datos que tenía alrededor de 1.5 millones de documentos en 11000 colecciones a una con el mismo número de documentos en alrededor de 300 colecciones; esto ha reducido el tamaño de la base de datos de 8GB a 1GB. No estoy familiarizado con el funcionamiento interno de MongoDB así que esto puede ser obvio, pero pensé que podría valer la pena notar en este contexto.
Prácticamente, nunca me he encontrado con un máximo. Pero definitivamente nunca he ido más allá del límite de 24,000 colecciones. Estoy bastante seguro de que nunca he golpeado más de 200, excepto cuando estaba realizando pruebas de rendimiento. Debo admitir que creo que es un caos tremendo tener tantas colecciones en una sola base de datos, en lugar de agrupar los datos en sus propias colecciones.
Considere la forma de sus datos y reglas comerciales. Si sus datos deben ser distribuidos de tal manera que usted debe tener los datos separados en diferentes agrupaciones lógicas para su aplicación multi-tenant, entonces probablemente debería considerar otros almacenes de datos. Porque aunque Mongo es excelente, el hecho de que pongan un límite a la cantidad de colecciones me dice que saben que hay un límite teórico en el que se realiza la ejecución.
Tal vez deberías considerar una tienda que coincida con la forma de los datos. Riak, por ejemplo, tiene un número ilimitado de ''cubos'' (sin el máximo teórico) que puede tener en su aplicación. Un cubo por cuenta es perfectamente factible, pero sacrificas cierta capacidad yendo en esa dirección.
De lo contrario, es posible que desee seguir un modelo de agrupación más relacional como con like. En mi opinión, Mongo se siente como un punto intermedio entre las bases de datos relacionales y las tiendas de valores clave. Eso significa que es más fácil conceptualizarlo desde un mundo de base de datos relacional.
Un poco de historia:
Cada vez que mongo crea una base de datos, crea un archivo de espacio de nombres (db.ns) para ella. El archivo de espacio de nombres (o colecciones como quiera llamarlo) contiene los metadatos sobre la colección. De forma predeterminada, el archivo del espacio de nombres tiene un tamaño de 16 MB, aunque puede aumentarlo manualmente. Los metadatos para cada colección son 648 bytes + algunos bytes de sobrecarga. Divida eso por 16 MB y obtendrá aproximadamente 24000 espacios de nombres por base de datos. Puede iniciar mongo especificando un archivo de espacio de nombres más grande y que le permitirá crear más colecciones por base de datos.
La idea detrás de cualquier configuración predeterminada es no molestar al usuario con cada detalle (y perilla configurable) y elegir uno que generalmente funcione para la mayoría de las personas. Además, la viabilidad va de la mano con las mejores / buenas prácticas de diseño. Como dijo Chris, considere la forma de sus datos y decida en consecuencia.