Re: looking for some real world performance numbers
От | Guy Rouillier |
---|---|
Тема | Re: looking for some real world performance numbers |
Дата | |
Msg-id | 471C10DC.3020308@burntmail.com обсуждение исходный текст |
Ответ на | Re: looking for some real world performance numbers (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: looking for some real world performance numbers
Re: looking for some real world performance numbers |
Список | pgsql-general |
Dave Cramer wrote: > snacktime wrote: >> I'm working through the architecture design for a new product. We >> have a small group working on this. It's a web app that will be using >> ruby on rails. The challenge I'm running into is that the latest >> conventional wisdom seems to be that since obviously databases don't >> scale on the web, you should just not use them at all. I have a group >> of otherwise very bright people trying to convince me that a rdbms is >> not a good place to store relational data because eventually it won't >> scale. And of course we don't even have version 1 of our product out >> of the door. I'll admit we do have a very good chance of actually >> getting tons of traffic, but my position is to use a rdbms for >> relational data, and then if and when it won't scale any more, deal >> with it then. >> >> So what would really help me is some real world numbers on how >> postgresql is doing in the wild under pressure. If anyone cares to >> throw some out I would really appreciate it. I missed the original post on this, so I'm replying to Dave's response. To the OP, I don't know where you obtain your conventional wisdom from, but I'd look for another source. Just about any site you might visit that handles lots of data has a DBMS of some sort behind it; given that IMS and Adabase have been out of favor for 20 years, most of those DBMSs are relational. So if it can work for your bank, E*Trade and eBay, chances are it can work for you. As far as real world numbers, we have a data-intensive app (network data collection for a telecom company) that is currently inserting about 16 million rows a day. I benchmarked PG for that app and with some tweaking, PG could handle it. The current app uses stored procedures for all inserts, and PG didn't do well with that approach; substituting embedded inserts fixed that problem. So PG can definitely "handle" very large transaction volumes. As with any DBMS and any application, you may encounter challenges (like the one I point out with using stored procs for high-volume inserts) that require you to address with some thought. -- Guy Rouillier
В списке pgsql-general по дате отправления: