Comments on: Xkoto Gridscale highlights

By: Teradata, Xkoto Gridscale (RIP), and active-active clustering | DBMS2 -- DataBase Management System Services

Sat, 31 Jul 2010 08:24:00 +0000

[...] is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be [...]

By: Stephen Sun

Stephen Sun — Tue, 20 Jul 2010 10:53:46 +0000

IBM is now focusing on its own product, pureScale. And I believe IBM will finally grow up pureScale to have similar capability as GridScale, that is, not only a HA solution, but also includes DR.

By: Curt Monash

Curt Monash — Mon, 19 Jul 2010 04:07:33 +0000

Teradata said they’d brief me, then refused, then probably forgot about it after changing direction again as to how much they’d disclose.

By: Yunfeng Sun

Yunfeng Sun — Mon, 19 Jul 2010 01:51:28 +0000

Hi Curt, Will you comment on Teradata’s acquisition of xkoto?

By: Anton

Anton — Mon, 17 May 2010 14:19:21 +0000

Indeed the sale of XKoto to Teradata is true, and yes, what a shame. Rick, I totally agree with you.

By: Rick

Rick — Thu, 13 May 2010 04:30:19 +0000

I just heard that Xkoto sold out to Teradata, and that Teradata will no longer support the product. If this is true, what a shame! I was very excited for this product as it gave DB2 an edge over Oracle in the long distance HA department.

And shame on IBM for not buying them first! They will be regretting that slip…

By: Curt Monash

Curt Monash — Thu, 13 May 2010 03:55:02 +0000

@Robert,

Nope. Haven’t heard from them quite a while. Tweeting PR guy Mel Webster to ask.

By: Robert Wagner

Robert Wagner — Thu, 13 May 2010 03:38:52 +0000

Hi Curt,

Do you have any news on xkoto? Their website doesn’t have any recent postings, and some material has been taken down (e.g. Management Team).

Thanks

By: Ariff Kassam

Ariff Kassam — Mon, 14 Sep 2009 17:01:33 +0000

Curt, thanks for spending time with us on the phone last week. We appreciate your interest in what is happening at xkoto and GRIDSCALE. To answer some of the questions in the article and in the comments:

1) Our customers find that the main benefits of GRIDSCALE to be a) continuous availability (the ability to have the application online during planned and unplanned outages) b) horizontal scalability for mostly read applications c) having a functional DR database.

2) We replicate at the SQL statement level. That is, we send all SQL writes (DML and DDL) to all database servers in the cluster.

3) I wouldn’t say that we’ll never support another database platform. We’re currently talking to our customers to see what other features or database platforms they would like added or supported by GRIDSCALE.

4) We cluster the GRIDSCALE servers for availability using our own clustering mechanisms. The Recovery Log is replicated between the GRIDSCALE servers.

5) For non-deterministic functions: a) if the non-deterministic function call flows through GRIDSCALE, it will automatically replace the call with a deterministic value set by the GRIDSCALE server before the SQL is sent to all the database servers. b) if the non-deterministic function happens in the database (e.g. SP, trigger, etc.) we provide functions that can be used in place of the default functions to provide the same functionality but consistent values across the database servers.

There are a number of debates on the benefits/disadvantages of placing application logic within the database. With GRIDSCALE, the scalability benefits are from being able to load balance queries. If the application is simply executing SPs which do both reads and writes, the scalability benefits will be limited. However, a lot of our customers feel that the scalability benefits are secondary. The availability benefits are the priority. Since GRIDSCALE operates at the SQL level, we allow customers to perform database maintenance, version migrations, etc. without application outages.

The main differences between GRIDSCALE and transaction/merge replication is that GRIDSCALE provides consistent read access across all the database servers and it is easier to setup/manage.

6) To guarantee order of updates across the servers, write statements are serialized based on primary (or unique columns) access.

By: Mark Callaghan

Mark Callaghan — Sun, 13 Sep 2009 16:38:07 +0000

Thanks for the PDF. This statement makes me think that write transactions are not run concurrently:
>>>
Each read or write request is sent with an appropriate lock and a sequence number. The
sequence numbers guarantee that all operations are performed by each database server in
exactly the same order.
>>>