• 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.

To understand Sybase’s plans for Aleri and CEP, it helps to understand Sybase’s current CEP-oriented offering, Sybase RAP. So far as I can tell, Sybase RAP has to date only been sold in the form of Sybase RAP: The Trading Edition. In that guise, Sybase RAP has been sold to >40 outfits since its May, 2008 launch, mainly big names in the investment banking and stock exchange sectors. If I understood correctly, the next target market for Sybase RAP is telcos, for real-time network tuning and management.

In addition to any domain-specific applications, Sybase RAP has three layers:

• CEP (Complex Event Processing). Sybase RAP CEP is based on a version of the Coral8 engine Sybase licensed and has been subsequently developing.
• In-memory DBMS. Sybase’s IMDB is part of (but I guess separable from) and has the same API as Sybase’s OLTP DBMS Adaptive Server Enterprise (ASE, aka Sybase Classic).
• Sybase IQ. Actually, Sybase used the phrase “based on Sybase IQ,” but I’m guessing it’s just Sybase IQ.

In theory, there could be a DBMS other than Sybase IQ, such as Sybase ASE or even Oracle, because Sybase IMDB can talk to a variety of DBMS. I didn’t get the impression, however, that in practice there were any Sybase RAP installations whose persistent DBMS was anything other than Sybase IQ.

Aleri had all along had something called Project Ohio, to merge Coral8 with Aleri Classic. Now Sybase’s own CEP engineering team is being added to the mix, schedules are being reconsidered and haven’t been disclosed yet. (If one woman can produce one baby in nine months, how long does it take nine women to produce a baby?) Apparently Sybase has a dozen programmers in the CEP area, plus ~20 more on Sybase RAP, not counting QA, documentation, etc.; that represents a significant bump to the overall Aleri development team.

Sybase doesn’t seem to have decided what to do yet with the various business intelligence/real-time OLAP engine products and technologies it is inheriting from Aleri.

And finally, some metrics:

• The Sybase/Aleri guys estimate that 1/3 of of Aleri’s customers and even less of its revenue came from outside the financial services sector. They did say the non-financial-services business was “starting to pick up,” but not very convincingly.
• Sybase IQ is now up to >1800 customers, with >200 new ones in 2009.
• Sybase IQ indeed has users taking in market feeds up to 3 terabytes a day, so it probably matches Vertica in having at least several-hundred-terabyte databases in the financial sector.

*While a few use cases are exceptions, being “better than MySQL” for a DBMS is basically like being “better than Pabst Blue Ribbon” for a beer. Unless price is your top consideration, why are you even making the comparison?

Even worse, the press release, from its subhead and very first sentence, emphasizes the claim “the Groovy SQL Switch’s ability to significantly outperform relational databases.” As CEO Joe Ward quickly agreed by email, that’s not accurate.  As you would expect from the “SQL” in its name, the Groovy SQL Switch is just as relational as the products it’s being contrasted to.  Unfortunately for Joe, who I gather aspires to edit it to say something more sensible, the press release is out already in multiple places.

More favorably, Renee Blodgett has a short, laudatory post about Groovy, with some kind of embedded video.

My client actually signed a deal for EnterpriseDB’s Postgres Plus Advanced Server and GridSQL, but unwound the transaction quickly. (They say EnterpriseDB was very gracious about the reversal.) There seem to have been two main reasons for the flip-flop.  First, it seems that EnterpriseDB’s version of Postgres isn’t up to PostgreSQL’s 8.4 feature set yet, although EnterpriseDB’s timetable for catching up might have tolerable. But GridSQL apparently is further behind yet, with no timetable for up-to-date PostgreSQL compatibility.  That was the dealbreaker.

The current base-case plan is to use generic open source PostgreSQL, with scale-out achieved via hand sharding, Hibernate, or … ??? Experience and thoughts along those lines would be much appreciated.

Another option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch.  But this client’s database is terabyte-scale, so hardware costs could be an issue, as of course could be product maturity.

By the way, a large fraction of these updates will be actual changes, as opposed to new records, in case that matters.  I expect that the schema being updated will be very simple — i.e., clearly simpler than in a classic order entry scenario.

• The Groovy SQL Switch is a memory-centric OLTP DBMS.
• More precisely, a Groovy SQL Switch database is managed in-memory, and is also persisted to disk. (I haven’t talked yet with a Groovy Corp technical person, and hence don’t know about data access methods or other technical particulars beyond that.)
• The Groovy SQL Switch is initially being introduced as an appliance, but will quickly be sold software-only as well.
• The Groovy SQL Switch runs only on Intel XEON processors.
• The Groovy SQL Switch is fully ACID-compliant.
• Groovy positions its SQL Switch both as a freestanding DBMS and, alternatively, as a companion to incumbent DBMS such as MySQL.
• Groovy strongly positions the Groovy SQL Switch as being for “real time” applications.
• Groovy claims SQL Switch has implemented “most” of SQL-92. SQL-99 and stored procedures are SQL Switch futures.
• Other than through speed, Groovy supports its “real time” claim with a publish/subscribe-like capability for continual updating of SQL Switch result sets, via a SQL extension called SELECT FUTURE. I don’t know how this compares with CEP (Complex Event Processing) vendors’ implementations of similar functionality …
• … but of course Groovy believes that the Groovy SQL Switch is much easier to use and implement than a CEP/DBMS combination.
• ETL, administrative, development, and so on tools for the Groovy SQL Switch are being developed by a couple of third parties, one of which is Persistent Systems.
• As you can see from Groovy Corp’s home page, Groovy is planning to announce an OLTP benchmark result for the Groovy SQL Switch on July 30. You can imagine how excited I am by that.
• Groovy boasts 2 sales to date, both in the Far East — a Singapore bank and an Indian telecom gaming company. (Groovy Corporation got its start in Australia.) I forgot to ask whether the buyers were in production yet.

