Lance |
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.
Chris |
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.
BJ Lachance |
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.
Anand |
Well the market capture of Oracle compared to Sybase tells a different story 
May be Oracle’s marketing is better and buyers are fools!!
Jeff Moss |
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.
Chris |
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.
Dallas |
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 ?
A Craven |
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’.
Martyn Richard Jones |
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 …
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.
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!
Tim DiChiara |
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
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.
Peter Robson |
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.
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.
Peter Robson |
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.
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)
Andrew |
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!
Managing an Oracle shop, Oracle database administration
Comment
RSS Feed
Email a friend
