The AWS and MongoDB Infrastructure of Parse

Re:The AWS and MongoDB Infrastructure of Parse by dhd415 on Thursday February 09, 2017 @10:12AM (#13607427)

I'd say YAGNI applies here since 95% of systems will never need to scale beyond the capabilities of a properly-configured RDBMS. Ensuring consistency and durability with a non-relational, distributed datastore generally requires a lot more detailed understanding of its internals than with a RDBMS, so choosing one of those rather than a RDBMS is going to impose costs that should be deferred until they're absolutely necessary.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by oblio on Thursday February 09, 2017 @10:17AM (#13607467)

Plus it's waaay more likely that bugs in application code will haunt you even more. Especially the lack of things such as foreign keys and other constraints.

Schemas can be straight jackets, but in many situations they're actually closer to life jackets.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by gerbilly on Thursday February 09, 2017 @11:46AM (#13608301)

Totally agree that schemas are lifejackets. Carfully modelled data can outlive the application it was originally written for.

Poorly structured data, on the other hand, where the schema and consistency is enforced in code is much harder to migrate.

Maybe our problem is that we write systems with a disposable point of view? We don't even think the system will be around long enough to require migration.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by luhn on Thursday February 09, 2017 @11:32AM (#13608124)

I think people underestimate just how far a properly-configured RDMS can scale. A machine with a couple CPUs and a few hundred gigs of memory can do a lot. Couple that with some tastefully-applied caching and query from a read replica when you can tolerate stale data... You can scale pretty far.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by brianwawok on Thursday February 09, 2017 @11:39AM (#13608207)

And don't forget sharding. If your load is very much user focused.. i.e. user A only cares about the items for user A within the DB... you shard by user_id, and can now host 10 billion users on a farm of RDBMS.

On the other hand, it gets more and more operationally complex as you add shards and failovers and such. If you KNOW you are going to hit that scale (say you are an established company with 100 million customers), it may not be the right choice.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by luhn on Thursday February 09, 2017 @12:14PM (#13608635)

Right. I'll remember that next time I'm an infrastructure lead at a company with a 100 million customers ;)

But thanks for pointing out sharding. It can be powerful strategy.

[ Parent | on HN ]

Re:The AWS and MongoDB Infrastructure of Parse by user5994461 on Thursday February 09, 2017 @02:15PM (#13609906)

Once you are at a 100 millions customers company, the urgency becomes to ban all these MySQL and postgre for production systems. Or you need to figure out how to seriously handle a multi master setup in production.

There are the 80% bottom of companies who are just toying around doing small products and MVP, that should stick to what's easy.

There are the 5% at the top who are guaranteed to get 1 million customers no matter what they ship, that should stick to doing things right and sustainable from the start.

Contrary to what the other comment state: sharding and failover are ALWAYS the EASIER choice at scale. The alternative is to be unable to change hardware/systems and to be forced into 15 hours downtime window for every maintenance/upgrade operation, which is a huge liability when you have real users.

The 2 types of companies have opposite priorities.

[ Parent | on HN ]