9 ms·

Is there anybody here who has run MongoDB at moderate scale with good results? As in a few terabytes of data, >10k ops/second territory. I've been really disa

Is there anybody here who has run MongoDB at moderate scale with good results? As in a few terabytes of data, >10k ops/second territory. I've been really disappointed with its reliability and performance in situations where I've been around that.

Ixiaus 12y ago
I came into a company that was attempting to use MongoDB for their soft-real time time-series data (I would consider it between low and medium scale) and it was atrocious, in too many ways. It doesn't scale without tremendous effort and implicit schemas are a very dangerous thing to introduce into your application, they're insidious, and require enormous diligence in the application to codify the schemas (I would only feel comfortable using a loose document store with something like Haskell in which I can model the schema with strong types). I've encountered MongoDB in three different companies / products and expended much effort to immediately move away from it in every case. In each case, the solution (which has been different each time) was far more appropriate to what was needed. There's a sad inclination by developers to pick "one ring to rule them all" tools and MongoDB I believe even sells itself that way. It is not.
- ak217 12y ago
  What were the more appropriate solutions?
  - Ixiaus 12y ago
    Postgres for structured data, Riak for high-volume and flatter data, and TempoDB for high-volume time-series data.
dkhenry 12y ago
Yes. When implemented correctly Mongo can scale very well.
quackerhacker 12y ago
I've been using mongo on 39M+ records (tracking financial tick data) across 73 assets (collections) and my queries take anywhere between 2-3mins depending on complexity. You can always run db.currentOp() in the mongo shell to see what process is taking forever as well. Let me clarify why though, there methods of optimizing a query by adding another field, but since I have to traverse my records with the sort() cursor my queries take that long.
- Thiz 12y ago
  Jesus Christ! I remember querying databases with 100 tables and millions of records in foxpro a century ago and it took less than a second. What has happened to the world while I was in cryogenic state? Take me back to the nitrogen pool!
- kyberias 12y ago
  I don't get this. If any relational database choked with that small number of rows, it would be thrown away immediately. That's a couple of orders of magnitude too slow.
nasalgoat 12y ago
I did, for nearly three years. MongoDB was consistently the number one reason for site downtime.
misiti3780 12y ago
i think foursquare is, unless they have migrated off and did not publicized it
kstirman 12y ago
High scale public references and links to their presentations are maintained here: http://www.mongodb.com/mongodb-scale http://www.mongodb.com/mongodb-scale I think scaling any system takes careful planning. IMHO, this is an area where MongoDB has improved a lot in the past two years, especially with 3.0, but there is still a lot of work to do.

Ixiaus 12y ago

I came into a company that was attempting to use MongoDB for their soft-real time time-series data (I would consider it between low and medium scale) and it was atrocious, in too many ways. It doesn't scale without tremendous effort and implicit schemas are a very dangerous thing to introduce into your application, they're insidious, and require enormous diligence in the application to codify the schemas (I would only feel comfortable using a loose document store with something like Haskell in which I can model the schema with strong types). I've encountered MongoDB in three different companies / products and expended much effort to immediately move away from it in every case. In each case, the solution (which has been different each time) was far more appropriate to what was needed. There's a sad inclination by developers to pick "one ring to rule them all" tools and MongoDB I believe even sells itself that way. It is not.

ak217 12y ago
What were the more appropriate solutions?
- Ixiaus 12y ago
  Postgres for structured data, Riak for high-volume and flatter data, and TempoDB for high-volume time-series data.

dkhenry 12y ago

Yes. When implemented correctly Mongo can scale very well.

quackerhacker 12y ago

I've been using mongo on 39M+ records (tracking financial tick data) across 73 assets (collections) and my queries take anywhere between 2-3mins depending on complexity. You can always run db.currentOp() in the mongo shell to see what process is taking forever as well. Let me clarify why though, there methods of optimizing a query by adding another field, but since I have to traverse my records with the sort() cursor my queries take that long.

Thiz 12y ago
Jesus Christ! I remember querying databases with 100 tables and millions of records in foxpro a century ago and it took less than a second. What has happened to the world while I was in cryogenic state? Take me back to the nitrogen pool!
kyberias 12y ago
I don't get this. If any relational database choked with that small number of rows, it would be thrown away immediately. That's a couple of orders of magnitude too slow.

nasalgoat 12y ago

I did, for nearly three years. MongoDB was consistently the number one reason for site downtime.

misiti3780 12y ago

i think foursquare is, unless they have migrated off and did not publicized it

kstirman 12y ago

High scale public references and links to their presentations are maintained here: http://www.mongodb.com/mongodb-scale http://www.mongodb.com/mongodb-scale I think scaling any system takes careful planning. IMHO, this is an area where MongoDB has improved a lot in the past two years, especially with 3.0, but there is still a lot of work to do.