What do you use as quey language in these kinds of system? I can see how an RDBMS isn't really needed for persistance. But they do have quite advance query engines. What is the replacement?
BR, John On Fri, Dec 5, 2008 at 8:20 AM, kirk <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
