John Nilsson wrote: > 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? Tangosol defines an OOQL that works quite nicely. The query engines on RDMS are quite advanced. However, they tuned the [EMAIL PROTECTED] out of something that is hidden behind a technology that is 6000x times slower and works on top of an architecture that force serialization on another technology thats almost as slow. It's not that the technology is bad, it has served us quite well and there is still lots of life in it. That said, its also like your comfy old sneakers that may not be up that marathon your training for. IME, synchronizing data in a database on the back end or a distributed system is a recipe for disaster. In fact, synchronizing on *anything* at the back of your distributed architecture is a recipe for disaster as you run right smack into Little's law. IMHO, Amdahl may get all the glory but Little is just as important when is comes to scaling.
Regards, Kirk > > BR, > John > > On Fri, Dec 5, 2008 at 8:20 AM, kirk <[EMAIL PROTECTED] > <mailto:[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]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> > > > > > > > > > > On 4 Dez., 14:06, Michael Lee <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[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 -~----------~----~----~----~------~----~------~--~---
