Let’s suppose a system requires 2 database because there 2 components written by different teams:
“Rails”, a web app, which displays output data from part 2.
“Analytics”, a processing engine written in say Python, which has huge daily import data volumes and lots of number crunching, and will probably run on EC2 instances.
However, there are some tables/data shared between the systems. These are relatively modest in size.
What’s the best way to manage this situation of some data is shared.
My guesses are:
2 databases is definitely required, as opposed to one giant database, even though a number of tables are in common.
Communication between the two systems should be via messaging, such as RabbitMQ.
Synchronization of the data of the common tables will be via messaging.
I’m just wondering if hand built messaging for synchronization of the shared data is overkill? It seems like there should be something simpler as this problem feels rather generic.
Questions:
Use Heroku to manage the non-rails database?
Assuming 2 separate databases
Any way to manage schema migrations used by both systems?
Any automated way to handle synchronization of some tables?
If the data is truly bidirectional then prepare for a world of pain. If each system needs only read-only access to data unique to the other, consider scheduled imports, API access, or database links with appropriate read only permissions (the specifics of which depend on your DB). In the case of your rails app, in can actually be configured to connect to several different databases.
I’d try very hard to avoid a situation where the data can be updated in multiple databases and needs to be synced between them. There are domains where this is necessary, but that complexity is best avoided if you can help it.
I’m going to keep the Rails DB pristine. I won’t know if the other team directly accesses the DB, synchronizes it, etc. The other team will be required to send Rails messages via RabbitMQ.
I’ll publish messages for the other team, as they require it.
There definitely are some common tables of information, and making one app is a far worst proposition, especially given the other team wants to use Python.