One obvious concern about Groovy’s approach is RAM cost. If you’re interested in the Groovy SQL Switch, you probably have a large transaction volume, in which case you probably also have a fast-growing database. Absent some kind of manual partitioning, the Groovy SQL Switch currently requires you to have enough RAM to hold that in its entirety. The same comment, of course, is probably true about VoltDB.

]]> http://www.dbms2.com/2009/07/28/the-groovy-sql-switch/feed/ 2 http://www.dbms2.com/2009/07/11/groovy-corp/ http://www.dbms2.com/2009/07/11/groovy-corp/#comments Sat, 11 Jul 2009 21:34:43 +0000 Curt Monash http://www.dbms2.com/?p=840 Groovy Corp sent over a press release and apparently suggested I write about the company’s wonderfulness immediately. This was without any kind of briefing. I don’t do that kind of thing.

However, a Twitter check revealed that Tony Bain is familiar with Groovy Corp and the Groovy SQL Switch (apparently they started out in Australia, where he lives and works, and he evidently knows the guys).  Tony’s take, in summary, is (emphasis mine):

They are an in memory RDBMS

They have worked with Intel to architect from the ground up for large multi processor concurrency

Initially they are launching as a multi-core appliance

They claim 200,000 sql operations per second from a single box

They are proprietary (not built on MySQL or any other open source database) which means they have had a lot of control around their architecture

They are a pretty cool company with some interesting people

There’s a little more detail at the above link.

*Thanks to Dave Kellogg for tipping me off to Plattner’s paper. I only went to two SIGMOD sessions, neither of which was Plattner’s. Nobody actually mentioned Plattner’s talk to me when I was down at SIGMOD.

Perhaps the most interesting part is Plattner’s claim that what’s demanding about OLTP isn’t database updating per se, but rather maintaining aggregates for quick-response analytics. In his main example of that point, Plattner proposes a real-life “more than 18″ table schema, of which 2 are base tables, and (most of?) the rest are materialized views that his proposed database architecture dispenses with (because analytic performance is sufficiently good without them). Thus, Plattner’s core columnar argument seemingly is

columnar –> natively fast analytics –> no need to maintain aggregates –> much lower update burden.

That said — if Plattner’s paper contained a clear statement of how much more expensive it is to insert or update a single row in a columnar vs. row-based system, I overlooked it. Instead, Plattner seems to be arguing that the volume of base-table updates is low enough that — whatever it may be — column-store update overhead is an acceptable price to pay.  (At one point he claims that only 5% of the data inserted in a financial application ever gets changed.) That may actually be true in a financial accounting system, but seems more questionable in a sufficiently large application that gets its updates from automatic devices, or from the consumer web.

Other highlights include:

• Like most modern observers, Plattner believes Postgres-style timestamping beats update-in-place.
• Plattner also offers a less common reason for liking timestamped inserts over updates-in-place — he thinks timestamps are helpful in planning-oriented applications. In particular, he wants timestamp-aware SQL extensions.
• Plattner claims columnar designs have a 10:1 compression advantage over row stores — specifically 20X vs. 2X — at least using compression schemes that allow for updating at reasonable speed. That seems exaggerated.
• Plattner seemed to drop various references to memory-centric structures SAP already uses. (SAP has long done a lot in-memory, in both the OLTP and planning areas. Years ago SAP told me of a customer that was buying >1 TB of RAM just to run SAP’s planning software. SAP also bragged that >99% of transactions never hit disk, in some sense of “transaction”. )
• There are lots of references to “tenants”, SaaS, and/or SAP’s SaaS product line. So SaaS is evidently a design point. That makes sense. First, SaaS is one of SAP’s biggest vulnerabilities. Second, the toughest customization a SaaS customer might want is to add a few columns to standard tables, which might be easier to accomodate with a columnar approach.

But I think I’ll at least say that the H-Store project is now named VoltDB.  The VoltDB website names two individuals — Mike Stonebraker and Andy Palmer — both of whom are founders of Vertica. Job listings on the site are for field engineer and trainer, but not developer, so that suggests something about the project’s/product’s maturity level.

If you have an extreme OLTP need, you should talk to VoltDB. If you don’t have access to Mike or Andy directly, I can hook you up with a key VoltDB marketing/outreach guy. Price may not be as much of a barrier as you’d initially fear.

If anybody from VoltDB wants to be less cloak-and-daggery and say more in the comment thread, I’d be pleased.

And yes — an open-secret working name for H-Store/VoltDB was, for a while, “Horizontica.”

One interesting thing on that blog is a taxonomy of caches — Level 1 cache, Level 2 cache, RAM, disk, etc., with some approximate figures for lookup times.  Edit: However, Kevin Closson emailed me to say it’s way out of date. Stay tuned to his blog for more on the subject.