MongoDB History
quickprogrammingtips.com
quickprogrammingtips.com
> People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested. For example, they’d write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market.
> almost everyone was asking “how is RethinkDB different from MongoDB?” We worked hard to explain why correctness, simplicity, and consistency are important, but ultimately these weren’t the metrics of goodness that mattered to most users.
> But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well.
In my mind Mongo is a database that had great developer experience, excellent marketing, and some seriously bad technical gotchas. But marketing drove momentum long enough to cover bills, grab the market, and address most of the gotchas, so now it's a decent DB.
[0]: https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...
[0] https://en.wikipedia.org/wiki/Keith_Bostic
Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers a neat way of using the power of distributed CosmosDB without sacrificing cloud portability.
Those differences may be fine for some use cases, but definitely compromise portability if you want to run or test the same application with a database deployment on GCP, AWS, or your own infrastructure. The lowest common denominator is based on Cosmos DB's underlying limits and features (not a MongoDB server feature set): https://docs.microsoft.com/en-us/azure/cosmos-db/concepts-li....
"relation dbs have impotence mismatch"
"does /dev/null support sharding"
"redis will kick memcache's ass"
Oracle on their website right now says "we lead the market in autonomous, cloud, and applications technologies".
I assume you think developers are going to suddenly abandon AWS, Python etc and move entirely to an Oracle stack based off this quote ?
at my firm we're being all but forced to use Azure even though it costs more and makes absolutely no sense whatsoever for the domain, but since it's the "technology strategy" fighting it becomes exceptionally difficult
I proved that a regular database would be orders of magnitude faster with a real example on real data and while the project/product was canceled for marketing/sales reasons. Until it was canceled we were told by multiple levels of "technical" managers to use the worse database because of unknown reasons.
I've built systems with it where we didn't own the schema - we were scraping data from other places and schemaless was a feature. And I benchmarked it against Postgres and a couple other things and I just couldn't get the same performance - note our operations were idempotent to the db, so even in a hard crash, we could just re-run the scraping job and we wouldn't really "lose" any data -- or even if the data was stale by a day, not a big deal... That system would do tens of millions of upserts per night on not crazy AWS hardware and it ran for years like this without problems.
Would I use mongo for situations where I needed transactions? Almost never - I actually like Postgres a lot and it's my default for your run of the mill CRUD apps since you can do geo, crypto, search, etc by just installing a few extensions. Do I got on HN on every mongo article and bash them constantly? No, I think they've built a pretty decent thing if you understand the implications of not confirming writes to replicas and whatnot and tune it to your needs.
It turns out it takes a decade to build a new database that’s half decent and has all the features people want. It’s really hard! Ask anyone that’s tried. The path is littered with skeletons.
Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes.
Imagining a timeline where people would say that about MongoDB is a good way to assess the project's quality...
And that's just a publicly available example. I have a client who paid for a MongoDB Inc. to send an "expert" down to assess the viability of a project, who flat out said the project can't be done and left it there; a week later the official MongoDB Inc. report says "We can definitely get it done. Why don't you move to our managed MongoDB Atlas service? That'll be $10K." For the record, my professional assessment was also that it'd be impossible to do it on a data model like Mongo's.
----
> Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes.
1. The snark isn't helping your cause.
2. Then there are databases that claim to be "perfect" from the start, having always put up a facade without every admitting any of their own flaws. Like MongoDB.
The thing MongoDB does best — though not something a DBMS can be judged by — is marketing. Not just the marketing they push themselves — "MongoDB is web scale!", "90% of RDBMS use can be replaced by MongoDB!" — but also the marketing it can get its fans to push.
Also Mongo wins by a large margin on "how little you need to know to get started" with any relational db.
The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.
Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc.
Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and validates) your data rather than keeping spread out in your application code.
It's next to useless for ensuring data integrity and why every app you see will have data validation inside the code itself. Whether it's checking that an email has a valid structure or that a payment is not negative.
Majority of the logic will be the code so it makes no sense to me other than if you have multiple clients accessing that database why it must be enforced at the database level as well.
To be fair depending on the culture of the company it maybe easier to put in code and update it there than to wait to have it approved, discussed and scheduled by the DBA
That doesn't mean that treating your database as a dumb datastore and having the "smarts" in the application layer doesn't work better for some applications. Both ways have trade-offs.
Business logic validation is a separate layer but still requires proper types and data integrity underneath, and that's where strong schemas in the database help. More so when you have multiple apps interacting with the same database.
I can understand broadly that RDBMS is better when you have joins and foreign key constraints and nosql is cheaper “web” scale plus there are ACID considerations yet without domain knowledge it’s plausible nosql is better
Also everything can scale, and it's all using the same fundamental primitives (sharding, etc) to do so anyway. Some just make it easier with built-in functionality vs external layers.
This is not to say that non-relational systems aren't useful, but that they are rarely used correctly instead of chosen for marketing hype, and hearing things like "adding a column is easier" from an architect usually points to the later situation.
I'm a dyed-in-the-wool RDBMS user but I can see the value of this feature. The trade-off, of course, is that your application has to handle varying schema levels. MongoDB also won't protect you against typos, inconsistent types, and other foolishness. I would not judge people who choose to make this trade--it's a sensible one for many use cases.
Many analytic databases are headed in this direction due to the amount of data that arrives in the form of nested JSON structures. I can't speak for other DBMS types but it's something we're very interested in for ClickHouse.
Encoding your business logic in the database schema is rarely a good idea.
If by this you mean not defining tables with explicit columns in general I would disagree. It's one of the most effective ways to get speed in analytic applications because it optimizes compression. And in OLTP applications it's the best way to ensure consistency of data.
But perhaps you were referring to a narrower scope like just JSON & upstream changes?
Compressed storage size for uniform datatypes can be phenomenally efficient. I've seen 10,000x size reduction in ideal cases like monotonically varying integers stored using double delta codec + ZSTD compression.
Storing a record with strong typing does not get in the way of business, and in fact it often helps by maintaining data consistency and integrity.
I agree that more complex row formats are needed though. Bigquery has done well with nested/repeating structures and Snowflake uses the PAX data format for JSON which has been very useful (however their JSON/VARIANT column doesn't support structured types).
Still, it's hard to beat MongoDB in this respect. In my first app I was amazed that I could just insert a BSON object and MongoDB created a queryable table automatically. You pay for it of course in other ways but the ease of use is quite extraordinary.
Don't know what they use now or if they still use it.
This is the tip of the iceberg when it comes to MongoDB's use cases in Financial services. These organisations REALLY use MongoDB for financial data and they are all public references. Relational databases are great for financial data and so is MongoDB.
But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.
You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly
Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.
In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library.
And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with that sort of behaviour either.
"code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice.
> And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent
Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.
For reference: https://docs.mongodb.com/manual/reference/operator/query/jso...
Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup.
These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.
What applications are much better in your opinion?
If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.
If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
The latest stats in the same case scenario (already-read posts) Zhihu is:
- 2.6 Trillion Rows
- 560TB data
- 200 TiKV instances
If you're working at that scale, it sounds like that's more of an OLAP use-case where MemSQL and other column-oriented databases would suit better than an OLTP document-store. Maybe you can share more details for better recommendations.
Sure MongoDB has some extra ergonomics for dealing with JSON/BSON data, but how much benefit this really adds is still up for debate. As horizontal scalability becomes more natively supported, MongoDB will lose even more of its benefits.
So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.