Forum: VoltDB Architecture

Post: Subscription to changes in DB

Subscription to changes in DB
bradleymeck
Jun 22, 2012
Is there a means to get notifications sent from VoltDB when a table changes (triggered on update/insert/delete) to an outside application? I realize this will not be ideal when number of changes excedes a threshold, but for us we would like to have database replication and notifications for failover reasons to be outside of our program and instead get notifications directly from the DB.
Notifications
rbetts
Jun 25, 2012
I'm not quite sure I understand the question. Taking a bit of a guess - please follow up if I've misunderstood.

VoltDB doesn't include a trigger / notification service. However, you might look at the export feature:http://blog.voltdb.com/voltdb-export-connecting-voltdb-to-other-systems/

(Edit: Or, if you want VoltDB to VoltDB replication, we have this feature explicitly: http://voltdb.com/category/tags/replication. Also, in the latest release, you can produce CSV snapshots - if you wanted to process the table state in a different system.)

Ryan.
This is similar to what I am
bradleymeck
Jun 25, 2012
This is similar to what I am looking for, but I have no desire for the export connector to be used as a means to retrieve data. We are writing state to a table and syncing table state in memory with a semi-realtime application. We would like to keep the table in VoltDB for other queries; however, polling the database for changes is very costly when we have many subscribers, but we may be able to write a workaround using these export features. Do you know of any problems if we just save the entries back into another VoltDB table after sending them off for syncing?

Seems like the proper way to do this right now is
[ VoltDB ] <- Data -> [ Exports Connector ] <- Data for Storage -> [ VoltDB ]
Where the Exports connector sends a broadcast to all the clients we wish to notify of changes.
Update poll/push
rbetts
Jun 26, 2012
This is similar to what I am looking for, but I have no desire for the export connector to be used as a means to retrieve data. We are writing state to a table and syncing table state in memory with a semi-realtime application. We would like to keep the table in VoltDB for other queries; however, polling the database for changes is very costly when we have many subscribers, but we may be able to write a workaround using these export features. Do you know of any problems if we just save the entries back into another VoltDB table after sending them off for syncing?

Seems like the proper way to do this right now is
[ VoltDB ] <- Data -> [ Exports Connector ] <- Data for Storage -> [ VoltDB ]
Where the Exports connector sends a broadcast to all the clients we wish to notify of changes.


A VoltDB to VoltDB loopback via the export connector feels a little strange to me, if that's what you've illustrated?

You can update multiple tables in one stored procedure, of course. So you could write your update to your persistent VoltDB table and then record the update to the export table in the same transaction? That might be simpler?

Ryan.
Could work that way too, just
bradleymeck
Jun 26, 2012
Could work that way too, just felt it would be safer if the exports table actually had a real backing store rather than the in-memory caches. Export-only tables are an option that we have not fully investigated after seeing this.
Ginokeck
May 24, 2013
Yes we can updated multiple table with the help of the stored procedure, but while updating each time the trigger will be fired.