By default most drivers do asynchronous, 'unsafe' writes - this means that the driver does not return an error directly, similar to INSERT DELAYED with MySQL. The tradeoff is that you are not explicitly notified of failures. MongoDB allows very fast writes and updates by default.
Tl dr - Keep documents under 16M each and you'll be fine! Write failure Services such as Amazon S3 or Rackspace Cloudfiles are generally a much better option and don't load your infrastructure unnecessarily.
Generally, I would suggest avoiding storing large, irregularly updated objects in a database of any kind. This may sound like an annoyance, but 10gen's opinion on this is that if you are hitting this limit then either your schema design is wrong or you should be using GridFS, which allows arbitrarily sized documents. All recent versions support documents up to 16M in size. In older versions of MongoDB, documents were limited to 4M each. Like most other databases, there are limits to what you can store in a document. These documents are BSON, which is a binary format similar to JSON. Unlike a Relational Database Management System ( RDBMS) which stores data in columns and rows, MongoDB stores data in documents. Tl dr - Just use 64-bit, or understand the limitations of 32-bit Document size limits For setups that are sharded, you can use 32-bit builds for the mongos. If you're intending on storing more than 2G of data you should use a 64-bit build of MongoDB. For standard replicasets MongoDB only has a single process type - mongod. Due to the way MongoDB uses memory mapped files 32-bit builds can only store around 2G of data. MongoDB ships with two versions - 32-bit and 64-bit. Most modern hardware supports 64-bit operating systems, which are better because they permit more addressable memory space, i.e.
Most modern servers are either running 32-bit or 64-bit operating systems. I have learnt all of the following from experience. As well as co-founding the offical MongoDB London User Group, I am a MongoDB Master and have worked on installations from single servers all the way to projects with 30k queries per second and over a terabyte of active data. Everyone should be able to benefit from MongoDB's power and simplicity, and so as a follow up to David's article I have outlined some common and not-so-common things that hackers should know about MongoDB.įirst though, why should you listen to me? I used to be a consultant specializing in Ops and helping companies (The Guardian, Experian) scale large web applications.
In my opinion they're misguided - the main reason so many people think like this is a lack of understanding. this post has been updated as of July 29th, 2014 for content, and October, 2020 for links.Ī lot of people hate on MongoDB.
0 kommentar(er)
