Hacker News Reader

Comment by twblalock | Hacker News Reader

The people who write the business logic and the people who do the analytics have different concerns. It's sometimes better to make different database choices for those two systems and just copy the data into the analytics system, rather than make a substandard choice of database to try to accommodate both.

If the devs want to use Mongo, it's their problem -- it shouldn't matter much to the analytics people, because they can just copy the data into a different database that fits their needs.

View on HN

This is such a common issue there's an entire architecture pattern developed to solve it. https://en.wikipedia.org/wiki/Lambda_architecture . No classic ETL, and any number of folks/systems can plug into the messaging system and get all the data.

Fair enough. Perhaps there are other uses of mongo going on in addition to exporting it to a different database/format? Otherwise I'd be curious what justifies the mongo choice.

Certainly sometimes you are in a position where you just gotta take what other units in the org give you and deal with it.

But _someone_ in the org is hopefully in the position to be able to articulate why they are using mongo in the first place...

Except that devs have to do ETL every day so analysts can do their query work.

That can be automated.

In theory, yes; in practice, not really.

I tend to disagree. Having multiple automated ETL processes running for different projects/clients/colleagues I see that the code does not change as often, as I had anticipated.

Automation here (in my case) is a net win on time.

Why? Technically speaking, simple ETL is easy to automate and not too much maintenance headache.

Which you'll likely want with any DB since analytics workloads are very different than the usual production DB workloads.

"they can just copy the data into a different database that fits their needs."

That's easier said than done when your database is over 10 TB big.

You only need to copy the stuff that changed since the last time you copied stuff.

If you are really generating 10TB of data more than a few times a day, you can look into putting it in something like Kafka for real-time consumption by the analytics team instead of batch copying.

You just need to read the oplog, so it only needs to track your saves.

In general, you probably should have at least something in your stack which reads all changes from your DB, at the very least for backup reasons.

I agree with this perspective, and have been researching it more lately.

Reply on news.ycombinator.com