title: MongoDB - single huge collection of raw data. Split or not?
body: <p>We collect and store instrumentation data from a large number of hosts. 
  Our storage is MongoDB - several shards with replicas. Everything is stored in a single large collection.
  Each document we insert is a time based observation with some attributes (measurements). The time stamp is the most important attribute because all queries are based on time at least. Documents are never updated, so it's a pure write-in-look-up model. Right now it works reasonably well with several billions of docs.</p>
  
  <p>Now,</p>
  
  <p>We want to grow a bit and hold up to 12 month of data which may amount to a scary trillion+ observations (documents).
  I was wandering if dumping everything into a single monstrous collection is the best choice or there is a more intelligent way to go about it.
  By more intelligent I mean - use less hardware while still providing fast inserts and (importantly) fast queries.
  So I thought about splitting the large collection into smaller pieces hoping to gain memory on indexes, insertion and query speed.</p>
  
  <p>I looked into shards, but sharding by the time stamp sounds like a bad idea because all writes will go into one node canceling the benefits of sharding.
  The insert rates are pretty high, so we need sharding to work properly here.
  I also thought about creating a new collection every month and then pick up a relevant collection for a user query.
  Collections older than 12 month will be either dropped or archived.
  There is also an option to create entirely new database every month and do similar rotation.
  Other options? Or perhaps one large collection is <strong>THE</strong> option to grow real big?</p>
  
  <p>Please share your experience and considerations in similar apps.</p>