Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB History

quickprogrammingtips.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: MongoDB History

#51

Post by stennie »

jaysonqpt wrote: post #49
chrisfosterelli wrote: post #18

MongoDB still has an awful reputation on Hacker News but I really appreciate the take from "Why RethinkDB Failed" [0]: > 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, w…

I think MongoDB 3.6 is when it became a "decent" DB. 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.

Cosmos' API is an emulation of MongoDB which differs in features, compatibility, and implementation from an actual MongoDB deployment. Cosmos' suggestion of API version support (eg 3.6) is referring to the MongoDB wire protocol rather than the full MongoDB server feature set for that version. There are also some inherent differences, such as Cosmos' Request Units (RUs) which need to be considered for capacity planning and costs: https://docs.microsoft.com/en-us/azure/cosmos-db/request-uni....

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....

Re: MongoDB History

#52

Post by madarco »

numlock86 wrote: post #10
tobyhede wrote: post #4

A complete history with all the data ... unlike MongoDB. Boom tish etc.

I never got a definite answer: What problem does MongoDB even try to solve?

I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier

Re: MongoDB History

#53

Post by jd_mongodb »

hodgesrm wrote: post #48
manigandham wrote: post #16

Earlier quoted context omitted.

Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. 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 valida…

Adding columns can be hard at scale. MongoDB allows you to add columns incrementally without stopping the world. You just add the value and it's materialized in the DBMS. The point is you don't have to manually define schema but instead the database works with the structure of the data. 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…

you can use JSON schema to lockdown you schemas like SQL but few developers choose do that as they prefer the flexibility that MongoDB offers. Changes in the schema are almost always due to upstream changes so the schema is a follower rather than a leader.

Encoding your business logic in the database schema is rarely a good idea.

Re: MongoDB History

#54

Post by jd_mongodb »

blibble wrote: post #45
threeseed wrote: post #17

Earlier quoted context omitted.

Anybody who makes complex technology decisions based on marketing copy doesn't deserve to be taken seriously either. Not that I think these people actually exist other than in the minds of many HN commenters. 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 a…

at large firms the clueless technology managment often buy based on the marketing crap, then force it down the throats of the engineers 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

In seven years working at MongoDB the one thing I have learned is technology is never "forced down the throat of the engineers". Developers have choices and would not stay in an organisation that made decisions that way. The reason developer relations exists is the acknowledgement that developers ARE the decision makers in most technology selection.

Re: MongoDB History

#55

Post by jd_mongodb »

xtracto wrote: post #39
conradfr wrote: post #13

Earlier quoted context omitted.

I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. 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.

Oh man. Payment provider data in mongo... even if by now MongoDB doesnt lose data... you REALLY want your ledger or OLTP to be in a relational, transactional database.

Coinbase uses MongoDB, Barclays uses MongoDB, BBVA uses MongoDB, Capital One uses MongoDB. Charles Schwab uses MongoDB. FICO uses MongoDB. Goldman Sachs uses MongoDB. HSBC uses MongoDB. Intuit uses MongoDB. Uk Inland Revenue uses MongoDB. UK Dept of Work and Pensions uses MongoDB.

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.

Re: MongoDB History

#56

Post by hodgesrm »

jd_mongodb wrote: post #53
hodgesrm wrote: post #48

Earlier quoted context omitted.

Adding columns can be hard at scale. MongoDB allows you to add columns incrementally without stopping the world. You just add the value and it's materialized in the DBMS. The point is you don't have to manually define schema but instead the database works with the structure of the data. 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…

you can use JSON schema to lockdown you schemas like SQL but few developers choose do that as they prefer the flexibility that MongoDB offers. Changes in the schema are almost always due to upstream changes so the schema is a follower rather than a leader. Encoding your business logic in the database schema is rarely a good idea.

> 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?

Re: MongoDB History

#57

Post by manigandham »

zaphirplane wrote: post #36
manigandham wrote: post #16

Earlier quoted context omitted.

Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. 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 valida…

The comparison here is DB schema + DB schema migration + shared data access layer vs shared data access layer With that I am not clear on what you think the problem is without domain knowledge. 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

"Web scale" isn't a real thing and I don't know what "shared data access layer" refers to but relational databases have decades of features and tooling that prove to be very useful in most cases. Even if you don't use ACID, transactions, key relations and other features, maintaining the basic type information in the database still has numerous advantages in data consistency, integrity and performance.

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.

Re: MongoDB History

#58

Post by manigandham »

trashcan wrote: post #31
manigandham wrote: post #15

Earlier quoted context omitted.

Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. 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…

> 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. What applications are much better in your opinion?

I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others.

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.

Re: MongoDB History

#59

Post by trashcan »

manigandham wrote: post #58
trashcan wrote: post #31

Earlier quoted context omitted.

> 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. What applications are much better in your opinion?

I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. 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.

I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives.

If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.

Re: MongoDB History

#60

Post by jinqueeny »

trashcan wrote: post #59
manigandham wrote: post #58

Earlier quoted context omitted.

I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. 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.

I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives. If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.

TiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-quer...

The latest stats in the same case scenario (already-read posts) Zhihu is:

- 2.6 Trillion Rows

- 560TB data

- 200 TiKV instances

Post reply on HN