Hi, my 2 cents, avoid using the database unless you really need persistent transactional data. No database written today will scale out as fast as a reasonably well written distributed Java application. Just about every latency problem I run into is either related to GC or DB transactions. The DB solution almost always involves injecting some sort of cache. John Davies (well known in financial circles) talks about the enterprise without a database. Cameron Purdy (Tangosol Oracle) also talks (gingerly now that he works or a db vendor) enterprises without a db. He talks of a number of latency sensitive systems that never touch disk. All the data sits in RAM all the time. Setup properly using replicated cache, they have proven that these systems are every bit as reliable as disk based systems if not more so. The numbers are telling these guys that disk failure rates are much higher than ram failure rates. These aren't eveyday home applications, they run 24/7. But now they've been architected that way.
I wish I had more time to write my opinion on DBs but in short, I believe that databases fundamentally a great technology that has managed to escape into areas of our systems. This escape was encouraged for a number of pretty good reasons that fit with pre-internet bubble thinking about how to build systems and pre-2005 changes in hardware. Unfortunately we are still being taught to think pre-bubble yet demands and hardware require us to think differently. IMHO, we all need to think very deeply about the role of RDB in modern architectures. I'm sure that there will still be a role there for it though I'm quite convinced that it won't be nearly as dominating. To that point, in the interview with Ted Farrel, he pointed out that Oracle is finding some interesting and unexpected uses for Tangosol. Maybe unexpected for the Tangosol guys but certainly unexpected for Oracle. It is solving a number of problems for them by taking pressure off of their DB. I see that my post is very Tangosol biased. I could say the same for JBossCache, EhCache, GigaSpaces, GemStone, Terracotta and a number of others. Pretty much all of these guys will tell you that they are friendly with the DB as they can't afford to send out a radical message. However privately, they all see the DB as an impediment to large system scalability as it is currently being used. And these are the guys that know how to scale! Regards, Kirk Matthew Kerle wrote: > my 2 cents... > > don't cache financial / OLTP data, anything thats likely to change > within the lifetime of a single release. Bite the bullet and load it > from the database. cache things like lookup lists & static data, be > very cautious with more aggressive caching without a distributing > caching / invalidation mechanism. Database hits are pretty fast unless > you have a *lot* of them or some long-running queries, and then you > should probably re-examine your architecture and look at hitting > pre-built OLAP tables instead or similar... > > If you don't mind going the distributed cache route though, then you > can look at stuff like EhCache or similar. I haven't looked at these > but I assume they would have some sort of integrated invalidation > mechanism, but not having used them I can't comment much. Has anyone > else used a Java distributed cache and dealt with stale cache / > invalidation issues? > > cheers! > > 2008/12/5 etzel <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > > > > On 4 Dez., 14:06, Michael Lee <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I would recommend that you would go with the simplest option B > first and > > migrate to service-oriented option D. > > But it kind of feels a bit dirty having multiple applications > accessing the same data the same time. It is a bit like communication > through the database. What about caching (Hibernate 2nd Level Cache). > I would frequently have to invalidate the cache. What about > transaction. I'd had a better feeling if there would be only one > client that accesses the data. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
