Eye on Oracle

Sep 19 2007   9:34AM GMT

Oracle is “fundamentally flawed”

Ken Cline Profile: Clinek

I received some interesting comments about my post Is the Oracle DBMS a legacy technology? from Mich Talebzadeh, a London-based independent Sybase consultant. Let me know what you think . . . .

There is a convincing argument these days to classify Oracle’s approach to handling both OLTP and OLAP type load as fundamentally flawed.

The argument is not so much that relational database management systems like Oracle “should be considered legacy technology” since they are more than a quarter of century old, but more to do with the philosophy and the design approach that they were created for. Twenty five years ago, and even ten years ago, databases were far smaller, on the order of a few gigabytes in size. They were dealing with a smaller community of users that were equally adding and reading data. This was the era of the transactional base databases in which the user — for example, a trader – was only interested in his/her own portfolio. Adding a few trades and reading them with some aggregates was fine and within the capability of the old optimiser, relying purely on nested-loop, join, etc. At that time, most RDBMS engines, including Sybase and others, did not even bother implementing sort-merge joins, never mind the hash-joins.

Things have moved on since then. Today’s systems and users deal much more with non-transactional (read) activity than with transactional (write/update) activity. An average trader today is not only interested in his/her portfolio but also interested in other portfolios and analytics, which requires sifting through millions of lines of records.

If I were to design a new database engine today, I would gear it towards OLAP type rather than OLTP type. I would probably make the deign *column-based* as opposed to row-based. A column-oriented system is a database management system that stores its content by column rather than by row. This has advantages for databases that most read data, such as data warehouses, plus adds the convenience of data compression, as Sybase IQ does. My argument would be that in today’s read-hungry world, an average user will read far more than he/she writes.

Going back to the approach of Oracle, it is becoming increasingly clear than *one size/one philosophy* does not fit all. When it comes to OLTP applications, we know well that Oracle is slower compared to Sybase (or Microsoft SQL Server for that matter). On the other hand, its transactional and concurrency approach is better suited for large volume of data. However, what it cannot do (although it tries very hard) is to adapt the relational model, which Oracle (much like Sybase and Microsoft SQL server) is based on, to handle what a column-based system inherently does much better!

Does that mean that Oracle and for that matter Sybase and Microsoft SQL Server are legacy systems? I don’t think so. All it means is that there is a limit that and you can take the relational model only so far. The RDBMSs are perfectly OK for certain things. However, the column-based systems are good for heavy read, low volume, transactional activity.

So what is the solution in a business world that is growing increasingly distributed and has to deal with the increased use of heterogeneous systems and proprietary databases across different levels of business? I genuinely think that we need to deploy tools for the purpose and relying on one engine philosophy (say RDBMS) solution is no longer viable. The solution is not to bolt a Ferrari and a bus together and create an all purpose vehicle, but more to use a Ferrari and a bus where appropriate. Today’s technology perfectly allow us to use a good RDBMS system like Sybase ASE for transactional activity with a column-based system like Sybase IQ. For that matter, you can use Oracle as an RDBMS and bolt it to Sybase IQ, if that’s what you have to do.

Mich tells me that he drives a Ferrari.

