Roads ? - where we're going, we don't need roads ...
Teradata, Xkoto Gridscale (RIP), and active-active clustering | ORA600
ORA600 content Content RSS
Oracle ORA600 News RRSS Oracle News RSS
ORA600 blog Blog RSS
ORA600 blog Blog Atom

User login

Teradata, Xkoto Gridscale (RIP), and active-active clustering


Having gotten a number of questions about Teradata’s acquisition of Xkoto, I leaned on Teradata for an update, and eventually connected with Scott Gnau. Takeaways included:

  • Teradata is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be a good fit for Teradata. Teradata hopes and expects that existing Xkoto Gridscale customers won’t renew maintenance. (I’m not sure that they’ll even get the option to do so.)
  • The point of Teradata’s technology + engineers acquisition of Xkoto is to enhance Teradata’s active-active or multi-active data warehousing capabilities, which it has had in some form for several years.
  • In particular, Teradata wants to tie together different products in the Teradata product line. (Note: Those typically all run pretty much the same Teradata database management software, except insofar as they might be on different releases.)
  • Scott rattled off all the plausible areas of enhancement, with multiple phrasings – performance, manageability, ease of use, tools, features, etc.
  • Teradata plans to have one or two releases based on Xkoto technology in 2011.

Frankly, I’m disappointed at the struggles of clustering efforts such as Xkoto Gridscale or Continuent’s pre-Tungsten products, but if the DBMS vendors meet the same needs themselves, that’s OK too.

The logic behind active-active database implementations actually seems pretty compelling: 

  • You may well be keeping a second copy of your database for high availability/hot standby.
  • You might even be keeping a third copy for off-site disaster recovery.
  • In some cases, you might have reasons beyond disaster recovery to distribute a database around the world.
  • So why not allow queries to be run against all the copies?
  • And by the way, splitting the workload up a bit by kinds (e.g., long-running vs. short query) might let you optimize the implementation of each copy of the database. (This last point becomes even more important with the rise of solid-state memory.)

Analytic DBMS vendors pretty much all need to offer this. (Possible exception: If they have a data-mart-only positioning so extreme that customers will never care about any form of failover.) That said, I must confess to not having done a good job of tracking who does or doesn’t have which features in this area to date; informative comments to this post in that regard would be much appreciated!




Howto's
See DUDE primer for info

Get Support

Europe

Belgium :
Kurt Van Meerbeeck
ORA600 bvba
E-mail
dude@ora600.be
Cell : +32 495 580714

Denmark :
Henrik Bjerknæs Rasmussen
Service & Support Manager
Miracle AS
E-mail :
hra@miracleas.dk
Cell: +45 53 747 110


North America

USA :
Tim Gorman
Evdbt Inc
E-mail
tim@evdbt.com
Cell : +1 303 885 4526

USA :
Daniel Fink
OptimalDBA
E-mail
daniel.fink@optimaldba.com
Cell : +1 303 808 32 82

Canada :
Pythian
E-mail
dude@pythian.com
Contact


Latin America

Brazil :
HBtec
E-mail
dude@hbtec.com.br
Cell : +55 47 88497639
Contact


Africa

South Africa :
Kugendran Naidoo
NRG Consulting
E-mail
k@nrgc.co.za
Cell : +27 82 7799275


East Asia Pacific

Australia
Alex Gorbachev
Pythian Australia
E-mail
dude@pythian.com
Cell : +61 2 9844 5431