• Tom Foremski outlined the dire (at least in theory) privacy risks of geolocation services, going into a lot more detail on that point than I ever have. However, he topped that off with the odd claim that people pay toll (rather than using an electronic service) to cross the Bay Bridge because they fear being tracked, rather than for reasons of time or money.
• Oracle had an earnings conference call. Larry Dignan did a good job of covering the highlights; the gory details are on the Seeking Alpha transcript, especially pp. 3-5.  Oracle now claims to be getting lots of multi-system deals for Exadata. (But I still haven’t seen much in the way of production customers named.) ULAs, which I presume are Unlimited License Agreements, are important on the software side. Besides picking on IBM and SAP, Oracle even touted a competitive win vs. EMC, which not coincidentally seems to be working on partnering with almost every Oracle competitor it can find.
• Brian Prentice of Gartner basically accused open source of being Dotcom 2.0, in terms of dubious business models and the hype associated with same. I agree with many of his particulars, and indeed often steer vendor clients away from open source strategies. For marketing purposes, I do feel that sometimes free can be a real cool price; but open source is not the only way to be free.
• Akiban, which I wrote about a couple of days ago, seems to be building out its website. As of this writing the website is still pretty raw, with bewildering messaging, carelessly repeated paragraphs, and a notable lack of clues as to who’s in company leadership. Even so — unless I missed some of the current stuff before, the site has come a long way in a few days, so maybe there’s hope.
• Groovy Corporation, which introduced the Groovy SQL Switch just last summer, seems to be doing something different now. It’s merged into a company called uCirrus (where the u is really a mu), but uCirrus doesn’t have a meaningful website yet, whereas Groovy does. There’s stuff there about a “push data cloud,” stressing the importance of not being a DBMS, under the name Cortex, whatever that all means. Groovy seems to have an online gaming deal for Cortex with MySpace, or maybe Cortex is just the name of a specific Groovy/MySpace project.
• Mike Mooney offered a long rant on the problems with database (design) version control. He did concede that the most recent Microsoft Visual Studio might help, for those who are bought into (and can afford) the Microsoft stack. Frankly, I think that’s what views are for, updatable or otherwise. In many cases, they’ll let you build what you need, quickly and without breaking anything, and you can leave it to the DBAs to sort out database performance later.
• I just discovered Chad Stewart’s programming blog. While he’s evidently a game programmer, a lot of his comments have broader applicability.
• Chip Hazard offered a VC’s perspectives on the difficulties facing enterprise IT startups. (Hat tip to Miriam Tuerk for turning me on to him.) Although he didn’t phrase it this way, his bottom line (at least the part I agree with) is that the startup’s products have to be amazingly superior to the alternatives (big vendors or in-house).

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

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