To: Mark Finger who wrote (163 ) 2/13/1998 6:31:00 PM From: Red Brick DBA Read Replies (1) | Respond to of 304
Hi, I'm new to Tech Stocks and am just trying it out for a couple weeks. But I had to respond to the stuff I'm seeing here. The reason I couldn't resist is I'm a DBA with several years' experience on a variety of systems, including a little Oracle and a little Red Brick. >>>If you look at REDB's web site, all their white papers are 18 months >>>old, from 1996. They're still gloating over their 1995-96 prowess. >>>There is not a single white paper from 1997 or 98. So, the question >>>is, how differentiated are they today? >The answer is that they aren't. In fact they are now in a trailing >position in many ways. >1. They have a single purpose engine--data warehousing in small >sizes (under 100G) and must be suitable for star architecture. Actually, their single-purpose engine is an asset. It's a lean, mean fast machine that doesn't have all the extra baggage of an OLTP database (e.g., locking, logging). Building a successful data warehouse is like racing in the Indy 500. You can certainly enter the race with a Chevy Suburban (which is good for many other purposes like injury prevention, hauling stuff, etc.), but if you want to win the Indy, you need a race car that's been built for that purpose. And, it's not just for small warehouses either. REDB has a number of customers with extremely large databases. Go talk to Tandy. Theirs is over 2TB. >2. No ROLAP (IFMX) or MDBMS (Oracle) support. So? >3. How many partners (VAR's) do they have to help set up the >systems? Compare to the many VAR's supporting ORCL, IFMX and >SYBS warehousing with additional capability. This business will grow when people wake up, smell the coffee and start buying the product. >4. ORCL and IFMX match the the prime point of Red Brick >architecture with their new index types (multi-table join) in their latest >releases. Yes they do ... in their literature and in their dreams. I did a small "bake off" with Oracle 8.0.3 vs. Red Brick 5.0.14 several months ago when we were trying to decide between the 2 for our major warehouse project. Granted, it was an "out-of-the-box" test with only minor tuning, but we did try to keep things as equal as possible. Suffice it to say Oracle didn't win. (I guess I'm not allowed to publish actual numbers.) One of my coworkers was giddy over the data loading rates and load features of REDB. >5. ORCL and IFMX support more hardware types (MPP, clusters, >NUMA architecture), especially for larger warehouses. REDB also runs on MPP but generally doesn't need to because you can get more bang for your buck on SMP systems (i.e., you have a faster, smarter db engine so you don't need as much iron behind it). >6. Really take a careful look at Sybase IQ. That is a very nice >product that is designed for areas where Red Brick does not >compete, and can compete well in some areas that are not the best >for Red Brick. No experience with IQ, but haven't heard good things from a DBA perspective. And it DOES cover the same territory as REDB. >Summary: Red Brick has seen their primary area matched, and the >competitors ahead in other areas. What does that mean for the long >run. Consider carefully. My opinion is that REDB is still ahead ... at least ahead of Oracle. I've had several occasions in the few short weeks I've worked with O8 to call their tech support. I went to v8 rather than sticking with the more-stable v7 because I needed the partitioning, bitmapped indexes and add'l optimizer plans. When I couldn't figure out how to grow my partitioning scheme, I called Oracle. They didn't have anyone on staff who had any experience with v8 yet (it's been out HOW LONG?). It took weeks to get a good answer. Oracle's loader is still slower and stupider. Case in point: When you load data to your warehouse, you're not going to always get it right. The database ought to be able to recover gracefully. Instead, if you have duplicate data, it'll invalidate your indexes and you must drop the index on the entire table, not just the partition, and recreate it to fix it. There is a command to fix just the broken partition, but the command itself is broken. Non-DBA's probably don't have an appreciation for the degree of frustration this can cause ... not to mention delay in getting the warehouse up and in a usable state, but trust me, it's HUGE. REDB, in contrast, will throw out the dups for you without messing up your table. You can gracefully clean up the offending rows and reload just those rows to your table without losing service to your database. This is just one example of many that I could cite how REDB has it 80 bezillion times over Oracle in performance, ease of management and just plain cool features. I'm like a pig in mud with this db. Oracle 8 was shipped in a half-baked state with major features broken (according to the instructor of a 3rd-party-taught O8 class one of my coworkers is attending this week and verified by my own experience). I guess that's not so unusual for a new software version, but what I find irritating as all get out is that everyone is trumpeting the claims of Oracle 8 as if it were the 2nd Coming. No one can possibly be building their data warehouses on this stuff yet. And the point of all this rambling and muttering, you ask? First, it's to set the record straight about what's right and wrong with the underlying technology. Second, I can't figure out why copies of REDB aren't flying off the shelf and the stock price isn't going through the roof (of course, I realize that there's more than great technology driving stock prices, but in a perfect world ....). Maybe the only reason is they don't have the advertising budget of an Oracle. The word just isn't getting out. Hmmm ... maybe someone ought to take to the streets with a megaphone. Maybe someone could suggest THAT tactic to their sales force. OK, I've said enough. If you made it to the end, thanks for reading this long post. Red Brick DBA (a.k.a. Pig in Mud)