As long as it all the data for all metrics fits in RAM, it will work great in MongoDB. Of course, as soon as it doesn't, you're totally hosed.
To expand on the parent, a column store like HBase or Cassandra is perfect as each row can represent a timeslice and then each column can represent a single event or record within that timeslice. As the row gets evicted from it's initial storage in memory, it will be written to disk contiguously, in sorted order, and batch reads of this data is sequential.
It is possible to use MongoDB to store a timeslice as a document, but it is not designed to scale out to store very large numbers of columns within a single document.
happily, this is not a synchronous application with tens of thousands of concurrent users, so "totally hosed" for us may have a very different definition.
What do you mean by "very large numbers of columns" ? I've seen some mongo users with very rich, i.e. large, document models.
1,000s, 10,000s, 100,000s, millions. MongoDB columns are designed for serialization of rich documents, not store unbounded ranges of data values.
Even without tens of thousands of concurrent users, you'll eventually run into a deeply critical performance wall when MongoDB starts reading from disk. It's really best to think of it as an in-memory database.
Comments
As long as it all the data for all metrics fits in RAM, it will work great in MongoDB. Of course, as soon as it doesn't, you're totally hosed.
To expand on the parent, a column store like HBase or Cassandra is perfect as each row can represent a timeslice and then each column can represent a single event or record within that timeslice. As the row gets evicted from it's initial storage in memory, it will be written to disk contiguously, in sorted order, and batch reads of this data is sequential.
It is possible to use MongoDB to store a timeslice as a document, but it is not designed to scale out to store very large numbers of columns within a single document.
MongoDB needs indexes to fit in memory, not the entire dataset. This is an important distinction.
happily, this is not a synchronous application with tens of thousands of concurrent users, so "totally hosed" for us may have a very different definition.
What do you mean by "very large numbers of columns" ? I've seen some mongo users with very rich, i.e. large, document models.
1,000s, 10,000s, 100,000s, millions. MongoDB columns are designed for serialization of rich documents, not store unbounded ranges of data values.
Even without tens of thousands of concurrent users, you'll eventually run into a deeply critical performance wall when MongoDB starts reading from disk. It's really best to think of it as an in-memory database.