504 reputation
210
bio website mongodb.org
location Sydney, Australia
age 32
visits member for 2 years, 3 months
seen Sep 17 at 1:24

Software generalist and aspiring writer with an unhealthy addiction to technology, lego, programmable toys, scripting languages, open source, and problem solving.

I work for MongoDB, Inc.

Disclaimer: opinions and technical advice given here are my own and do not represent an official statement by my employer.


Sep
12
comment Difference between mongod and mongodb upstart jobs
The reference links are to the official documentation but if you want a more specific source the packaging changes between 2.4 and 2.6 were related to SERVER-3579.
Sep
12
answered Difference between mongod and mongodb upstart jobs
Sep
1
comment MongoDB performance problem
Also, you don't need to have an index on both type:1 and { type: 1, imei:1 } as per your index list. A compound index on {type:1, imei:1} can be also be used to satisfy queries on type:1 (or more generically, any proper subset of keys that match the order of a compound index from left to right).
Sep
1
comment MongoDB performance problem
If all your documents have a type value of f, it isn't useful to include in the index. An index only helps with criteria that is selective and helps limit results. If your typical query is on imei ordered by time (descending), I would add an index on { imei: 1, time: -1}. Also, you do not need $and in your example query; this is implicit in a default query. What version of MongoDB are you using? Have you tried using explain() to look at the query plan?
Aug
29
comment Mongo stuck on save
How large is your hard drive? Have you checked the Windows Event log or MongoDB logs for any unusual errors?
Aug
29
comment Mongo stuck on save
Since you're running MongoDB 2.0.6 (released June-2012) an obvious starting recommendation would be to upgrade to the latest production release (currently 2.6.4) as there have been significant improvements in performance and concurrency in the past few years. The maximum data size on Windows with journaling enabled is 4TB, however 2TB sounds like a suspicious limit (eg. 2TB limit for drives partitioned with MBR scheme).
Aug
29
comment Mongo stuck on save
There isn't enough information in your screenshot to diagnose a performance issue and practically, this sort of discussion is beyond the scope of what can easily be answered via StackExchange. A good source of information would be the log files as well as the output of db.currentOp(). Asya's presentation on Diagnostics & Debugging provides some helpful case studies & tips if you want to drill down into this info a bit yourself.
Aug
29
comment Scaling mongoDB & Node.js
This is a very broad question - generic "scaling" depends on the subsystems that are limiting your performance. If your application is processing or memory bound, you would tune/scale out app servers/code. If your application is constrained by database performance you would tune/upgrade the database infrastructure. As a general best practice it is better to separate app servers from database servers so you can measure and scale resources appropriately, but the limiting factors are entirely dependent on your use case.
Aug
28
comment Mongo import error: exception:read error, or input line too long (max length: 16777216)
No, if you dump/restore via the mongos this will correctly route requests to the shards. You only get the config metadata if you dump the config database. Since you only have some specific collections to dump you can specify the -c (or --collection) name to mongodump. If you dump directly from a shard mongod this may include orphaned data (the mongos knows what data belongs to a shard; the mongod does not). Restoring directly to a shard mongod will add data the config servers don't know about and cause issues for sharded collections.
Aug
28
comment Mongo import error: exception:read error, or input line too long (max length: 16777216)
Sorry, I should have made that clearer. You need to mongodump and mongorestore via the mongos.
Aug
28
answered Mongo import error: exception:read error, or input line too long (max length: 16777216)
Aug
28
comment Mongo import error: exception:read error, or input line too long (max length: 16777216)
Are you trying to do a live migration to a parallel/new cluster running 2.6, or trying to migrate your 2.4 cluster to 2.6?
Aug
27
comment MongoDB thinks it's running a replica?
Could you share the connect string? Are you using any read preferences? Also, what version of MongoDB driver are you using? There aren't enough details to reproduce the problem yet, but I'd still suspect the client/driver code over the server at this point.
Aug
26
comment MongoDB thinks it's running a replica?
What does your MongoDB connect string look like? Perhaps the error is not on the server configuration (which looks to be standalone) but in your application connection. Also, what specific version of MongoDB 2.4 is this (and what host O/S)?
Aug
25
awarded  Yearling
Aug
25
comment Mongo Sort By Added Fields
Given this is a programming question, it is probably better suited for StackOverflow with the [meteor] and [minimongo] tags. In general it would be much more efficient to update a field to sort by (which can also be indexed) rather than computing this on every query. It sounds like updating an explicit field is your only option with MiniMongo, as a calculated sort field is normally only possible with the Aggregation Framework.
Aug
20
comment 1 million strings and exact match search
You're correct that duplicate key exceptions don't apply to upserts. My comment was that in general it doesn't seem sensible to recommend unacknowledged writes if you care about the data (in this case, maybe the OP does not). With regards to capped collections, your answer could be clearer that they aren't fit for the use case (FIFO vs the comments on scaling/sharding which seem a misdirection). I mentioned bulk inserts as an alternative to speeding up insertions (assuming that's the only reason you want unacknowledged writes). It seems implicit that bulk inserts are for multiple docs :).
Aug
20
comment 1 million strings and exact match search
Capped collections also aren't relevant for sharding as they are a fixed-size FIFO collection optimised for fast writes and sequential reads. You can't delete documents from a capped collection, and the documents are maintained in insertion order. If you need to scale writes beyond a single server, you should use a normal sharded collection.
Aug
20
comment 1 million strings and exact match search
I wouldn't presume that storing a million strings requires sharding; you should be able to comfortably wrangle that on a modern laptop :). I would also not recommend unacknowledged write concerns if you care about the data. A difference between default (acknowledged) writes and unacknowledged is that unack'd writes ignore insertion errors (for example, duplicate key exceptions). A more appropriate approach for speeding up insertion would be to use Bulk Inserts.
Aug
19
answered Updating Document in MongoDB without Alphabetically order