September 11, 2009
Xkoto Gridscale highlights
I talked yesterday with cofounders Albert Lee and Ariff Kassam of Xkoto. Highlights included:
- Xkoto sells Gridscale, a clustering server for DB2 and, more recently, MS SQL Server.
- Xkoto Gridscale runs on a separate box, between the application and the database servers. This box is typically smaller and cheaper than the database server boxes.
- Xkoto most typically sells Gridscale into environments where there already are three database servers — one to do work, one for hot standby, and one for remote disaster recovery.
- In such environments, Gridscale’s big benefit is that you can distribute the query workload among all three servers. Xkoto believes this big performance increase is the reason customers don’t get much past 3 database servers under Xkoto (they didn’t seem quite sure as to whether the all-time record was 4 or 5). Note that even if a remote server is a little too far away for OLTP query response, it can work fine for reporting.
- Of course, if you don’t already have high/”continuous” availability and/or disaster recovery, then Xkoto would say those are core benefits of Gridscale as well.
- Gridscale sends transactions (or just SQL statements?) to all servers in the cluster. Once any of them responds affirmatively, that update is reflected in queries. Gridscale maintains a small query log to make sure it gets the other database copies in sync. It also tries to make sure that queries always go to the most current copy of the database. (I didn’t ask what happens if Server A executes Transaction T but not U, while Server B executes Transaction U and not T — but that does seem like something of an edge case.).
- Xkoto spun out of Halcyon Monitoring in 2006, starting with DB2 support. Microsoft SQL Server support was introduced in 2008.
- Xkoto likes its partnerships with IBM and Microsoft. For example, IBM provides Level 1 and 2 support for Gridscale itself. Due in large part to this partnership strategy, Xkoto says it has no plans to support DBMS beyond DB2 and SQL Server.
- Instead, Xkoto is pursuing partnerships with large application vendors and so on. (The figure “about 10” was mentioned.) I gather the idea is to make sure that neither the application support folks nor the app itself freak out from the fact that the app isn’t exactly talking to the DBMS any more.
- Xkoto has done lab tests suggesting Gridscale offers near-linear scalability (in terms of SQL Server database throughput) on a query-only workload up to 10 servers.
- I gather that Xkoto and IBM have demos suggesting it’s a fine idea to have your disaster recovery server be in the Amazon cloud, but they haven’t yet made any sales based on that — er, based on that premise. 😉
- Gridscale pricing is measured in the same metrics as DB2 or SQL Server pricing, and in each case is around 1/3 what database pricing would be on the same box (I’m guessing that’s for enterprise additions without add-ons, but I didn’t probe). Specifically, Gridscale charges $12K per 100 PVUs for the DB2 edition, and $12K per socket for running with Microsoft SQL Server.
- Gridscale typically runs on smaller boxes than the databases it talks to.
- Xkoto has about 35 revenue-recognized customers. Most are on DB2, the first environment Gridscale supported.
- Average Gridscale selling prices are $180K on DB2, and $40-50K in the early going for SQL Server.
- Xkoto has about 40 full-time employees, with engineering in Toronto and business operations in Waltham.
Categories: Clustering, IBM and DB2, Market share and customer counts, Microsoft and SQL*Server, Parallelization, Pricing, Xkoto
Subscribe to our complete feed!
Comments
15 Responses to “Xkoto Gridscale highlights”
Leave a Reply
Curt, so would this be like one of those “accelerator” sidekick products you once said you recommended against (namely for Dataupia and ParAccel back when they had one) as this layer seems to “emulate” DB2 and SQLServer? Thanks.
Not particularly. When you use Gridscale, the DBMS is still really DB2 or SQL Server.
And I don’t actively recommend against emulation. I just question how many enterprises find enough value in it to care.
Curt,
How do I recover the query log when the server running Xkoto fails? If it records SQL that has yet to be run on all servers, then I need to make that log highly available.
How does this guarantee that transactions have the same outcome between servers without serializing transaction execution (for all transactions, or for all that update the same table)?
Mark,
I didn’t push regarding how bulletproofed Xkoto itself is or isn’t. Between site outages and coughing, I didn’t drag the call out to the extent I usually do.
I was reviewing a start up proposal many years ago that had the idea of replicating SQL statements across nodes to create a scalable system. In general terms, replicating SQL statements seems like a good idea, on the surface. But there are non-deterministic functions that are commonly used in SQL Server database design. Like getdate() is often the default for a date column. With a bit of latency, different replicas would have different values. Also, NEWID() is commonly used to assign a default value to a GUID column. This generates a random GUID so regardless of timing each replica would have different values. Also, stored procedures are commonly used as an interface. Many developers push application logic down into the database so many stored procedures are read/write. This means in theory the whole stored procedure has to run on every node (which is bad if it does a 100,000 row range scan SELECT and then does a one row event table INSERT for example). So it turned out, unless you really architect and develop with this in mind you could end up replicating much of your existing load as you scale. And combined with the point that DBAs can do something similar with transactional replication (updating subscribers) or merge replication and avoid most of these issues, this particular proposal proved a non-starter.
If Xkoto are following this thread I would be interested if any of the above issues are relevant to them, and if so if they have workarounds/solutions for these sorts of problems. To be clear, I no idea if these sorts of issues are a problem or not for Xkoto. But based on what I read here http://www.availabilitydigest.com/public_articles/0307/xkoto.pdf I am curious as to how they avoid these stuff.
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.
>>>
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.
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
@Robert,
Nope. Haven’t heard from them quite a while. Tweeting PR guy Mel Webster to ask.
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…
Indeed the sale of XKoto to Teradata is true, and yes, what a shame. Rick, I totally agree with you.
Hi Curt, Will you comment on Teradata’s acquisition of xkoto?
Teradata said they’d brief me, then refused, then probably forgot about it after changing direction again as to how much they’d disclose.
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.
[…] is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be […]