If I do create a hashed index with ensureIndex({ _id: "hashed"}) will Mongo know to take any queries on the _id field and run them against the hashed index? Or do I need to update all the queries that use _id to be the _id_hashed?
Mongodb doesn't modify the _id field when a hashed index is created. It will do the right thing, and query against _id appropriately. The hash will only be used to query and balance the shards.
Related
If I insert a document, directly with a mongodb client or with Mongoose, who is responsible to generate the _id field's value? Is it happening inside the database engine or the clients do the work?
In MongoDB, each document stored in a collection requires a unique _id field that acts as a primary key. If an inserted document omits the _id field, the MongoDB driver automatically generates an ObjectId for the _id field.
Note
Most MongoDB driver clients will include the _id field and generate an ObjectId before sending the insert operation to MongoDB; however, if the client sends a document without an _id field, the mongod will add the _id field and generate the ObjectId.
https://docs.mongodb.com/manual/core/document/index.html#the-id-field
Is there any possibilities of without having _id field in mongodb collection??
I don't want it because i need to load mongodb data into apache pig, which will not support _id.
So, i just don't want _id field in my mongodb collections.
Anyone please help..
Thanks in advance.
No, you can't. The _id field is required for internal purposes in MongoDB. It is the MongoDB equivalent to a primary key in a relational database. Every document must have an unique _id field. It does not necessarily need to be an ObjectId, but it must be a value unique to the collection. But you can query data without the ID field:
db.yourCollection.find({ ...query... }, { _id: false } );
I have sharded collection with shard key as hashed _id (docs ).
Now I want to add index on another field (called alias) which doesn't need to be unique but it should be sparse if possible. This new index would serve only for speeding my query.
Should I do some kind of compound index for this or there is another procedure if possible in the first place?
In app I make only 2 types of queries :
db.myCollection.findOne({alias : 'some-alias'})
db.myCollection.findOne({_id : 'some-id'})
The second one works as supposed to (because my shard key is on hashed _id field) but first query is problem.
Thanks,
Ivan
Lets say you have a collection with a field called "primary_key",
{"primary_key":"1234", "name":"jimmy", "lastname":"page"}
and I have an index on "primary_key".
This collection has millions of rows, I want to see how expensive is to change primary_key for one of the records. Does it trigger a reindex of the entire table? or does it just reindex the changed record? in either case is that expensive to do?
Updating an indexed field in mongodb causes an update of the index (or indices if you have more than one) that use it. It does not "reindex". Shouldn't be all that expensive - effectively you will delete the old entry and insert a new one.
This document has a fair amount of detail on mongodb indexes:
http://docs.mongodb.org/master/MongoDB-indexes-guide.pdf
BTW, keep in mind that there is one special field, _id, that mongodb uses as it's primary key
_id
A field required in every MongoDB document. The _id field must have a unique value. You can think of the _id field as the document’s
primary key. If you create a new document without an _id field,
MongoDB automatically creates the field and assigns a unique BSON
ObjectId.
You cannot update the _id field.
I am building a webapp using Codeigniter (PHP) and MongoDB.
I am creating indexes and have one question.
If I am querying on three fields (_id, status, type) and want to
create an index do I need to include _id when ensuring the index like this:
db.comments.ensureIndex({_id: 1, status : 1, type : 1});
or will this due?
db.comments.ensureIndex({status : 1, type : 1});
You would need to explicitly include _id in your ensureIndex call if you wanted to include it in your compound index. But because filtering by _id already provides selectivity of a single document that's very rarely the right thing to do. I think it would only make sense if your documents are very large and you're trying to use covered indexes.
MongoDB will currently only use one index per query with the exception of $or queries. If your common query will always be searching on those three fields (_id, status, type) then a compound index would be helpful.
From within the DB shell you can use the explain() command on your query to get information on the indexes used.
You don't need to implicitly create index on the _id field, it's done automatically. See the mongo documentation:
The _id Index
For all collections except capped collections, an index is automatically created for the _id field. This index is special and cannot be deleted. The _id index enforces uniqueness for its keys (except for some situations with sharding).