February 25, 2010
Notes on Sybase Adaptive Server Enterprise
It had been a very long time since I was remotely up to speed on Sybase’s main OLTP DBMS, Adaptive Server Enterprise (ASE). Raj Rathee, however, was kind enough to fill me in a few days ago. Highlights of our chat included:
- One of the most confusing things about Sybase ASE is its version numbering. In particular,
- Sybase ASE 15.5 went GA in December, 2009. (But the clustered version is just coming out in March.)
- The prior version of Sybase ASE was 15.03.
- Sybase ASE 15.0 came out in September, 2005.
- The version of Sybase ASE before that was 12.5.
- And by the way, Sybase System 10 came out in 1994 or so.
- Sybase ASE 15.0 was a major rewrite. In particular, Sybase ASE 15.0 had a “brand new” optimizer and query processing engine, based on the Volcano model. The main driver of the rewrite was to make Sybase ASE suitable for mixing OLTP and some level of decision-support workloads. (Not on the order of what Sybase IQ can handle, but at least operational reporting and so on.)
- I haven’t looked up Volcano in more detail than to confirm that what I thought Raj said made sense, but as he characterized it, it’s a lot more modular than what Sybase had in ASE 12.5. For example, substantially the only join algorithm in Sybase ASE 12.5 was nested loop – no hash or sort/merge.
- As you might imagine, a lot of things one might regard as core modern DBMS features were only added to Sybase ASE once 15.0 came out. Examples include:
- Various forms of partitioning at the storage level.
- User-defined functions (UDFs).
- A clustering offering that competes with Oracle RAC. (100 or so customers are on that so far.) Absent clustering, Sybase ASE is limited to a single SMP (Symmetric Multiprocessing) box.
- Shared disk. Amazingly, it seems that before 2008, every node in an SMP box running Sybase ASE had its own private partition (maybe not the right word) of data.
- In Sybase ASE, you have lots of databases managed by one database server. You can write SQL statements that span multiple databases, but they have to reference database names as well as table names.
- There are several ways to get data from one place to another in Sybase’s technology and nomenclature, specifically including Replication Server, Incremental Data Transfer, and “proxy tables.” (Other than the fact that Replication Server is a separate, chargeable product, I don’t really have these straight.) In addition, there’s a hand-coded one in Sybase RAP, which will get a planned 5-6X performance improvement later this year when it is replaced by Incremental Data Transfer.
And in what basically sounds like a very cool approach, Sybase ASE has a lot of memory-centric aspects. That said, Sybase’s in-memory ASE story is still incomplete (wait until the next release) and confused (I think in part because of what’s missing in the current release). Also, this is one area where the non-technical nature of the briefing got in my way. So here’s some of what I do and don’t know about Sybase’s memory-centric ASE strategy:
- Sybase lets you mix and match on-disk and in-memory databases under one instance of Sybase ASE. To a programmer, it all looks like ASE.
- I don’t know exactly what the limitations are on what you can do with in-memory databases, how you can use them in tandem with on-disk databases, etc.
- You can replicate data from disk to an in-memory Sybase ASE database today. (Hello caching, ala Oracle Times Ten or IBM DB2/solidDB.)
- Replicating from memory to disk is a near-term future capability. (So Sybase does not yet have a hybrid memory-centric story ala solidDB Classic.)
- I have no clue as to what kinds of in-memory data structures Sybase ASE uses.
Categories: Cache, In-memory DBMS, Memory-centric data management, Sybase
Subscribe to our complete feed!
Comments
One Response to “Notes on Sybase Adaptive Server Enterprise”
Leave a Reply
[…] IQ is not immune to Sybase’s confusing choices in version numbering. […]