I am going to start a new series from this post. Many times you find great article on the internet that you would like to share with others. "Links" is one such series.
And very first link here is an Article written on Terracotta : An amazing technology for java application clustering. Its here : Kill Your Database. Terracotta is clustering technology with built-in support for HA. Clustering is all about shared data and when you talk about HA, you are actually caring for the shared data, its availability. Terracotta implements it by writing every change to shared data to disk in transactional manner. So if your data whose life is short or medium, (often you need to store derived data from the temporary data which is very large, and we use RDBMS for all of this) you can use terracotta to store it in very fast manner : since you don't have to convert data to relational model its all java. Pretty powerful!!. Other use case is Database off-loading which means you can use terracotta to store all data temporarily and then write to your database in manner which would not affect end-user response time. By doing this you remove database access and operation time from response time ( which mostly is the very significant part of the response time). Article mentioned above touches all these concepts. I will add one more link on terracotta org-site which describes this case ( and all other wonderful use-cases for terracotta). Here it is : Write Behind SOR. If you read my previous post, I had exactly discussed the same idea : Write Behind or Asynchronous writes. That time I knew only coherence supported this. Then I came to know that Gigaspaces also supports it. ( See comments below on the same post). But terracotta would be the most exciting among them all. Why? One reason is all existing application can easily integrate this pattern in there application with very small change in code-base. Second reason terracotta supports lot of java framework out of the box.
..
Tushar
4 comments:
Tushar
There are few points that one should consider with this pattern:
1. What do you do in case you already have an existing database, how do you integrate existing system with this model? You would find that this is probably one of the more common scenarios. In this case you will also find that mapping data from its existing format to the In-Memory representation is required. Note the use of external datasource as a plug-in allows you to plug-in different database implementation and mapping styles. The common one would be hibernate plug-in for existing database and black-box plug-in in case your just looking for durability and you don't care how the data is being stored. We found that this level of flexibility is required as in many cases the database serves also as an integration point with other applications and not just as a persistent storage.
2. What happens in case of a failure i.e. when the database server is down for 10 hours? Can the application continue to run?
3. How do you manage the transaction scope? If transaction is blocked until the database is synched you may loose large part of the performance benefit of working in-memory for read/write scenarios.
This has been some of the assumptions behind the design of our reliable async replication and Mirror service which runs today and already being used in most mission critical application in the trading area.
You can see more details on this pattern in some of my earlier posts here and here
My2c
Nati S.
GigaSpaces
ur blog Is very nice
@Nati,
Hi Nati,
Again thanks for the some more light on the real issues. Recently there have been very much interest in the idea of using Terracotta as some sort of data storage medium. Surely, it can be done but usage is limited. Terracotta can not be used as in-memory grid. But surely, it has some extensions like tim-async which implement part of the functionality of IMG and in some situation would be perfect fit. Terracotta reference application is one good example of this pattern.
Tushar
@web design india
thanks
Post a Comment