5 ms·
In our case we set up a dedicated cheap database server only for ChartIO. Then we have a script that copies to it analytics data from our production servers eve
by swisspol 13y ago
In our case we set up a dedicated cheap database server only for ChartIO. Then we have a script that copies to it analytics data from our production servers every few hours (while also anonymizing what needs to be just to be extra safe).
- john_w_t_b 13y agoThis is a good approach. I work with ERP systems for large companies, and it's typical to separate the transactional database (OLTP) from the analytics database (OLAP). There's usually a replication process to copy transactions into the reporting system.
- thingsilearned 13y agoGreat use case! We don't support an API that you can push data to, but that's because whatever API we build, it would never be easier to learn or have as much language support than just spinning up a PostgreSQL instance and writing the data to it. Quite a few of our customers use us this way.
- swisspol 13y agoYou guys should really suggest this approach in the setup guide (it can be phrased in a way not to scare potential users). The alternative of directly accessing production database servers is really risky.
- thingsilearned 13y agoAgreed. I'll work on it.
- aiiane 13y agoYep. That's the kind of approach I'd like to see Chartio recommending (or at least, providing suggestions for).
- tixocloud 13y ago+1 for getting non-operational stuff off of the production servers. In my opinion, production servers should be left untouched by analytics and what not. I'd prefer not tying up resources that could better serve customers.
- rdl 13y agoThis seems like what you'd do just to protect your production server from some crazy load/etc. issues from analysis, too. I can't imagine giving read-only access to a core rw database server to anything which didn't need it.