Re: Sybase limitations

Mark Sigler (msigler@informix.com) wrote: [ stuff deleted ] : Having worked with all the major databases, I can give you a brief : overview of why Sybase doesn't scale well. : Sybase was the first vendor to use a mulit-threaded model, but it was : targeted to uni-processor systems prior to the availablity of SMP systems. : The basic problem is that the first process, Engine 0, handles the bulk : of the I/O which is the biggest bottleneck in RDBMS's. Engines 1-n handle : mostly network I/O or user connections. This results in a great deal of : context switching by the OS for Engine 0 and causes blocking. This is : readily evident if you use UNIX utilities to examine context switches. : Furthermore, the threads in Sybase are relatively heavy, thus thread creation : is expensive. Since Engine 0 is a bottleneck, the other engines diminish : in value as the number increases since they are so dependent on Engine 0 : for services. This results in scalability problems beyond 4-6 CPU's. : System 10 has a very similar architecture to v4.9 and did not address : these issues. There is a great deal of concern by the industry analysts : that System 11 will not resolve the problems as well, this is shared by : many users of System 10 that found out the hard way that it didn't live : up to the promises made by Sybase, resulting in the recent financial : diaster in which Sybase lost over 40% in stock values. : MicroSoft SQL-Server for NT has these problems as well since it is : based on the v4.x Sybase kernel. : Oracle has a similar probelm in that the architecture is heavy in ^^^^^^^^^^^^^^^ This is misleading. You imply that Oracle, like Sybase, cannot scale beyond 4-6 processors. Oracle scales linearly (at most things) to high tens of processors (and I suspect beyond, but have never tried it). Oracle's problem is that their scalability line is not as steep as yours (IMHO). On the other hand, until you get 8.0 out, you cannot scale to as many processors as Oracle. : multiple processes that block and context switch. Oracle is a : mulit-process, not multi-threaded architecture, that uses a multiplexing : scheme with a dispatcher. Oracle uses more system resources to accomplish : it's tasks resulting in less efficient use of the hardware resources. : On Very Large DataBases (VLDB) scalability is limited due to the lack : of data partitioning, which drastically reduces the amount of disk I/O, : again the most prevalent bottleneck. On the other hand, they can do parallel query on non-fragmented tables, unlike OnLine. Making PDQ work well requires more administrative effort than Oracle7 PQO. : Both vendors are trying to re-architect their products to match the : lightweight multi-threaded model that is core to the Infomix DSA : OnLine product. The MT model allows for the internal parallelism : that is winning rave reviews by the industry analysts. Coupled with : data partitioning to reduce disk I/O and you have a product that : scales from uni-processor to large numbers of SMP CPU's. : Note that DSA was developed in conjunction with Sequent, a pioneer : in large SMP UNIX systems. DSA uses the concept of "Virtual Processors" : that are UNIX processes that are individually specialized for RDBMS : functions such as CPU, network I/O (NIO), asynchronous I/O (AIO) : logging I/O (LIO) and so forth. Each VP executes threads for particular : tasks in a non-blocking fashion. This provides very efficient use of : hardware resources with minimal context switching. : The fundamental architectures of the RDBMS kernel are very important : to addressing scalablity and performance. : I hope that this sheds some light on the differences in the current : RDBMS products in the market. Obviously I have a bias, but the facts : remain and are evidenced by the performance or lack thereof in key : benchmarks such as the TPC-C which are critical for un-biased : assessment of RDBMS products. I have relatively limited experience of OnLine 7.1 compared to Oracle7 with PQO, but so far I find it impressive. I hope 8.0 works as well on MPP, where the architecture should provide *real* advantage. -- graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.