It's not the network round trips that are problematic. That can be mitigated, and is by some ORM clients like Eclipselink by threading the queries across multiple connections. The problem is ACID. You have to make sure that before you return a commit call to the client that the entire transaction is whole and stored. Each record you send to the back end must be put somewhere that won't go away, and places that won't go away are mostly made up of disks these days, which are slow. There is also the matter of indexes and foreign key checks too that can be expensive.
Having said that - I can count on one hand the number of developers and IT people I've worked with over the years who had any idea how to configure database server to get good performance. There are many moving pieces, and if they are out of whack even by a bit, you can loose an order magnitude of performance. For example - anyone who has done the benchmarks knows that you simply don't put linux on HP x86 hardware because the drivers in linux for the controllers are not great leading to very sub-optimal performance. Other people put OLTP systems on a RAID 5 or 6 and wonder why they don't see better speed. They don't understand fundamental hardware issues like the stripe read penalty in RAID 5/6. And let's not even get into how a journaling file system can suck the life out of performance on a transaction log. Alex On Thu, Jul 23, 2009 at 1:01 PM, Rakesh<[email protected]> wrote: > > I think its worth pointing out 2 major changes in how we work with > relational databases that have a negative impact on performance (but > many other advantages): > > 1. We started developing in OO languages and thus introduced an > impedance-mismatch leading to inefficiency in processing. > 2. We choose to run our business logic in a separate (physically and > logically) tier from the data. Network round trips introduce an order > of magnitude slower performance. > > I think its telling that in environments where performance matters > more than anything (eg banks), they choose to use languages like C > (Pro C) and stored procedures. > > Relational databases are still with us because they are reliable and > fast. Unfortunately we choose to access this data in inefficient ways. > > R > > On Thu, Jul 16, 2009 at 11:21 AM, Christian > Catchpole<[email protected]> wrote: >> >> I think this recent wave or 'rethinking' peristance, and google apps >> big-table style storage, is long overdue. I'm not saying it's not >> going to be a difficult progression, but it's long overdue. I >> remember when I first started working with SQL storage.. around 1999. >> I couldn't believe how it worked. It all just seemed so backwards >> compared to how i understood software to work. The data types didn't >> match the ones I was used to.. and SQL seemed so unprogramatic and >> clunky. And how could getting your data over a socket ever be >> efficient. >> >> Now it seems the only way a high volume web site can interact with >> it's database is by using a huge cache infront of it. Now this >> suggests to me that the technology (or the access to it) is falling >> behind the way we need to use it. And even if it works, the problem >> with a cache is that me be out of sync with the database. And even if >> you use multi-cast updating caches, well, then your providing sync >> functions that I would expect the database to be handling. In effect >> we are creating in-memory databases which are kept in sync with the >> storage. >> >> I'm not saying I have any magic answers, only that SQL databases, >> while highly efficient for many purposes, with an industry based >> around them, are obviously not cutting it for many projects. >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
