Integrating Databases with IBM WebSphere eXtreme Scale
We've made some video discussing how WebSphere eXtreme Scale integrates with databases and put a playlist of 5 of them together on youtube. In total, it's only around maybe 20 minutes to watch all five but I'd appreciate any comments. Thanks
Comments
Thanks for these video's - We're finding them very helpful. A question regarding DBMS's and extreme scale:
If my workload is too big for a single DBMS (even if fronted by extreme scale) whats a good way to go about solving this? Would you recommend something like writing my loader to choose a database shard based on object key?
It's probably worth mentioning that a good way to get the events to invalidate caches is hooking into the txn log. I don't know if DB2 has a txn log API, but certainly Sybase and Times Ten both have support for hooking into database changes via the transaction log. This avoids any performance penalty for the updating process which would be the case if triggers were used. And clearly it avoids the need for polling.
The issue is certainly a very useful one to discuss since in my experience there are often 2 tier apps already accessing the database and you need to have some way of handling updating of data and staleness in any data cache/grid that sits in front of the database.
Guy,
Yes, database sharding in the loader based on key is the way to go. There are open source projects available to do sharding on top of OpenJPA and Hibernate.
Robert,
DataMirror is what I'm looking at to do what you describe. I can implement my tx log reader once and let datamirror handle the differences, trying to prioritise this now.
Thanks for these video's - We're finding them very helpful. A question regarding DBMS's and extreme scale:
If my workload is too big for a single DBMS (even if fronted by extreme scale) whats a good way to go about solving this? Would you recommend something like writing my loader to choose a database shard based on object key?
Posted by: Guy Laden | March 15, 2009 at 10:43 AM
It's probably worth mentioning that a good way to get the events to invalidate caches is hooking into the txn log. I don't know if DB2 has a txn log API, but certainly Sybase and Times Ten both have support for hooking into database changes via the transaction log. This avoids any performance penalty for the updating process which would be the case if triggers were used. And clearly it avoids the need for polling.
The issue is certainly a very useful one to discuss since in my experience there are often 2 tier apps already accessing the database and you need to have some way of handling updating of data and staleness in any data cache/grid that sits in front of the database.
Posted by: Robert Greig | March 15, 2009 at 03:11 PM
Guy,
Yes, database sharding in the loader based on key is the way to go. There are open source projects available to do sharding on top of OpenJPA and Hibernate.
Robert,
DataMirror is what I'm looking at to do what you describe. I can implement my tx log reader once and let datamirror handle the differences, trying to prioritise this now.
Posted by: Billy | March 15, 2009 at 05:32 PM