Hacker News Reader

Comment by heliodor | Hacker News Reader

Yep, just regret and misery.

Back in 2010 when the MongoDB hype was high, the well-known company where I was working at the time decided to build the next version of the product using MongoDB. I was on the analytics team and had to code a whole bunch of intricate map-reduce jobs to extract summary data out of Mongo. I'd repeatedly head to the product team and ask them to explain the edge cases I was seeing in the data and they would not be able to give me an answer because the data was on the third or fourth version of their mentally-stored schema and no one knew anymore. All in all, misery.

View on HN

I decided to check out the hype back then, and started writing tutorials on using PHP with MongoDB. After the 3rd posting, I realized that they were all about being anti relational, and though you you could have keys to other records in your record. This lead to bringing back records, querying more records, then manually filtering records,rinse and repeat.

Iirc, they've turned around on their anti relational views and now allow for joins.

I looked at OrientDB awhile back ago, but it fell flat with the lack of features and oddness.

If I had more time, I would really dig into ArangoDB.

While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar?

Since they are both of the NoSQL family.

I'm curious as well, since my company is moving from Postgres to DynamoDB.

Could you share your use case?

DynamoDB is a completely different beast and would use no other data store unless I had to. It can pretty much handle any transactional workload I need.

It's cheap, its fast and it scales super high. Don't need much more

DynamoDB is consistent and scalable, not fast and cheap.

DDB is great for storing data that is required to be scalable and never needs to be joined. Add in DAX, developer time necessary to orchestrate transactions, calculate the scaling costs and...that's how AWS gets you.

Plus, local development requires half-complete emulators or a hosted database you're charged for.

No, maybe people should think twice about DynanoDB.

This came up in a thread a few days back, but people considering it should note that Dynamo’s transactions are limited to 25 rows. That may be enough for most operations, but I definitely wouldn’t say it can handle “any transactional workload”. I ran into this limit pretty quickly when trying it out.

DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash against Mongo was because it basically claimed to be well-suited to any use case, when its sweet spot was really far narrower. To be successful with Mongo, you need to design the entire app around its limitations, but those limitations were initially downplayed and obscured.

People were convinced that Mongo was a good choice as a default, general purpose db, when it clearly wasn’t for about a million reasons.

I don’t think DynamoDB is marketed or viewed in the same way. The docs are pretty clear about needing to design your data model to specifically work well with Dynamo. People using it seem to generally be aware of its limitations, and deliberately choose to accept them for the sake of performance and scalability. At least that’s my perception.

What are those good use-cases for mongo?

Basically when speed and horizontal scalability are very important, and consistency/durability are less important. It’s also pretty good for unstructured or irregularly structured data that’s hard to write a schema for.

Web scraping or data ingestion from apis might be a reasonable use case. Or maybe consumer apps/games where occasional data loss or inconsistency isn’t a big deal.

It can also be used effectively as a kind of durable cache (with a nice query language) in place of redis/memcached if you give it plenty of ram. While its guarantees or lack thereof aren’t great for a database, they’re pretty good for a cache.

I worked for a big news website- we used mongodb for pixel tracking data.

I went on to work at mongodb

> I don’t think DynamoDB is marketed or viewed in the same way. The docs are pretty clear about needing to design your data model to specifically work well with Dynamo.

More importantly, AWS is very explicit in letting newcomers be perfectly aware that DynamoDB's usecases are, that they are very specific niche use cases, and that if users require schemas and joins then they should just stick with either relational databases or graph databases.

Those who overpromise will always disappoint.

Would that be better if they had use typesceipt or jsflow for the data type ?

Reply on news.ycombinator.com