Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The on-disk storage of documents in MongoDB is in BSON format. There is a detailed description of the BSON format here: - <a href="http://bsonspec.org/#/specification" rel="nofollow">http://bsonspec.org/#/specification</a></p> <p>While there is some disk savings from using short key names (since, as you can see by looking at the spec, the key name is embedded in the document), it looks to me like there'd be almost no net difference between the two designs in terms of on-disk space used -- the extra bytes you use by using the delimiters (-) get bought back by not having to have string terminators for the separate key values.</p> <p>$inc updates should take almost identical times with both formats, since they're both going to be in-memory operations. Any improvements in in-memory update time are going to be the tiniest of rounding errors compared to the time taken to read the document off of disk.</p> <p>The performance of new key inserts should also be virtually identical. If adding the new key/value pair leaves the new document small enough to fit in the old location on disk, then all that happens is the in-memory version is updated and a journal entry gets written. Eventually, the in-memory version will be written to disk.</p> <p>New key inserts are more problematic if the document grows beyond the space previously allocated for it. In that case, the server must move the document to a new location and update all indexes pointing to that document. This is generally a slower operation, and should be avoided However, the schema changes that you're discussing shouldn't affect the frequency of document movement. Again, I think this is a wash.</p> <p>My suggestion would be to use the schema that most lends itself to developer productivity. If you're having performance problems, then you can ask separate questions about how you can either scale your system or improve performance, or both.</p>
    singulars
    1. This table or related slice is empty.
    1. POMongoDB data schema performance
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USWilliam Z
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMongoDB data schema performance
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COReading the BSON spec it looks like arrays and documents cannot have any padding for future use. Do you read it the same way? This seems a bit strange: to add a single key in a 100K doc they may need to modify many blocks on disk as up to 100K of data may need to be moved by a few bytes.
      singulars
      1. PO
      1. USSim
    2. COYou're right about the spec. MongoDB can allocate additional space for the document (a padding factor) above what the spec allows: http://www.mongodb.org/display/DOCS/Padding+Factor In addition, you can use a manual padding factor when you initially create the document: http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding
      singulars
      1. PO
      1. USWilliam Z
    3. COIn MongoDB, when a document outgrows its slot, only that document is moved: the documents around it are left untouched. When a document is moved, it is moved into a new record which is big enough to hold it's new size (plus any padding factor). The extra I/O comes from re-indexing, not from moving other documents.
      singulars
      1. PO
      1. USWilliam Z
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload