Databases on ISTORE: AME for parallel RDBMSs Noah Treuhaft

Parallel DBs on clusters Mature products from many vendors: IBM, Informix, Oracle, Tandem, Teradata Own the largest DB installations And still, lots of large, multimillion $ SMPs

Overview This presentation is about what we can do to improve the availability, maintainability, and evolutionary growth (AME) of large- scale DBs on ISTORE.

Outline State of the art and then our plans for –Availability –Maintainability –Evolutionary Growth

Availability: state of the art Tandem NonStop SQL on Himalaya servers Everything replicated for failover –DB objects –Processes –Processors Great uptime

The availability spectrum Availability as the range between “working perfectly” and “not working” Includes shades of “working, but degraded” Example: disk errors before failure

System view Degraded components affect the larger system: performance faults Keep system performance up even as components lag “Performance availability” through “performance redundancy”

Graduated Declustering Replication for performance redundancy in read- mostly workloads To Client0 Before SlowdownAfter Slowdown Client0 B Client1 B Client2 B Client3 B Server0 B Server1 B Server2 B Server3 B To Client0 From Server3 B/ Client0 7B/8 Client1 7B/8 Client2 7B/8 Client3 7B/8 Server0 B Server1 B/2 Server2 B Server3 B From Server3 B/2 3B/8 5B/8 B/4 5B/83B/8 B/2

Read Performance: One Slow Disk

Eddy (River) Dataflow query processing with a flexible query plan. SELECT * FROM a, b, c WHERE a.x=b.x AND b.y = c.y x y ab c ab c xy

Maintainability: state of the art Tandem & Teradata Tandem has cluster-special HW Both have renowned management tools

Managing storage Simplify with RAID/virtual disks/logical volumes and give up layout control Or maintain control and face the hardship of managing 1000s of disks.

Profile-derived feedback for storage management Profile a workload (trace SQL statements) Identify hot tables & partitions using statistics Feedback from optimizer on proposed reorganizations

Evolutionary growth: state of the art DBA makes the most of –nodes with faster CPUs & more memory –bigger and faster disks

Evolutionary growth Layout tool incorporates disks of any size GD & Eddy make slower HW look like a performance fault

The truly large scale Experience shows that large I/O-bound clusters have performance faults Parallel DBs are scalable, but have limits Addressed by GD & Eddy

Closing remarks There are improvements to be made to parallel DBs Ideas that improve AME: –GD –Eddy –Profile-derived feedback for storage management