MongoDB Developers Best Practices12.pptx

mongo

1. MongoDB Developers Best Practices Ramesh S

2. General NoSQL Best Practices Test Exhaustively Don’t assume that what worked for your RDBMS will translate Think about the consistency and durability needs of your data Understand what to expect from EBS volumes

3. Test Exhaustively Test within the context of your application and against traffic patterns that are representative of your production system. A test environment that does not resemble your production traffic will block you from discovering performance bottlenecks and architectural design flaws. Examine your queries closely and always collect metrics.

4. Don’t assume that what worked for your RDBMS will translate Whatever worked on your SQL database may not work on MongoDB so make sure that your expectations are realistic and aligned with the features of the database. For better performance, design your documents and queries according to what MongoDB recommends. Understand that your application might need to be re-architected in order to migrate to a non-relational data store. Read The cost of Migration for more information on migrating to NoSQL.

5. Think about the consistency and durability needs of your data Think about your durability and consistency needs. We cannot emphasize this enough. During your research you will find that MongoDB offers durability through replication. It is never recommended to run a standalone MongoDB for production use, make sure you understand why

6. Understand what to expect from EBS volumes If you are an Engine Yard Cloud customer (AWS EC2), you should know that the performance of Amazon’s Elastic Block Storage (EBS) can be inconsistent. Collect throughput metrics over time when benchmarking your application and plot your data. Engine Yard Managed customers do not have this limitation.

7. MongoDB Best Practices

8. Always use Replica Sets Keep up with current versions Don’t run MongoDB on 32-bit systems Turn journaling on by default Mind the location of your data files Your working set should fit in memory Scale up if your metrics show heavy use Be careful when sharding Keep up with MongoDB resources

9. Always use replica sets Replica sets provide high availability through automatic failover. If your primary node fails, a secondary node will be elected as primary and your cluster will remain functional.

10. Keep up with current versions Please keep your version of MongoDB current version. MongoDB rolls out numerous fixes within each release that help your cluster run smoother. Version 4.0.x includes significant performance and concurrency improvements, index changes, bug fixes, a compaction command, and it even makes it easier to upsize your cluster. If you are still using 3.x please be sure to upgrade as soon as possible.

11. Don’t run MongoDB on 32-bit systems MongoDB has a ~2.5GB data limit on 32-bit systems. Its storage engine uses memory-mapped files for performance and they are tied to the available memory addressing.

12. Turn journaling on by default MongoDB supports write-ahead journaling of operations to facilitate crash recovery and node durability.

13. Mind the location of your data files Check your recipes to make sure that your MongoDB data files exist in a persistent volume (example: /data/mongodb). Using ephemeral drives is possible, but you should be extremely careful when deciding to do so, as it will influence your cluster architecture.

14. Your working set should fit in memory Being able to keep the working set (and indexes) in memory is an important factor in overall cluster performance. If you notice the number of page faults increasing, there is a very high chance that your working set is larger than your available RAM. You have two options when your data exceeds your available RAM: increasing the size of your MongoDB instance or sharding.

15. Scale up if your metrics show heavy use If your instance shows a load over 65%, you should consider scaling up. Your load should be consistently below this threshold during normal operations. This also impacts recovery and vertical scaling scenarios

16. C areful when sharding Sharded installations require careful understanding of your application’s data access patterns. Please take the time to understand how MongoDB sharding works and if you really need it. Also remember that selecting a good sharding key is important as it will affect your performance. Config servers are critical to the health of your cluster. You MUST have 3 configuration servers in a sharded production environment. NEVER delete their data, always make sure you back them up frequently, and refer to them, if you can, by name using an /etc/hosts file (this will make your cluster more resilient).

17. Keep up with MongoDB resources Keep informed as things change rapidly MongoDB resources: Documentation: https://docs.mongodb.com/ Google Group: http://groups.google.com/group/mongodb-user Bugs: https://jira.mongodb.org Blog: http://blog.mongodb.org/