1) MongoDB provide ACID in following ways:
• Atomicity - MongoDB provides only a document-wide transaction: Writes are never partially applied to an inserted or updated document. The operation is atomic in the sense that it either fails or succeeds, for the document in its entirety.
• Consistency – Consistency is achieved by replica set.
• Isolation – DB level locking from version 2.2 onwards
• Durability – JournalCommitInterval configuration options.
2) You need to model the data correctly to achieve the atomic operation. Example
3) Even if in future if there is requirement for having atomicity between multiple collections that can be achieve via two phase commit.
4) Ideally all atomic MongoDB operation should be performed from application layer or by scripting.
JOINs:
1) 1. JOIN’s requirement can be met in following ways in MongoDB:
- DBRefs - Referencing one document to other via _ids.
- Embedding - Putting the data into single document. .
2) When to Embed and when to use DBRefs:
- If the document is huge and is refereed in many document then it is prefer to use DBRef. Doing so if document needs updating it is done once rather than many times. Also it saves the disk space and performance is better as lesser I/O ( Due to document caching).
- But if there is one-one relationship and is not refereed to other document then it is always better to embed, irrespective to size of document. If updates are zero and relationship graph is small then also it is advisable to embed the document.
- Again it depends on the user requirement also whether there is lazy loading required, whether data is write once and read many times, read/write ratio, atomic data requirement, ACID requirement and many other factors which I leave to user to decide.
Database level locking:
For ACID locking is much more important then any other aspect. Previous version of MongoDB there was global read/write lock which is slow in performance but now from new release 2.2 things had improved to great extent and hope future release will also add more value.
1) From MongoDB version 2.2 there are the improvements in locking:
- Elimination of the global reader/writer lock.
- Locking at database level.
- PageFaultException architecture – yield lock on page fault.
2) PageFaultException architecture improves concurrency within a single collection,which meets most of normal requirements.
3) DB performance depends on the read/write ratio, so it is recommended to do benchmark before taking any decision.
4) In future MonogoDB is going to have document level locking (latching).
File Sizes :
File size matters a lot from maintenance and from performance perspective.
Please refer the MongoDB documentation for in depth details.
1) Each BSON document has 16 MB limit in MongoDB, if your document span across 16 MB then you need to use GridFS.
2) Following are the various options to shrink the file if required:
- db.repairDatabase().
- Compacting particular document: db.runCommand({ compact : 'User' });
3) Test of file size:
- No of collection:2
- No of Documents:
- Collection 1: 216147
- Collection 2: 245712
- Total No of Keys in each collection: 30
- Data type used: integer, date, string, double.
- Average length of each key : 10 characters.
- Total physical file size for that db: 256 MB (268,435,456 bytes) on Windows platform.
Security:
1) MongoDB needs to be deployed in trusted environment.
2) MongoDB provides basic support for authentication with the auth setting, which is disable by default.
3) MongoDB can have control access in trusted environment.
4) In production MongoDB will not be installed in an environment which should not be directly accessible via web.
When to use Mongo Db :
1) When your data is not much normalized.
2) When you want to store unstructured data.
3) When you want data flexibility.
4) When you are not much concern about the ACID properties, ideal case most reads operations.
5) If you want to dump data dynamically without even thinking of the schema, ideal case dump as it is form.
6) There is no need of complex transactions.
7) If you want to achieve high scalability, but considering the above aspects.
8) If your requirement is to support high volume traffic.
It is always advisable to do performance/benchmark testing to meet your requirement.
When to use Mongo Db :
1) When your data is not much normalized.
2) When you want to store unstructured data.
3) When you want data flexibility.
4) When you are not much concern about the ACID properties, ideal case most reads operations.
5) If you want to dump data dynamically without even thinking of the schema, ideal case dump as it is form.
6) There is no need of complex transactions.
7) If you want to achieve high scalability, but considering the above aspects.
8) If your requirement is to support high volume traffic.
It is always advisable to do performance/benchmark testing to meet your requirement.
