@@ -299,11 +299,12 @@ Glossary
299
299
300
300
journal
301
301
A sequential, binary transaction used to bring the database into
302
- a consistent state in the event of a hard shutdown. The journal is
303
- enabled by default in MongoDB v2.0 and later. When enabled,
304
- MongoDB writes data first to the journal and after to the core
305
- data files. Journal commits are synced to disk every 100ms, but
306
- this is configurable using the ``journalCommitInterval `` option.
302
+ a consistent state in the event of a hard shutdown. MongoDB
303
+ enables journaling by default for 64-bit builds of MongoDB
304
+ version 2.0 and later. When enabled, MongoDB writes data first
305
+ to the journal and after to the core data files. MongoDB commits
306
+ to the Journal every 100ms, but this is configurable using the
307
+ :setting: `journalCommitInterval ` runtime option.
307
308
308
309
.. seealso :: The ":wiki:`Journaling`" wiki page.
309
310
@@ -340,21 +341,12 @@ Glossary
340
341
341
342
padding factor
342
343
An automatically-calibrated constant used to determine how much
343
- extra space should be allocated per document container on disk.
344
+ extra space MongoDB should allocate per document container on disk.
344
345
A padding factor greater than 1 may allow a document to be rewritten
345
- in-place if the document is ever enlarged by an update.
346
-
347
-
348
- TODO: I don't believe that there's any reason to define lock in the abstract.
349
-
350
- lock
351
- An approach to concurrency where a single process or thread
352
- prevents sibling process from accessing or changing a value
353
- until the original process or thread has completed its
354
- operation.
346
+ in-place if an update requires the document to grow.
355
347
356
348
read-lock
357
- In the context of a reader-writer lock, a :term: ` lock ` that while
349
+ In the context of a reader-writer lock, a lock that while
358
350
held allows concurrent readers, but no writers.
359
351
360
352
config database
@@ -364,8 +356,8 @@ TODO: I don't believe that there's any reason to define lock in the abstract.
364
356
balancer
365
357
An internal MongoDB process that runs in the context of a
366
358
:term: `shard cluster ` and manages the splitting and
367
- migration of :term: `chunks <chunk> `. The balancer must
368
- be disabled for all maintenance operations on a shard cluster.
359
+ migration of :term: `chunks <chunk> `. Administrators must disable
360
+ the balancer for all maintenance operations on a shard cluster.
369
361
370
362
fsync
371
363
An system call that flushes all dirty, in-memory pages to disk. MongoDB
@@ -375,7 +367,8 @@ TODO: I don't believe that there's any reason to define lock in the abstract.
375
367
In the context of a :term: `shard cluster `, a chunk is a contiguous
376
368
range of :term: `shard key ` values assigned to a particular :term: `shard `.
377
369
By default, chunks are 64 megabytes or less. When they grow beyond the
378
- configured chunk size, they are split in two.
370
+ configured chunk size, a :program: `mongos ` splits the chunk into
371
+ two chunks.
379
372
380
373
geospatial
381
374
Data that relates to geographical location. In MongoDB, you may
@@ -396,11 +389,13 @@ TODO: I don't believe that there's any reason to define lock in the abstract.
396
389
397
390
.. code-block :: javascript
398
391
399
- db .places .ensureIndex ({ position: " geoHaystack" , type: 1 } )
392
+ db .places .ensureIndex ( { position: " geoHaystack" , type: 1 } )
400
393
401
394
You can then query on position and type:
402
395
403
- db.places.find({position: [34.2, 33.3], type: "restaurant"})
396
+ .. code-block :: javascript
397
+
398
+ db .places .find ( { position: [34.2 , 33.3 ], type: " restaurant" } )
404
399
405
400
oplog
406
401
A :term: `capped collection ` that stores an ordered history of
@@ -424,8 +419,6 @@ TODO: I don't believe that there's any reason to define lock in the abstract.
424
419
each running process. You can use a process's PID to inspect
425
420
a running process and send signals to it.
426
421
427
- TODO: where is this even used in the docs?
428
-
429
422
JSONP
430
423
:term: `JSON ` with Padding. Refers to a method of injecting JSON
431
424
into applications. Presents potential security concerns.
@@ -434,7 +427,7 @@ TODO: where is this even used in the docs?
434
427
An API design pattern centered around the idea of
435
428
resources and the CRUD operations that apply to them. Typically
436
429
implemented over HTTP. MongoDB provides a simple HTTP REST interface
437
- that allows commands to be run against the server.
430
+ that allows HTTP clients to run commands against the server.
438
431
439
432
dbpath
440
433
Refers to the location of MongoDB's data file storage. The
@@ -447,17 +440,18 @@ TODO: where is this even used in the docs?
447
440
set name
448
441
In the context of a :term: `replica set `, the ``set name `` refers to
449
442
an arbitrary name given to a replica set when it's first configured.
450
- All members of a replica set must have the same name, which is specified
451
- using the ``--replSet `` flag on :program: `mongod `.
443
+ All members of a replica set must have the same name specified
444
+ with the :setting: `replSet ` setting (or :option: `--replSet
445
+ <mongod --replSet> ` option for :program: `mongod `.)
452
446
453
447
.. seealso :: :term:`replication`, ":doc:`/replication`" and
454
448
":doc: `/core/replication `."
455
449
456
450
_id
457
451
A field containing a unique ID, typically a BSON Object ID.
458
- If not specified, this value is automatically assigned
459
- when a new document is created. The `` _id `` field can
460
- be thought of as a document's :term: `primary key `.
452
+ If not specified, this value is automatically assigned while
453
+ upon the creation of a new document. You can think of the
454
+ `` _id `` as the document's :term: `primary key `.
461
455
462
456
lvm
463
457
Logical volume manager. LVM is a program that abstracts disk
@@ -475,8 +469,8 @@ TODO: where is this even used in the docs?
475
469
primary key
476
470
A record's unique, immutable identifier. In an RDBMS, the primary
477
471
key is typically an integer stored in each row's ``id `` field.
478
- In MongoDB, a document's primary key is stored in a document's :term: ` _id `
479
- field and is usually a BSON Object ID .
472
+ In MongoDB, the :term: ` _id ` field holds a document's primary
473
+ key. Primary keys are usually :term: ` BSON ` Object IDs .
480
474
481
475
unique index
482
476
An index that enforces uniqueness for a particular field across
@@ -493,19 +487,21 @@ TODO: where is this even used in the docs?
493
487
profiler is most often used to diagnose slow queries.
494
488
495
489
shard key
496
- In a sharded collection, a shard key is the field whose value
497
- is used to distribute documents among members of the
490
+ In a sharded collection, a shard key is the field that MongoDB
491
+ uses to distribute documents among members of the
498
492
:term: `shard cluster `.
499
493
500
494
query
501
- A read request. MongoDB queries use a :term: `JSON `-like
502
- query language that includes a variety of :term: `database operators ` whose names
503
- begin with a ``$ `` character. In the :program: `mongo ` shell, you can issue queries
504
- using the :func: `db.collection.find() ` and :func: `db.collection.findOne() ` methods.
495
+ A read request. MongoDB queries use a :term: `JSON `-like query
496
+ language that includes a variety of :term: `query operators <operator> `
497
+ with names that begin with a ``$ `` character. In the
498
+ :program: `mongo ` shell, you can issue queries using the
499
+ :func: `db.collection.find() <find> ` and
500
+ :func: `db.collection.findOne() <findOne> ` methods.
505
501
506
502
projection
507
503
A document given to a :term: `query ` that specifies which fields
508
- from the documents in the result set should be returned .
504
+ MongoDB will return from the documents in the result set.
509
505
510
506
pre-splitting
511
507
When deploying a :term: `shard cluster `, it is sometimes
@@ -531,7 +527,7 @@ TODO: where is this even used in the docs?
531
527
pipe
532
528
A communication channel UNIX allowing independent processes
533
529
to send and receive data. In the UNIX shell, piped operations
534
- allow the output of one commmand to be passed as the input
530
+ allow users to direct the output of one command into the input
535
531
of another.
536
532
537
533
IPv6
@@ -559,48 +555,38 @@ TODO: where is this even used in the docs?
559
555
consistency and, therefore, does not provide multi-master replication.
560
556
561
557
rollback
562
- A process that, in certain replica set situations, reverts writes opertaions
563
- to ensure the consistency of all replica set members.
564
-
565
- TODO: we need to rewrite the definitely completely. There are lots of
566
- valid definitions, and it depends on the context.
567
-
568
- consistency
569
- The condition "up to date," and reliable quality of a database
570
- system with multiple nodes and multiple instances of the same
571
- data. A system may be ":term: `eventually consistent <eventual
572
- consistency> `," with write or update operations returning
573
- successfully before all copies of the data are in a consistent
574
- state, or ":term: `strictly consistent <strict consistency> `,"
575
- with no write or update operations returning before all copies of
576
- the data are in a consistent state.
558
+ A process that, in certain replica set situations, reverts
559
+ writes operations to ensure the consistency of all replica set
560
+ members.
577
561
578
562
eventual consistency
579
563
A property of a distributed system allowing changes to the
580
564
system to propagate gradually. In a database system, this means
581
- that readable nodes are not required to reflect the latest writes
582
- at all times. In MongoDB, reads to a primary are consistent; reads
583
- to secondary nodes are eventually consistent.
565
+ that readable nodes are not required to reflect the latest
566
+ writes at all times. In MongoDB, reads to a primary have
567
+ :term: `strict consistency `; reads to secondary nodes have
568
+ :term: `eventual consistency `.
584
569
585
570
strict consistency
586
- A property of a distributed system requiring that all nodes always
587
- reflect the latest changes to the system. In a database system, this means
588
- that readable nodes are required to reflect the latest writes
589
- at all times. In MongoDB, reads to a primary are consistent; reads
590
- to secondary nodes are eventually consistent.
571
+ A property of a distributed system requiring that all nodes
572
+ always reflect the latest changes to the system. In a database
573
+ system, this means that any system that can provide data must
574
+ reflect the latest writes at all times. In MongoDB, reads to a
575
+ primary have :term: `strict consistency `; reads to secondary
576
+ nodes have :term: `eventual consistency `.
591
577
592
578
write concern
593
579
A setting on writes to MongoDB that allows the use to specify,
594
- among other things, how far a write should be replicated
595
- before returning.
580
+ how the database will handle a write operation before
581
+ retiring. This often determines how many :term: `replica set `
582
+ members should propagate a write before returning.
596
583
597
- .. seealso :: ":ref:`Write Concern for Replica Sets
598
- <replica-set-write-concern>`."
584
+ .. seealso :: ":ref:`Write Concern for Replica Sets <replica-set-write-concern>`."
599
585
600
586
priority
601
587
In the context of :term: `replica sets <replica set> `, priority
602
- is a configurable values that help determine whih nodes in
603
- a replica set are most likely to be elected: term:`primary `.
588
+ is a configurable values that help determine which nodes in
589
+ a replica set are most likely to become : term: `primary `.
604
590
605
591
.. seealso :: ":ref:`Replica Set Node Priority
606
592
<replica-set-node-priority>`"
@@ -640,10 +626,13 @@ valid definitions, and it depends on the context.
640
626
.. seealso :: ":ref:`Delayed Nodes <replica-set-delayed-members>`"
641
627
642
628
read preference
643
- A setting on the MongoDB drivers that determines where reads
644
- to any replica set, including shards, should be directed. By
645
- default, reads are directed to primary nodes. However, you may
646
- also direct reads to secondary nodes.
629
+ A setting on the MongoDB :doc: `drivers </applications/drivers >`
630
+ that determines where how the clients direct read
631
+ operations. Read preference affects all replica sets including
632
+ shards. By default, drivers direct all reads to :term: `primary `
633
+ nodes for :term: `strict consistency `. However, you may also
634
+ direct reads to secondary nodes for :term: `eventually consistent
635
+ <eventual consistency> ` reads..
647
636
648
637
.. seealso :: ":ref:`Read Preference <replica-set-read-preference>`"
649
638
@@ -671,7 +660,7 @@ valid definitions, and it depends on the context.
671
660
.. seealso :: ":ref:`Replica Set Failover <replica-set-failover>`."
672
661
673
662
data-center awareness
674
- A property that allows nodes in a system to be addressed
663
+ A property that allows clients to address nodes in a system to
675
664
based upon their location.
676
665
677
666
:term: `Replica sets <replica set> ` implement data-center
@@ -767,5 +756,7 @@ valid definitions, and it depends on the context.
767
756
namespace.
768
757
769
758
replica pairs
770
- The precursor to the MongoDB :term: `replica sets <replica set> `. Replica
771
- pairs were deprecated in MongoDB v1.6.
759
+ The precursor to the MongoDB :term: `replica sets <replica
760
+ set> `.
761
+
762
+ .. deprecated :: 1.6
0 commit comments