6 ms·

MongoDB receives a fair amount of criticism here but the company is a fantastic place to work. I'm proud that I was able to learn and grow as a developer alongs

by tbrock 10y ago

MongoDB receives a fair amount of criticism here but the company is a fantastic place to work. I'm proud that I was able to learn and grow as a developer alongside all of those who have been trying (and succeeding) to make a great database. The team at MongoDB really cares a lot about making the best database product possible. I knew it when I was there and still think so after I've left.

tyre 10y ago
When building a company, I care more about culture than anything else. It's the people that make the company great. When choosing a database, caring is only one aspect of it. It's necessary, but not sufficient.
diziet 10y ago
MongoDB as a product evolved tremendously in the last few years. All the improvements introduced with WiredTiger and other major releases have seriously improved the performance and reliability of the product. It's not a perfect solution, but the majority of criticism is something that was written about version 1.8.
bogomipz 10y ago
>"MongoDB receives a fair amount of criticism here but the company is a fantastic place to work" None of the criticisms I have ever seen or heard about MongoDB were related to Mongo Inc and their office culture but rather their product.
- omginternets 10y ago
  Exactly, which makes ... >The team at MongoDB really cares a lot about making the best database product possible. ... some what ironic.
  - bogomipz 10y ago
    Right I would hope that that would be implicit :)
- edgan 10y ago
  Actually, having been through their training, and dealt with their consultants. Their company culture is the problem. They had a pure-developer centric mindset, and no operations mindset. So at the time they had no good way to do backups. Their more modern solution is backups that they manage for you, which is even more crazy.
  - Fiahil 10y ago
    Yes. Mongo is an operational nightmare. I mean, who in their right mind would use a product where the recommended solution[0] to resync a stale replica (which happen all the time after a long netsplit) is to "perform an initial sync". Which, of course, mean "please remove everything and type this command". Crazy. [0]: https://docs.mongodb.com/manual/tutorial/resync-replica-set-member/ https://docs.mongodb.com/manual/tutorial/resync-replica-set-...
    - bogomipz 10y ago
      Indeed, and the only practical means of performing a compaction is to "rm -rf" the data directory and let it resync from another replica set member. This is not documented of course.
      - Fiahil 10y ago
        This is documented (okay, a little "hidden")! It's written black on white in their documentation (see the link above): > A replica set member becomes “stale” when its replication process falls so far behind that the primary overwrites oplog entries the member has not yet replicated. The member cannot catch up and becomes “stale.” When this occurs, you must completely resynchronize the member by removing its data and performing an initial sync. > MongoDB provides two options for performing an initial sync: > Restart the mongod with an empty data directory and let MongoDB’s normal initial syncing feature restore the data > Restart the machine with a copy of a recent data directory from another member in the replica set. Note: the second option is not a real option when you're dealing with a 700GB database. By the time you finish the copy the oplog will be too big anyway. Thus, making all these steps completely pointless. And that's why it's so bad. They even acknowledge the "correct" solution is to rm your data and resync.
joering2 10y ago
I really wanted to make it work! But out of the box on Centos distribution it doesn't. Its open to anyone by default, eats all memory and then crashes! I had it on and off my machine in less than one week and won't plan to go back.
bborud 10y ago
Too bad that care didn't make it into the product.

by tbrock 10y ago

tyre 10y ago

When building a company, I care more about culture than anything else. It's the people that make the company great. When choosing a database, caring is only one aspect of it. It's necessary, but not sufficient.

diziet 10y ago

MongoDB as a product evolved tremendously in the last few years. All the improvements introduced with WiredTiger and other major releases have seriously improved the performance and reliability of the product. It's not a perfect solution, but the majority of criticism is something that was written about version 1.8.

bogomipz 10y ago

>"MongoDB receives a fair amount of criticism here but the company is a fantastic place to work" None of the criticisms I have ever seen or heard about MongoDB were related to Mongo Inc and their office culture but rather their product.

omginternets 10y ago
Exactly, which makes ... >The team at MongoDB really cares a lot about making the best database product possible. ... some what ironic.
- bogomipz 10y ago
  Right I would hope that that would be implicit :)
edgan 10y ago
Actually, having been through their training, and dealt with their consultants. Their company culture is the problem. They had a pure-developer centric mindset, and no operations mindset. So at the time they had no good way to do backups. Their more modern solution is backups that they manage for you, which is even more crazy.
- Fiahil 10y ago
  Yes. Mongo is an operational nightmare. I mean, who in their right mind would use a product where the recommended solution[0] to resync a stale replica (which happen all the time after a long netsplit) is to "perform an initial sync". Which, of course, mean "please remove everything and type this command". Crazy. [0]: https://docs.mongodb.com/manual/tutorial/resync-replica-set-member/ https://docs.mongodb.com/manual/tutorial/resync-replica-set-...
  - bogomipz 10y ago
    Indeed, and the only practical means of performing a compaction is to "rm -rf" the data directory and let it resync from another replica set member. This is not documented of course.
    - Fiahil 10y ago
      This is documented (okay, a little "hidden")! It's written black on white in their documentation (see the link above): > A replica set member becomes “stale” when its replication process falls so far behind that the primary overwrites oplog entries the member has not yet replicated. The member cannot catch up and becomes “stale.” When this occurs, you must completely resynchronize the member by removing its data and performing an initial sync. > MongoDB provides two options for performing an initial sync: > Restart the mongod with an empty data directory and let MongoDB’s normal initial syncing feature restore the data > Restart the machine with a copy of a recent data directory from another member in the replica set. Note: the second option is not a real option when you're dealing with a 700GB database. By the time you finish the copy the oplog will be too big anyway. Thus, making all these steps completely pointless. And that's why it's so bad. They even acknowledge the "correct" solution is to rm your data and resync.

joering2 10y ago

I really wanted to make it work! But out of the box on Centos distribution it doesn't. Its open to anyone by default, eats all memory and then crashes! I had it on and off my machine in less than one week and won't plan to go back.

bborud 10y ago

Too bad that care didn't make it into the product.