I just discovered a bizarre behavior exhibited by MongoDB.
Apparently, any collection name with the string "system." anywhere in it will just not function correctly.
To make matters worse, it won't even tell you anything is wrong!
It's really more a matter of curiosity, but does anybody have any idea why this would happen? Is it documented somewhere?
My assumption is that it uses ""system.*" collections to store things internally (like indexes) and doesn't want you messing with them, but this doesn't seem like the correct behavior to me.
You are correct "system.*" is a reserved collection namespace used by MongoDB in each DB.
It is used to store indexes and users, etc.
SQL Server has many such tables too, and I don't believe they warn you not to use them either :)
But you could always put in a request for such functionality: http://jira.mongodb.org/
You can see them by running ...
> show collections
and you'll see something like ...
system.indexes
system.users
So, you can see your indexes for example:
> db.system.indexes.find()
From the MongoDB docs:
The .system.* namespaces in
MongoDB are special and contain
database system information. System
collections include:
system.namespaces lists all namespaces.
system.indexes lists all indexes.
Additional namespace / index metadata exists in the database.ns
files, and is opaque.
system.profile stores database profiling information.
system.users lists users who may access the database.
local.sources stores replica slave configuration data and state.
Information on the structure of a stored object is stored within the
object itself. See BSON .
There are several restrictions on
manipulation of objects in the system
collections. Inserting in
system.indexes adds an index, but
otherwise that table is immutable (the
special drop index command updates it
for you). system.users is modifiable.
system.profile is droppable.
http://docs.mongodb.org/manual/reference/system-collections/
Related
This seems like a very simple task, but after implementing role-based access control in a database on MongoDB, I am having trouble granting them access to nonspecific collections of said database. Right now, I've granted permissions to the find, insert, remove, and update actions to default users, and left the "Collection" section blank to assign these users to all collections by default (shown in the image below). However, instead of being assigned to all collections, they are assigned to none, and none of the existing collections show up under the main database when connecting to the deployment on MongoDB compass.
To work around this, I specified all of the existing collections, one-by-one, in an individual collection section (shown below). This technically solves the problem, but this is painstaking work when there exist many collections, and it means that I will have to manually make changes (which is undesirable) when collections are added/removed as the database grows/shrinks. Noting this, is there a way to specify all collections, kind of similar to how the * asterisk works in a MySQL statement or Python function call?
I've also seen this solution, but I'm wondering if it is possible to do this without resorting to MongoDB shell?
Is there a way to switch off the ability of mongo to sporadically create dbs and collections as soon as it sees one in a query. I run queries on the mongo console all the time and mistype a db or collection name, causing mongo to just create one. There should be a switch to have mongo only explicitly create dbs and collections. I can't find one on the docs.
To be clear, MongoDB does not auto create collections or databases on queries. For collections, they are auto created when you actually save data to them. You can test this yourself, run a query on a previously unknown collection in a database like this:
use unknowndb
db.unknowncollection.find()
show collections
No collection named "unknowncollection" shows up until you insert or save into it.
Databases are a bit more complex. A simple "use unknowndb" will not auto create the database. However, if after you do that you run something like "show collections" it will create the empty database.
I agree, an option to control this behavior would be great. Happy to vote for it if you open a Jira ticket at mongoDB.
No, implicit creation of collections and DBs is a feature of the console and may not be disabled. You might take a look at the security/authorization/role features of 2.6 and see if anything might help (although there's not something that exactly matches your request as far as I know).
I'd suggest looking through the MongoDB issues/bug/requests database system here to and optionally add the feature request if it doesn't already exist.
For people who are using Mongoose, a new database will get created automatically if your Mongoose Schema contains any form of index. This is because Mongo needs to create a database before it can insert said index.
Is there a way to switch off the ability of mongo to sporadically create dbs and collections as soon as it sees one in a query. I run queries on the mongo console all the time and mistype a db or collection name, causing mongo to just create one. There should be a switch to have mongo only explicitly create dbs and collections. I can't find one on the docs.
To be clear, MongoDB does not auto create collections or databases on queries. For collections, they are auto created when you actually save data to them. You can test this yourself, run a query on a previously unknown collection in a database like this:
use unknowndb
db.unknowncollection.find()
show collections
No collection named "unknowncollection" shows up until you insert or save into it.
Databases are a bit more complex. A simple "use unknowndb" will not auto create the database. However, if after you do that you run something like "show collections" it will create the empty database.
I agree, an option to control this behavior would be great. Happy to vote for it if you open a Jira ticket at mongoDB.
No, implicit creation of collections and DBs is a feature of the console and may not be disabled. You might take a look at the security/authorization/role features of 2.6 and see if anything might help (although there's not something that exactly matches your request as far as I know).
I'd suggest looking through the MongoDB issues/bug/requests database system here to and optionally add the feature request if it doesn't already exist.
For people who are using Mongoose, a new database will get created automatically if your Mongoose Schema contains any form of index. This is because Mongo needs to create a database before it can insert said index.
In a system I'm building, it's essentially an issue tracking system, but with various issue templates. Some issue types will have different formats that others.
I was originally planning on using MySQL with a main issues table and an issues_meta table that contains key => value pairs. However, I'm thinking NoSQL (MongoDB) might be the better option.
Can MongoDB provide me with the ability to generate "standard"
reports, like # of issues by type, # of issues by type by month, # of
issues assigned per person, etc? I ask this because I've read a few
sources that said Mongo was bad at reporting.
I'm also planning on storing my audit logs in Mongo, since I want a single "table" for all actions (Modifications to any table). In Mongo I can store each field that was changed easily, since it is schemaless. Is this a bad idea?
Anything else I should know, and will Mongo work for what I want?
I think MongoDB will be a perfect match for that use case.
MongoDB collections are heterogeneous, meaning you can store documents with different fields in the same bag. So different reporting templates won't be a show stopper. You will be able to model a full issue with a single document.
MongoDB would be a good fit for logging too. You may be interested in capped collections.
Should you need to have relational association between documents, you can do have it too.
If you are using Ruby, I can recommend you Mongoid. It will make it easier. Also, it has support for versioning of documents.
MongoDB will definitely work (and you can use capped collections to automatically drop old records, if you want), but you should ask yourself, does it fit to this task well? For use case you've described it is better option to use Redis (simple and fast enough) or Riak (if you care a lot about your log data).
From my experience this is what i come up with.
Im currently saving Users and Statistic classes into the MongoDb and everything works grate.
But how do i save the log each user generate?
Was thinking to use the LogBack SiftingAppender and delegate the log information
to separate MongoDb Collections. Like every MongoDb Collection have the id of the user.
That way i don't have to create advanced mapreduce query's since logs are neatly stacked.
Or use SiftingAppender with a FileAppender so each user have a separate log file.
I there is a problem with this if the MongoDB have one million Log Collections each one named with the User Id. (is it even possible btw)
If everything is stored in the MongoDb the MongoDb master-slave replication makes
it easy if a master node dies.
What about the FileAppender approach. Feels like there will be a hole lot of log files
to administrate. One could maybe save them in folders according to Alphabet. Folder A
for user/id with names/id starting with A.
What are other options to make this work?
On your qn of 1M collections, the default namespace file for a db is 16MB which allows about 24000 namespaces (12000 collections + their _id indexes). More info on this website
And you can set maximum .ns (namespace) file size to 2GB with --nssize option, which will allow probably 3072000 namespaces.
Make use of Embedded Documents and have one Document for each user with an array of embedded documents containing log files. You can also benefit from sharding if collections get large.