This talk centers around the responsibilities of anyone administering MongoDB: security, server status, replication, and backups are all covered in detail. We'll describe how to integrate with monitoring services, discuss the output of various important diagnostic command, provide hardware recommendations, and hint at a few tricky issues surrounding backups.
by Richard Kreuter
We all know that MongoDB is one of the most flexible and feature-rich databases available. In this session we'll discuss how you can leverage this feature set and maintain high performance with your project's massive data sets and high loads. We'll cover how indexes can be designed to optimize the performance of MongoDB. We'll also discuss tips for diagnosing and fixing performance issues should they arise.
This session will demonstrate how to build a simple location-based application with geospatial indexing, map/reduce and other interesting MongoDB features.
This talk will discuss the ongoing evolution of data storage at Craigslist, starting from a homogeneous one-size fits all "MySQL everywhere" approach and moving toward a heterogeneous environment that considers our real data and performance needs and the plethora of tools available today. I'll discuss how and why we chose MongoDB to be part of our future infrastructure and highlight what has gone well - and not so well - in our multi-billion document deployment. This will include a discussion of some new 1.6.x features, including replica sets and auto-sharding.
For applications that outgrow the resources of a single database server, MongoDB can convert to a sharded cluster, automatically managing failover and balancing of nodes, with few or no changes to the original application code. This talk starts by discussing when to shard and continues on to describe MongoDB's sharding architecture. We'll describe how to configure a shard cluster and provide several example topologies. We'll also give some advice on schema design for sharding and how to pick the best shard key.
One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don't always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense. Understandably, this begets good questions: Are foreign keys permissible, or is it better to represent one-to-many relations withing a single document? Are join tables necessary, or is there another technique for building out many-to-many relationships? What level of denormalization is appropriate? How do my data modeling decisions affect the efficiency of updates and queries? In this session, we'll answer these questions and more, provide a number of data modeling rules of thumb, and discuss the tradeoffs of various data modeling strategies.
by Kenny Gorman
Shutterfly is an Internet-based social expression and personal publishing service. MongoDB is used for various persistent data storage requirements within Shutterfly. MongoDB helps Shutterfly build an unrivaled service that enables deeper, more personal relationships between customers and those who matter most in their lives.
3rd December 2010