TransRelational(TM) — The final debunking
In prior posts, I’ve mentioned the essential dishonesty behind the hoohah around Transrelational(TM) technology from Required Technologies, Inc., and Chris Date’s highly regrettable promotion of same. Now I’ve been able to get more detail from another former executive of the company. Unsurprisingly, it corroborates what I wrote before, and utterly contradicts some of the myths spread by Date and his acolytes. This executive, while requesting that his name be withheld because of the acrimony between the CEO and just about every other company insider, otherwise gave me permission to report fully on what he told me.
1. While the company indeed started in New York, before it shut down in November/December 2002 it had moved to California. The reason was the availability of DBMS engineers. That makes sense.
2. The company had venture capital lined up to keep it going, but the deal fell apart due to “governance” issues. I.e., the investors wanted to bring in a new CEO and, as they always do, control the board. Rather than acceding to this common if annoying demand, the CEO shut the company down.
Incidentally, my contact says most of the developers went to Google, and most of the rest went to Yahoo.
3. The product never had a DML or DDL other than SQL. Any claims that it could implement a “true relational” language are speculative. Any claims that it already did implement such a language are utter falsehoods, unless a whole lot of secret development has been done (for which there was no money) without the shareholders being notified.
4. My contact insists that, for what it was, the product was ready for beta release when the company shut down. It was an analytics-oriented DBMS, definitely not designed for update-heavy applications. Indeed, he explicitly said that it was for “decision support, with batch loads into the database.”
5. In their tests, it outperformed Oracle on most queries. These tests seem to have been mainly performed on a database in the 100 gigabyte size range. It had better than a 10X advantage in storage space vs. a highly denormalized star-schema approach. However, claims of “orders of magnitude” performance improvements are utterly unfounded.
6. My contact viewed the TransRelational architecture as being memory-centric, but in the actual product they tried to marry concepts of TransRelational with efficient storage on disk. He gave two examples of the kinds of features they added. One is the ability to sort the data for efficient I/O. Another is to in certain cases reaggregrate the data. I don’t have further detail than that.
7. The core idea of how the product worked is that it stored, for each column, a unique list of the values, and also the frequency of their appearance. (Called “standard distribution values”). Fabian Pascal’s denial that this was a columnar data store is bullshit. It also stored lots of indices to reconstruct every possible record. Claims that there are no indices are bullshit. The overhead of reconstructing records in memory was negligible.
Bottom line: This was a very cleverly designed product, that might have made an impact in the market for data warehousing DBMS. But it is very far from what it is being promoted as being.
I’m sorry for the nasty tone of my posts on this subject, but this product has been consistently misrepresented. Those misrepresentations have been used by unpleasant people as hammers in flame wars, and they also seem to be the basis for separating unsuspecting seminar attendees from considerable amounts of money. A lot of time and effort has been spent debunking this BS, including by me. Any honest, knowledgeable person should have stopped promoting it years ago.
Comments
5 Responses to “TransRelational(TM) — The final debunking”
Leave a Reply
It had better than a 10X advantage in storage space vs. a highly denormalized star-schema approach. However, claims of “orders of magnitude” performance improvements are utterly unfounded.
Better than a 10X advantage would represent at least one order of magnitude.
Better than one order of magnitude in one measure vs. one alternative is not “orders of magnitude” improvements overall, and certainly not specifically in performance.
[…] Now that I’ve meandered for a while, let me mosey on back toward the question raised in Scoble’s post. What tests of credibility should we impose on bloggers in the area of (enterprise) technology? I think what Scoble proposes about sourcing, linking, etc. are way too restrictive, and in some cases even silly. One should never post anything unless one has a named, on-the-record source?? C’mon. Some of the best investigative reporting is based on anonymous sourcing, very carefully confirmed. (Here’s an example of me taking this route.) Indeed, sometimes a reviewer or analyst is able to come to an informed conclusion based solely on his or her own judgment or experience, without contacting anybody else to be told what to think. Analysis may overlap with journalism, but it’s not the same thing. […]
[…] they’re time series data stores rather than full RDBMS. Mike is less eager to talk about Required Technologies, a failed columnar RDBMS startup that he was involved in, and which is the pretext for (through no […]
[…] He lost credibility with me about two things. The first was his denial of SQL as an appropriate language to interact with relational database systems. He could have made a good point if he provided an alternative language that could and should replace SQL. The second thing was referencing this company called Required Technologies, Inc. in which he said this company built what’s called a Trans Relational Model. As Date said, this company built a relational system that claimed to have no DML or DDL, not to mention a CBO or joins. For some reason I felt like the only person in the room saying this guy is either senile or foolish. Well it turns out there are others who think the same as me. […]