18  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Clinek
    I’m fairly new to the IT “game” and I’ve heard a lot of talk of network automation as the time has passed. I’ve seen some resistance to automation but it’s usually from folks who aren’t as educated in IT as they should be. It was explained to me that through database automation a company can improve application availability for it’s clients and by making use of smart dba tools can really drive profits up. I’ve become a big support of data center automation over the last year or so mainly because by having the network take care of the smaller things we can focus on the company’s business software applications and delivering better service to our clients.
    0 pointsBadges:
    report
  • Clinek
    Right...an independent Sybase consultant is going to tell me Oracle is outdated. Seems fair. Of course independent and sybase constitute an oxymoron in this case. I'll wait for more information from a less biased "authority" before I make up my mind.
    0 pointsBadges:
    report
  • Clinek
    Yeh I know... the object based Db models worked so well that obviously Oracle is flawed.( anybody know what happened to that RDBMS slaying technology???) anyone???) Toy databases like MS-SQL and MYSQL will always do well in their spaces. For instance: MYSQL-- as long as it doesn't have to do any actual I/O or MS SQL if it doesn't have to any crash recovery.... But I invite someone to come up with a better "industrial quality' DB with out putting untold software engineering manhours -- over 25 years). Remember, USAF B-52's have been flying longer than most of their pilots have been alive -- are they same craft as they started out as -- I think not. Refits of the basic concept and maint of the airframe -- including 'high tech' add ons have made them more effective than ever. (just ask the rag head terrorists in afghnaistan-- if you can find one still alive...) Same with Oracle... Don't mess with it.
    0 pointsBadges:
    report
  • Clinek
    Well the market capture of Oracle compared to Sybase tells a different story :) May be Oracle's marketing is better and buyers are fools!!
    0 pointsBadges:
    report
  • Clinek
    Actually, "we" know that statements suggesting that one database is faster than another, should be taken with a pinch of salt when issued by a supporter of one vendor product, and that includes Oracle and Sybase...especially if they are unaccompanied by any supporting evidence. TPC-C results are not everything when it comes to OLTP performance, however, they are at least suggestive and it is interesting to note that Sybase doesn't even figure in the top ten, unlike Oracle: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp I am an Oracle consultant - therefore I am biased of course.
    0 pointsBadges:
    report
  • Clinek
    I would like to know where "we know well that Oracle is slower compared to Sybase (or Microsoft SQL Server for that matter)" comes from. I worked at a software house where we developed software for SQL Server, Sybase and Oracle and we struggled to scale applications on Sybase and SQL Server the same way we did on Oracle. Also "This has advantages for databases that most read data, such as data warehouses, plus adds the convenience of data compression, as Sybase IQ does" is somewhat outdated, the author should refer to advanced compression which is available with Oracle 11g. In short I found the article highly amusing if not based on any facts, in fact I can't remember ever reading a technical article posted on the internet that was so flawed and without any foundation based on reality whatsoever.
    0 pointsBadges:
    report
  • Clinek
    we know well that Oracle is slower compared to Sybase. I didn't know this was a well known fact, why are there no Sybase databases in the top ten TPC results ?
    0 pointsBadges:
    report
  • Clinek
    Some arguments defy reality, this is one that defies logic AND reality. The problem is not Oracle's 'row based' approach counterposed to a 'column based' approach. That nonsense was easily disposed of before relational databases (ever heard of multi dimensional tables?). The issue is also not 'transactional' v. 'non transactional', another red herring (all objects can be considered transactions). The real issue is one of which mechanism is best at getting to relevant information quickly. The issue is certainly not some posed alternative between the relational db model and the vague notion of an object model above. In this Oracle is far superior to certainly SQL Server and if measured scientifically Sybase. It is scaleable, and offers full partitioning and clustering at Enterprise level. However, it is the optimizer that is superior to the others. This is the mechanism that gets the data. The other factor in performance is database design and in this, the relational model applied correctly would beat this nonsense of a 'column-based' system. Try looking up 'normalization'.
    0 pointsBadges:
    report
  • Clinek
    1. Mike Stonebraker reinvented the "column based" database management system fairly recently. 2. I have used Oracle for data warehousing for more that 13 years, it does the job .. so what the issue, apart from cost? 3. I have worked in investment banking for more than twenty years, the last thing that banks want is traders seriously adopting copycat trading behaviours. If you know anything about trading you will know why. 4. Independent Sybase consultant? hahahaha ... Sybase is a good product .. but ...
    0 pointsBadges:
    report
  • "John
    Mich says, "If I were to design a new database engine today, I would gear it towards OLAP type rather than OLTP type. I would probably make the deign *column-based* as opposed to row-based." I like the "probably"! As if Mich has an entire Alladdin's cave of wonderful ideas to smash the RDBMS approach used by all the big players. Mich: 10 out of 10 for sheer gall, but 0 out of 10 for real-world value.
    0 pointsBadges:
    report
  • "John
    And as for this: "When it comes to OLTP applications, we know well that Oracle is slower compared to Sybase (or Microsoft SQL Server for that matter)" - leave it out, Mich!
    0 pointsBadges:
    report
  • Clinek
    A quick note for those questioning the "independence" of Mich, the author of the post: I've known Mich for years and I can assure you that he does NOT work for Sybase. Yes, he's a Sybase fan -- an evangelist, really -- but doesn't work for the company. He's a consultant and the author of a book on Sybase as well: "Sybase Transact SQL Programming Guidelines and Best Practices: A Practitioners Approach Through Example" He also has a book coming out soon that compares and contrasts Oracle and Sybase. Anyway, I just wanted to clear the air about that point. Cheers, Tim
    0 pointsBadges:
    report
  • Mich
    Tim, Thank you for your notes. Can I just clarify that I do work on Oracle equally as well and I am fond of it. It is natural to expect emotions to run high when religious arguments like databases come into it. This happens in both Oracle and Sybase forums so I have got used to it. However, the issue at stake is whether the traditional transactional base relational models like Oracle and Sybase can do as good a job compared to non traditional models like column based storage databases such as Sybase IQ, when it comes to read intensive activities. I have to emphasis here that both the designs that I mentioned are based on relational model (i.e. Codd's original ideas), just the way the data stored in different. It is becoming increasingly obvious that the traditional models have limitations in this arena. That is all. In summary you can only take the traditional RDBMSs so far in read intensive area.
    0 pointsBadges:
    report
  • Clinek
    I really think there is a confusion going on here. Where the word 'traditional' appears, there is a danger of it being used in a perjorative sense. Where the term 'relational database' is described as 'traditional' things get even worse. The relational model is a logical concept, endlessly flexible, and frankly superior to any other data model currently known to man. Now, the physical implementations of the relational model are an entirely different matter, and do indeed vary according to the various manufacturer offerings. Some are older than others, some implement the relatonal model better than others. But please - do not confuse old physical technology with a logical system that will outlast many of the current implementations.
    0 pointsBadges:
    report
  • Mich
    Hi Peter, Thank you for your clarification. I will pick up on your terminologies. As you correctly pointed the physical implementations of the relational model are an entirely different matter, and do indeed vary according to the various vendor's offerings. Some implement the relational model (objectively depending on your familiarity/attachment) better than others. I call Sybase ASE or Oracle a row based storage implementation (RBSI) of Relational Model (RM) and Sybase IQ a column based storage implementation (CBSI) of RM. Let me for focus on the back-end stuff, I believe a vendor like Sybase and I am sure Oracle as well has both technologies for both RBSI and CBSI in hand. To make RBSI and CBSI implementations work seamlessly is a challenge. Every vendor recognises the need to create an RBSI and CBSI solution. Clearly there is a need for a physical implementation that focuses on better retrieval of data for Read Intensive activities. To believe that one RBSI model of vendor has cracked it much better than the other ones is simply naive and at best a marketing ploy. I would envisage a scenario in the future where a vendor like Sybase will retain ASE but will incorporate column based storage implementation into it. That is probably the best way of taking this forward. Imagine one has the ability to create a table with row or columned based storage option: CREATE TABLE ... STORAGE With that in mind the challenge for the designers would be how to make the RBSI Execution Engine work in tandem with the CBSI Execution engine when joining a row based storage table with a column based storage table! I can see tremendous potential with partitioned tables as well. You could create the most active partition with row storage and the other partitions with column storage and thus compressed, resulting in considerable saving of space. The potential is infinite and so is the challenge. I am sure the technology is achievable.
    0 pointsBadges:
    report
  • Clinek
    Intesting stuff, Mich. I quite take your point. As far as storage is concerned, there would appear to be little or no limit on that currently! I don't know a lot about it, but if memory serves me correctly, the Trans-Relational model is an attempt to go down the CBSI route, but with such performance advantages that the RBSI becomes redundant. Further, it would claim to be able to implement physically much closer to the opriginal logical relational model. We are still awaiting its appearance, however.
    0 pointsBadges:
    report
  • Mich
    Thank you for your insight Peter. I discussed the issue of RBSI and CBSI implementation with some engineers. These are further practical views. First, we know that Row Based Storage is very effective for OLTP applications. Want to kill Column Based Storage sometime, just do a select * on your typical 60+ column trading table (using a where clause to say fetch 1,000 rows). We all know ways of killing Row Based Storage. I am not trying to knock either, but each are firmly entrenched at opposite ends of the spectrum. Again it does not meant that the thought of putting them together is not attractive - everyone can see some of the advantages here.....having flying cars or even flying Ferraris would be a great way to relieve congestion too - and the technology exists today, but it has to be tempered with a bit of reality in what is practical today, given the economics and infrastructure....which brings up the second point. Arguably, however, the idea of merging the two in a single instance suggests that "One Size Could Fit All" - which is an argument that ignores operational environmental considerations Secondly, the complexity of (effectively) putting the Sybase IQ style access methods (CBSI) let alone optimization (i.e. costing a CBSI query is different from costing a RBSI query), index maintenance (IQ penalizes loads to maintain stats and focuses more on bulk loads as a result - picture the overhead of an OLTP system that is forced to maintain stats on certain tables at insert time)....not saying all this *could not* be done - but it would be a complete top to bottom re-write of say RBSI such as ASE or Oracle that would effectively kill? any other project (RAC, SDC, etc.) as well as most other RBSI enhancements for multiple years. That is the practical/infrastructure problem that the engineers point out. The current way forward is to have both engines working as separate entities. If you think about it, this is not too different from what MySQL tried to do - they separated storage logic from query logic and allowed you to pick the storage engine. The *current* direction for Sybase as I know is a twist on that - allow multiple query engines to access multiple storage engines - whether that is a federated ASE -> ASE or a OLTP/DSS ASE -> Sybase IQ (and in reverse)
    0 pointsBadges:
    report
  • Clinek
    So, why wasn't this article entitled, "RDBMS' technology is fundamentally flawed"? SybaseIQ is a niche product - it certainly has a lot of great features, and is fast, without doubt, but it is niche. As for the demise of OLTP, you have to wonder what is driving the explosion in the growth in database sizes if OLTP were dead. How are OLAP systems populated? Interested to see that, if it were you designing an RDBMS, your design would incorporate one already designed - shows foresight!
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: