17 ms·
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 fo
by twblalock 8y ago
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.
- jrochkind1 8y agoFair 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...
- AznHisoka 8y ago"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.
- twblalock 8y agoYou 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.
- ayw 8y agoYou 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.
- dizzystar 8y agoExcept that devs have to do ETL every day so analysts can do their query work.
- twblalock 8y agoThat can be automated.
- dizzystar 8y agoIn theory, yes; in practice, not really.
- sdoering 8y agoI 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.
- marcinzm 8y agoWhy? Technically speaking, simple ETL is easy to automate and not too much maintenance headache.
- marcinzm 8y agoWhich you'll likely want with any DB since analytics workloads are very different than the usual production DB workloads.
- mitchell_h 8y agoThis is such a common issue there's an entire architecture pattern developed to solve it. https://en.wikipedia.org/wiki/Lambda_architecture 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.
- sbr464 8y agoI agree with this perspective, and have been researching it more lately.