Hot answers tagged

3

You can only use the $regex operator to match values that are strings. As you've noted, an ObjectID is a 12-byte binary value stored as a specific BSON type. You should instead use the $type operator to query based on the BSON data type of a field. Example usage of $type: // Find all restaurants where `_id` is not an ObjectId (type 7) db.restaurants.find({...


2

As at MongoDB 3.2, the only supported key for a sharded output collection for Map/Reduce is the _id field (non-hashed). There are known issues with Map/Reduce output to a sharded collection using a hashed shard index; the two features don't play well together yet and this isn't a supported combination. The documentation currently only suggests that _id can ...


2

I just ran into the same problem...it took a while to find, but the deprecation is documented in the native driver for Node: use find().limit(1).next(function(err, doc){}) This is for the 2.1.20 version of mongodb.


2

A configuration with three voting nodes in different data centres plus an additional non-voting delayed secondary is definitely supported. This is actually a reasonable configuration in terms of satisying core availability requirements using the distributed voting nodes with additional hidden/non-voting nodes for special use cases. A delayed secondary should ...


2

A graph database would be a good candidate. They specialise at retrieving interconnected data and navigating the relationships between objects. The ones I'm familiar with allow dynamic schema so different objects can have different values. Some allow classes of objects to be constructed so some consistency can be enforced. The links between objects are ...


1

I'm not sure if you're using cursors on your client side but due to your long query, you could be hitting a internal timeout of 10 minutes. If you do check out Jira Ticket SERVER-3090 on Mongo. If you are not using cursors then you can look at changing the _waitForDelete option in the balancers so the primary waits for the replicas to process the delete ...


1

You'll need to rethink your shard key approach. As at MongoDB 3.2: All fields in a compound shard key must be present in all documents and will be immutable (i.e. the shard key for an existing document cannot be changed). A hashed shard key is based on a single field, and does not support range queries. It generally makes sense to have a shard key that ...


1

Switching a primary in a replica set to a standalone will not impact CPU unless you were offloading something to the secondaries that will now hit the standalone node like reads or Map Reduce (and you mention you were not). As well as that, mongod is generally not CPU intensive unless you are doing lots of sorts or distincts (or a lot of javascript, Map ...


1

I'd recommend looking into pre-splitting and/or using a hashed shard key to do the insertion and stick with dropping the collection (with remove you are basically doing a delete for every write, so it will always be slow). The hashed shard key is usually the easiest one to get started with. If you are looking to measure write throughput then each of those ...


1

You mention the smallfiles option (from ObjectRocket docs) but your ls output suggests that you are not actually using it. If you were, then your maximum file size would be 512MB but you have 2GB files (the default). It also explains your issues. As soon as you fill up your existing data files and another write comes in (it's a little more complicated ...


1

It looks like you are using NMAP as storage engine. From mongo 3.2 it was changed to WiredTiger as it is more efficient in space usage and allows to add compression - which in your case could be a plus. As NMAp reserves file storage using power of 2 and padding when storing documents - it is less disk storage effective and reservers lot more than is needed (...


1

Since you are using the MMAP storage engine there are several factors to be aware of: The compact command only defragments data files & indexes in MMAP; it does not release unused space to the operating system. Running compact can still be useful to reduce fragmentation and encourage free space reuse, but will not help if your disk space is critically ...


1

The large number of nscanned key comparisons is explainable by the skip value: the query is skipping 903,462 documents (ntoskip) in order to return 21 (ntoreturn). The nscanned value in your output is the sum of ntoskip and ntoreturn. The number of nscannedObjects (identical to nscanned) is because the skip stage in MongoDB 2.6.x query processing happens ...



Only top voted, non community-wiki answers of a minimum length are eligible