Re: 10 billion transactions a year?

We do about 75B rows a year (projecting 90B rows next year). It is about 1.5 TB of data.

We use a three tiered federated database. The 'control' or 'front end' that the users connect to for their reporting and queries (about 200GB) which is linked to a middle tier that contains the 'recent' data (1.5 TB). The middle tier is also linked to a group of archive databases (about 4.5TB) of historical data. (It is a warehouse for data, 7 years of transactions, but not a datawarehouse, in that we do not analyze the data for our clients.)

The front end and middle tier are HP-UX multiprocessors, but are not clustered. The archive tier is a mixture of Sun and AIX. The servers are a mixture of Oracle 7, 8 and 8i.

The application(s) supports concurrent 150-200 users.

The main problem we have is finding maintenance windows for things like backups, tuning, upgrades, etc. While of course everyone wants everything to run faster, we don't have too many performance issues.

"Jim Kuschill" <kusch_at_fuse.net> wrote in message news:<tllkkk7r7bd8b6_at_corp.supernews.com>...
> We are looking at the need to build an application that can scale to upwards
> of 10 billion transactions/year. We've managed a data mart containing 2
> billion transactions, but this new application will require a fair amount of
> complex processing to post the transactions (the data mart just
> reads/maps/plops) so isn't a good extrapolation of our knowledge.
>
> My two best guesses at an architecture to support something like this:
> a) a good sized computational cluster, essentially sharing the work
> b) some sort of master/slave organization with the slaves using database
> links to perform the majority of the processing, with the master being
> relegated to more or less a "posting machine"
>
> Comments?
>
> Any experiences anybody has had with volumes anywhere near this would be of
> interest - even if they were *bad* experiences (at least we might be able to
> avoid some black holes).
Received on Fri Jul 27 2001 - 13:35:50 CDT