Re: Opteron scaling with PostgreSQL

Поиск
Список
Период
Сортировка
От Steve Atkins
Тема Re: Opteron scaling with PostgreSQL
Дата
Msg-id 20040612180627.GA8066@gp.word-to-the-wise.com
обсуждение исходный текст
Ответ на Re: Opteron scaling with PostgreSQL  (jseymour@linxnet.com (Jim Seymour))
Ответы Re: Opteron scaling with PostgreSQL  (jseymour@linxnet.com (Jim Seymour))
Список pgsql-general
On Sat, Jun 12, 2004 at 07:19:05AM -0400, Jim Seymour wrote:
> "Dann Corbit" <DCorbit@connx.com> wrote:
> [snip]
> >
> > Another important point is that the data in an organization is always
> > more valuable than the hardware and the software.
> >
> > Hose up the hardware and the software, and insurance gets new stuff.
> >
> > Hose up the data and you are really hosed for good.
>
> It's amazing, how many people don't seem to get that.

It's often not true.

I use postgresql for massive data-mining of a bunch of high-update
rate data sources. The value of the data decreases rapidly as it
ages. Data over a month old is worthless. Data over a week old has
very little value.

If I lose all the data and can't recover it from backups then I can be
back up and running within two days worth of new data handling, and
back to business as usual within a week of new data.

If I lose a router or a controller and have to fault-find, order a
replacement and get it overnighted, reload the OS and restore the
database and analysis software it'll take me offline for at least a
couple of days, during which I can't even handle new incoming data,
so it'd still take me two-three days after that before I was back
up and running with usable data.

So, for that particular case the data really isn't as valuable as
the infrastructure, despite that segment of the business being
primarily data analysis.

In other words, different people have different needs. There are
perfectly valid cases where you just don't care too much about the
data, but need a decent SQL engine, others where you care about
data-integrity (no silent corruption) but don't care about data
loss, others where recovery from the previous days backup is fine
if the system crashes and others where loss of a single transaction
is a serious problem.

PostgreSQL handles all those cases quite nicely, and provides some
good performance/reliability trade-off configuration options.

Cheers,
  Steve



В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: index with LIKE
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Trying to minimize the impact of checkpoints