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.
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.
When choosing a database, caring is only one aspect of it. It's necessary, but not sufficient.
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.
>The team at MongoDB really cares a lot about making the best database product possible.
... some what ironic.
[0]: https://docs.mongodb.com/manual/tutorial/resync-replica-set-...
> 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.
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.