Earlier quoted context omitted.
“Extreme consolidation” - wait till us-East-1 goes down
Friends don’t let friends run on us-east-1. Consolidate on us-west-1 or us-west-2 instead.
us-west-1 wouldn’t be my first choice either for
MongoDB security notice
171–180 of 198 posts
Re: MongoDB security notice
#172I never used/tried MongoDB, what are the reasons people choose MongoDB over other DBs?
- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. - Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries. - Little to…
So basically nothing Django and a postures db can't do.
Re: MongoDB security notice
#173Earlier quoted context omitted.
Asked 11 years ago and still going strong... "To what extent are 'lost data' criticisms still valid of MongoDB?" - https://stackoverflow.com/questions/10560834/to-what-extent-...
Isn’t mongodb data losses commonly referred related to their use of fsync()? From what I vaguely remember they call fsync() every 100ms or so and just assume everything went fine, resulting in potential data loss.
No. The default write concern as of version 5 is "majority" which "Requests acknowledgment that write operations have been durably committed to the calculated majority of the data-bearing voting members" (as long as writeConcernMajorityJournalDefault is true which is the default).
So fsync is called on every write.
Re: MongoDB security notice
#174Earlier quoted context omitted.
Mongo is never the right choice. Postgres is nearly always the right choice, however.
Legitimate question, please don't downvote. Are you basing this opinion on: - popular HN opinion - issues that Mongo experienced in its infancy - mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems Or are you basing it on extensive experience with wide range of use cases?
I'm of a similar opinion. I experienced all the issues of MongoDB's infancy; it wasn't a good time, but the mmap functionality seemed worth it at the time if you had enough memory or constrained your access patterns appropriately.
Nowadays, PostgreSQL has JSON/JSONB types, a full suite of extensions like pgvector and PostGIS, and I can scale with Citus or use it in any of the big managed clouds.
From a functionality perspective, MS SQL Server makes a more compelling alternative to me simply by way of its native graph database support.
Re: MongoDB security notice
#175Earlier quoted context omitted.
Asked 11 years ago and still going strong... "To what extent are 'lost data' criticisms still valid of MongoDB?" - https://stackoverflow.com/questions/10560834/to-what-extent-...
Isn’t mongodb data losses commonly referred related to their use of fsync()? From what I vaguely remember they call fsync() every 100ms or so and just assume everything went fine, resulting in potential data loss.
It all depends on your writeConcern setting. This option is super critical to understand when deploying an MongoDb. Older versions had defaults that were more optimized for availability than consistency.
Even so, not flushing each write is not as bad as it sounds, if you have a 3-node replicaset and your w-parameter is set to majority (default), it means at least 2 servers have the write in memory. It would take both of them crashing at the same time for the unflushed write to be lost.
The idea is that MongoDB allows you to choose which corner of the CAP triangle you want, if you chose AP, that’s your decision. The defaults can of course be argued and I believe it’s been gradually moving over to more and more C for each version. Nowadays the journal does get flushed as next comment described.
Re: MongoDB security notice
#176Re: MongoDB security notice
#177Earlier quoted context omitted.
I’ll ask again, what’s a good use case over Postgres jsonb.
All you do is poop all over the story about postgres. I'm convinced that no use cases will convince you of anything. I'm not really looking to involve myself in a database holy war.
Is jsonb in Postgres not flexible enough? I dump external json in there all the time (like large API responses). The jsonb operators work well. And there's an escape hatch that lets you easily convert json to a table. And importantly, you get indexes with Postgres.
Re: MongoDB security notice
#178Earlier quoted context omitted.
Mongo is never the right choice. Postgres is nearly always the right choice, however.
Legitimate question, please don't downvote. Are you basing this opinion on: - popular HN opinion - issues that Mongo experienced in its infancy - mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems Or are you basing it on extensive experience with wide range of use cases?
Mostly that Postgres is amazing, runs anywhere and supports jsonb (which I use a lot). And I don't want to worry too much about mis-modeling; that's the entire point of a relational database with a type system.
Plus all the Mongo horror stories from people who I know and hold in high esteem. And recently talking to a data person explaining what a pita getting data out of their Mongo monstrosity into a format adequate for analysis.
Re: MongoDB security notice
#179Earlier quoted context omitted.
People use MongoDB because it’s easy to get started. It does “db stuff” and “authentication”. I’ve given up trying to fight the trend. I just recognize immediately when it is used early on that the devs are still operating with training wheels on.
Sometimes this is the case but not always... It's nice to just work with objects in some languages... for some projects. That's engineering - picking trade offs :)
Except you can have objects in Postgres via jsonb; there's no trade off and you're both future and vendor proofed.
Re: MongoDB security notice
#180I never used/tried MongoDB, what are the reasons people choose MongoDB over other DBs?
We use MongoDB in conjunction with RealmDB to build an offline first mobile app. For this specifically it works very well. You basically define which parts of your document collection should be synced to which device, for example based on a query that contains the user id.
MongoDB takes care of syncing the right data to the right device when internet connection is available. On the device, the data is stored locally in RealmDB, which represents the other side of the sync.
This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.