Re: High-Speed/Volume Database

Hi guys,

My vote would be DB2/400 running under on an iSeries box under OS/400

A good link:
http://www.iseries.ibm.com/developer/bi/bipaper.html

DB2 on the iSeries and what that means
http://www-1.ibm.com/servers/eserver/iseries/db2/udb400.htm

A small excerpt:
DB2 UDB for iSeries supports the full range of processing power from small uni-processors to 24-way symmetrical multiprocessing (SMP) parallel machines, to a cluster of 768 processors in a clustered configuration with a single-image view of your database. Today, the iSeries family provides over 200-fold growth within the single-system family, and over 10,000-fold growth when clustered systems are used. Each SMP node supports up to 128 GB of main storage and over 38 TB of disk attached to each system..

The parallel data loader allows all 24 processors within a single system, or 768 within a cluster, to be used simultaneously to load a single data table. Today, a single iSeries can load a table at over 100 GB/hr... You can also specify that only certain processors are to be used in queries of the database so that you can load-balance the CPU. My comments:
The AS/400 was designed back in 1970 as a 64 bit machine (48 in h/w initially), in the 18 years that I've worked with them unscheduled downtime on the machines I was working with averaged less that 5 hours per year. The database is integrated within the operating system, as is security, as is communications. Fixes are cumulative and non-conflicting (unlike NT), the disk drives are self load balancing. If one of the drives is sick, the system automatically calls IBM and has a tech sent out before you even know the drive was about to go down. ODBC and SQL access is integrial. In short, its a mainframe, don't expect pretty windows, though IBM is working on it. Text based screens, but performance ROCKS, but as usual, you will pay for it.

Email me directly if you want to talk, I don't normally monitor this group.
Remove the XXXX: timhXXXX_at_cruzio.com

chris.arets_at_hetnet.nl (Chris Arets) wrote in message news:<10c07c02.0205041323.5ff9d112_at_posting.google.com>...
> What i think Anton means is clustering of a database. This means
> several computers (for example 20 ordinary desktops) are 'linked' to
> eachother to form a cluster, so that the whole cluster can handle your
> database. Linux is the way to go here by the way. The point i really
> wanted to make is that Oracle also provides clustering i believe since
> version 8, but the version you have to look up on the website of
> Oracle.
>
> Greets Chris Arets
>
> P.S. The point about seeking professional consulting is a strong one
> :)
>
> Anton Versteeg <av_at_nospam.for.me> wrote in message news:<3CD3AF0E.789EF440_at_nospam.for.me>...
> > I agree with almost everything Bob is saying except of course his choice
> > for Oracle. I would consider using DB2 UDB EEE (parallel database) where
> > you can spread the data across different machines (nodes). This is a very
> > scalable solution.
> > As for the platform: Win2K, Unix, or Linux.
> >
> > Bob Hairgrove wrote:
> >
> > > On 3 May 2002 11:32:44 -0700, gatesucks_at_hotmail.com (Bob Smith) wrote:
> > >
> > > >We are designing an application that needs to use
> > > >a relational database to hold quite a large amount
> > > >of data.
> > > >
> > > >In particular there is one table that has about 33
> > > >fields, 18 indexes, and 120 bytes per record.
> > >
> > > How do you know how many "bytes per record" there will be? What
> > > difference does it make? This will vary a great deal and is a rather
> > > meaningless quantity compared to other things such as block size.
> > > Besides, those indexes will take up quite a bit of space on their own
> > > ... sometimes almost as much as the data itself.
> > >
> > > >Additionally, we are going to need to add about 2
> > > >million records per day to the table, delete about 2
> > > >million records per day from the table, hold 2 weeks
> > > >worth of data within the database (approx. 30 million
> > > >records), and sustain an average add rate of about 23
> > > >records per second while, at the same time, sustaining
> > > >an average delete rate of 23 records per second.
> > > >
> > > >My questions are, what database software should we use,
> > >
> > > Depends on how much your data integrity is worth to you as well as how
> > > much (or little) downtime you can afford. You look at the licensing
> > > and do your own arithmetic. ;-)
> > >
> > > >what kind of hardware platform will be needed to
> > > >support the specifications enumerated above,
> > >
> > > Same as above.
> > >
> > > >and what kind of average query performance can we expect?
> > >
> > > Depends on whether you're talking about reads or writes. You're well
> > > advised to leave index creation alone until you're actually up and
> > > running because they can really get in the way of your updates,
> > > inserts and deletes. Only use an index if query performance demands
> > > one (I'm not talking about constraints here). With only 33 fields, 18
> > > indexes sounds like a few too many to me, but it really depends on
> > > your data design. Each foreign key or unique constraint as well as
> > > primary keys will usually be implemented through one or more indexes,
> > > so it's always a trade-off as to how many are necessary. In general,
> > > the fewer the better if you can get away with it performance-wise and
> > > relational integrity-wise.
> > >
> > > You have a lot of data to manage and a lot of activity on the
> > > database, so I would look at Oracle if I were you. And you'll need one
> > > or more DBA's that know what they are doing. As to OS, some flavor of
> > > Unix (better Sun than Linux because of the better support ... you pays
> > > for what you gets ... and I would stay away from Windows for something
> > > this big) is probably the way to go if you choose Oracle.
> > >
> > > Seriously, though, you should get some real professional consulting
> > > instead of posting to newsgroups ... do you really want to take the
> > > risk of having some college student with no experience telling you how
> > > to handle this?
> > >
> > > Bob Hairgrove
> > > rhairgroveNoSpam_at_Pleasebigfoot.com
Received on Wed May 08 2002 - 02:48:29 CEST