Bottom line: If you want to do a little OLTP on a Teradata box you buy for other reasons, fine. But if your main goal is OLTP, it’s the wrong thing to get.

I should add that Teradata’s architecture is somewhat more OLTP-like that newer analytic DBMS. E.g., it is designed for random more than sequential reads, it assumes you’ll probably normalize your data, you can buy Teradata boxes with lots of small, fast disks, and so on.

If you are reading between the lines here, you will see that Teradata’s I/O layer is very inefficient for a data warehouse. If you look around almost every DW DBMS vendor is focusing on maximizing sequential I/O so that they can get the most disk bandwidth out of each HDD. The quote of “15 MB/second on their fastest disks” is unfortunate as those drives are physically capable of doing well over 100MB/s of sequential I/O. This likely has to do with the small random read pattern that is common with Teradata. Michael McIntire commented on this back in April. This is also the reason that Teradata’s systems have a very large number of HDDs in them. For instance, the 5555 series generally consists of 3/5 cliques which is 3 dual socket quad core Intel Harpertown hosts (plus one spare host) and 5 fibre channel arrays each with 60 HDDs, so the ratio of HDDs to hosts is 100:1. The capacity of these drives has been 146GB for quite some time, and I hear they are starting to now offer the 300GB drives. Compare this to other vendors (say like Oracle Exadata) where the drive capacities are 600GB SAS (or 2TB Midline SAS) and the scan rates per disk are around 125MB/s – over 100MB/s more per HDD than Teradata. In comparison, a single Sun Oracle DB Machine has a physical scan capacity of 21GB/s with 168 SAS HDDs and a Teradata 12 node 1200 drive 5555 system has a physical scan capacity 18GB/s (1200*15MB/s), so what Exadata can do in 1 rack, it takes Teradata on the order of 8 or so racks of equipment. Knowing this, it now makes sense why Teradata is so “excited” about using SSD. By doing so, it removes the “latency penalty” for random I/O operations and has the opportunity to drastically shrink their data center footprint, though of course at the increased cost of SSD vs HDD.

Just following up on my second point regarding the use of a SAS disk interface versus PCIe, a new post from James Hamilton (one of the genii behind AWS) appears to concur.

“Expect flash to stay strong and relevant for the near term and expect it to be PCIe connected rather than SATA attached.”
http://perspectives.mvdirona.com/2009/10/26/AndyBechtolsheimAtHPTS2009.aspx

Admittedly this is in reference to a presentation given by a Sun employee. Nevertheless, disk interfaces are already too slow before TD even release their flash appliance and that seems like a problem to me.

Joe

My point: There are lots of good alternatives.

2. You can’t just add sufficiently well-performing long-running queries into a good OLTP DBMS and say you have a good mixed-used system. E.g., workload management gets a lot harder. A DW should ideally have more optimistic locking than an OLTP system. Etc.

3. In theory, you can break tables into sufficiently small pieces and store them in sufficiently different ways that you can do everything with great performance and reliability in one system.

That’s theory.

4. The cost of hardware is often a small factor when compared with the cost of DBMS licenses. Just look at Oracle’s software cost per core (license and maintenance). Whether you’re paying $2,500/core for the hardware or (more likely) a lot less is, by comparison, pretty irrelevant.

For example; How would a 8 cpu/6 core server (48 cores) running SMP database software (take your pick Oracle, DB2 etc) with 256 Gig memory (total price ~$80K @ HP.com) with a 5TB SSD SAN (~ $200K RAMSAN) compete with a MPP players like Teradata or Netezza? Remember the lower energy costs of SSD and the OLTP functionality of SMP DB software. Which gives it more ODS flexibility. Again, for the low to mid-range DW it seems like a viable alternative?