DB Practices For MongoDB
DB Practices For MongoDB
Developers -MongoDB
Adobe IT Cloud - DaaS
mongo --port <Port> --host <Server Name> -u <User Name> -p <Password> <Database Name>
Note: <….> fields should be filled with details you received via email after you created Mongo
DB database.
There are other multiple ways to connect to mongo DB database using different supported
drivers and clients. See more details in http://docs.mongodb.org/ecosystem/drivers/
o By default, mongo looks for a database server listening on port 27017 on the localhost interface.
To connect to a server on a different port or interface, always use the --port and --host options.
o When we create a new database using “use mydb”, please note Mongo DB will not permanently
create a database until you insert data into that database.
b. All Mongo DB documents must have an _id field with a unique value. These operations
do not explicitly specify a value for the _id field, so mongo creates a
unique ObjectId value for the field before inserting it into the collection.
Collection names should begin with an underscore (_) or a letter character and cannot:
i. contain the $.
ii. be an empty string (e.g. "").
iii. contain the null character.
iv. begin with the system. prefix. (Reserved for internal use.)
In the mongo shell, use db.getCollection() to specify collection names that might
interact with the shell or are not valid JavaScript.
Limit the Number of Documents in the Result Set:-
a. To increase performance, you can constrain the size of the result by limiting the amount
of data your application must receive over the network. To specify the maximum
number of documents in the result set, call the limit() method on a cursor.
a. Each index requires at least 8KB of data space. Adding an index has some negative
performance impact for write operations. For collections with high write-to-read ratio,
indexes are expensive since each insert must also update any indexes.
b. Collections with high read-to-write ratio often benefit from additional indexes. Indexes
do not affect un-indexed read operations.
c. When active, each index consumes disk space and memory. This usage can be significant
and should be tracked for capacity planning, especially for concerns over working set
size.
d. In general, the performance gains that indexes provide for read operations are worth
the insertion penalty. However, in order to optimize write performance when possible,
be careful when creating new indexes and evaluate the existing indexes to ensure that
your queries actually use these indexes.
Atomicity:-
a. In Mongo DB, operations are atomic at the document level. No single write operation
can change more than one document. Operations that modify more than a single
document in a collection still operate on one document at a time. Ensure that your
application stores all fields with atomic dependency requirements in the same
document. If the application can tolerate non-atomic updates for two pieces of data,
you can store these data in separate documents. A data model that embeds related data
in a single document facilitates these kinds of atomic operations. For data models that
store references between related pieces of data, the application must issue separate
read and write operations to retrieve and modify these related pieces of data.
Document Limitations:-
a. The maximum BSON document size is 16 megabytes. The maximum document size
helps ensure that a single document cannot use excessive amount of RAM or, during
transmission, excessive amount of bandwidth.
1) The field name _id is reserved for use as a primary key; its value must be unique
in the collection, is immutable, and may be of any type other than an array.
2) The field names cannot start with the $ character.
3) The field names cannot contain the. Character.
c. Mongo DB does not make guarantees regarding the order of fields in a BSON document.
Drivers and Mongo DB will reorder the fields of a documents upon insertion and
following updates.
The following are common options for storing values for _id:-
a. Use an ObjectId.
b. Use a natural unique identifier, if available. This saves space and avoids an additional
index.
c. Generate an auto-incrementing number. See Create an Auto-Incrementing Sequence
Field.
d. Generate a UUID in your application code. For a more efficient storage of the UUID
values in the collection and in the _id index, store the UUID as a value of the
BSON BinData type.
a. Index keys that are of the BinData type are more efficiently stored in the index
if:
1) The binary subtype value is in the range of 0-7 or 128-135, and
2) The length of the byte array is: 0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 20,
24, or 32.
Yes. When you use remove (), the object will no longer exist in Mongo DB’s on-disk data
storage.
If you see a very large number connection and re-connection messages in your Mongo DB
log, then clients are frequently connecting and disconnecting to the Mongo DB server. This is
normal behavior for applications that do not use request pooling, such as CGI. Consider using
FastCGI, an Apache Module, or some other kind of persistent application server to decrease
the connection overhead.
Why are Mongo DB’s data files so large?
Mongo DB aggressively preallocates data files to reserve space and avoid file system
fragmentation. You can use the smallfiles setting to modify the file preallocation strategy.
Consider the following suggestions and strategies for optimizing storage utilization for
these collections:-
To optimize storage use, users can specify a value for the _id field explicitly when inserting
documents into the collection. This strategy allows applications to store a value in
the _id field that would have occupied space in another portion of the document.
Mongo DB stores all field names in every document. For most documents, this represents a
small fraction of the space used by a document; however, for small documents the field
names may represent a proportionally large amount of space.
o Embed documents.
In some cases you may want to embed documents in other documents and save on the per-
document overhead.
How does Mongo DB address SQL or Query injection?
BSON. As a client program assembles a query in Mongo DB, it builds a BSON object, not
a string. Thus traditional SQL injection attacks are not a problem.
Mongo DB implements a readers-writer lock. This means that at any one time, only one
client may be writing or any number of clients may be reading, but that reading and
writing cannot occur simultaneously.
Collection names can be any UTF-8 string with the following exceptions:-