<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Xtreme Data readies a different kind of FPGA-based data warehouse appliance</title>
	<atom:link href="http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/</link>
	<description>Choices in data management and analysis</description>
	<lastBuildDate>Thu, 09 Feb 2012 21:52:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
	<item>
		<title>By: Justin Swanhart</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128365</link>
		<dc:creator>Justin Swanhart</dc:creator>
		<pubDate>Wed, 01 Jul 2009 17:23:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128365</guid>
		<description>The big difference between the MPP column stores and Kickfire is the price/performance ratio.  If you look at the benchmarks you will see that Kickfire provides great performance in a small form factor for a lot less money.  If benchmarks are good at only one thing, gauging price/performance is probably it.  The SQL chip allows us to literally do more with less.

But beyond that, Kickfire decided to go in a different direction from the other guys.  In order to get performance at very large data volumes, there are tradeoffs.  MPP databases often don&#039;t feature UNIQUE keys, FOREIGN KEY constraints and other indexes which can be very useful.  

There are technical challenges to implementing such keys in a MPP system, since the constraints must be maintained across the entire cluster.  When you have volumes of data in the tens of terabytes or higher, it makes sense to go with ETL instead.

Big companies with vast amounts of time and money will be happy to invest in an ETL process to accompany their new multi-TB warehouse.  Smaller shops with less data are not so willing to spend effort and hard earned capital on such processes.

Small companies want fast results without spending a lot of money.  They might only have a hundred gigabytes of data, but they want answers on it now, and they don&#039;t want to spend a million dollars to get them.

There are a lot more small companies with tens or hundreds of gigabytes than there are large companies with tens or hundreds of terabytes.</description>
		<content:encoded><![CDATA[<p>The big difference between the MPP column stores and Kickfire is the price/performance ratio.  If you look at the benchmarks you will see that Kickfire provides great performance in a small form factor for a lot less money.  If benchmarks are good at only one thing, gauging price/performance is probably it.  The SQL chip allows us to literally do more with less.</p>
<p>But beyond that, Kickfire decided to go in a different direction from the other guys.  In order to get performance at very large data volumes, there are tradeoffs.  MPP databases often don&#8217;t feature UNIQUE keys, FOREIGN KEY constraints and other indexes which can be very useful.  </p>
<p>There are technical challenges to implementing such keys in a MPP system, since the constraints must be maintained across the entire cluster.  When you have volumes of data in the tens of terabytes or higher, it makes sense to go with ETL instead.</p>
<p>Big companies with vast amounts of time and money will be happy to invest in an ETL process to accompany their new multi-TB warehouse.  Smaller shops with less data are not so willing to spend effort and hard earned capital on such processes.</p>
<p>Small companies want fast results without spending a lot of money.  They might only have a hundred gigabytes of data, but they want answers on it now, and they don&#8217;t want to spend a million dollars to get them.</p>
<p>There are a lot more small companies with tens or hundreds of gigabytes than there are large companies with tens or hundreds of terabytes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hriyadesh Sharma</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128340</link>
		<dc:creator>Hriyadesh Sharma</dc:creator>
		<pubDate>Wed, 01 Jul 2009 13:11:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128340</guid>
		<description>Hi Justin,

Please help me understand the benefit of a SQL on Chip engine as comared to ParAccel and Vertica, who can provide stellar performance on any data volumes with SW only? They can also package it as an appliance with very small number of nodes to very large number of nodes.

Thanks</description>
		<content:encoded><![CDATA[<p>Hi Justin,</p>
<p>Please help me understand the benefit of a SQL on Chip engine as comared to ParAccel and Vertica, who can provide stellar performance on any data volumes with SW only? They can also package it as an appliance with very small number of nodes to very large number of nodes.</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Swanhart</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128234</link>
		<dc:creator>Justin Swanhart</dc:creator>
		<pubDate>Tue, 30 Jun 2009 23:45:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128234</guid>
		<description>Zman, 

It is a little unclear as to what the capabilities the &quot;Xtremedata&quot; box will actually have, given the partial stealth nature of Xtremedata.

Kickfire is selling a product today and is performing extremely well for our customers.  We feature a small form factor and we don&#039;t cosume a lot of power.  We can run queries in seconds that MySQL takes DAYS to process.

For example.  We have one customer who bought our appliance.  On their old MySQL servers, one of their most important queries ran for more than 4 DAYS.  Before engaging in a POC with Kickfire, they tried out Infobright.  They got pretty good results.  Their 4 day query ran in four hours.

In the Kickfire POC, this query ran in four minutes.  This very important query can now be run any time they want, it can be changed to look at patterns and it doesn&#039;t lock their database for hours or days at a time.

Kickfire has show proven real performance numbers on benchmarks like TPC-H(tm) and in customer POCs.  We&#039;ve proven our solution works.  We&#039;ll just have to wait and see if Xtremedata can match the very high bar which we have set.

Xtremedata claims to run the TPC-H(tm) queries, but they have not submitted audited results, and they aren&#039;t allowed to use the TPC-H(tm) name as far as I understand.

The architectural differences are &lt;del datetime=&quot;2009-06-30T23:57:02+00:00&quot;&gt;moribund&lt;/del&gt; manifold.  The Kickfire SQL chip is a true dataflow engine with patented in-memory compression and SQL execution technology.  Just having an FPGA doesn&#039;t mean you can run &quot;SQL on a chip&quot;.

These are my own opinions and I am not speaking directly for Kickfire.</description>
		<content:encoded><![CDATA[<p>Zman, </p>
<p>It is a little unclear as to what the capabilities the &#8220;Xtremedata&#8221; box will actually have, given the partial stealth nature of Xtremedata.</p>
<p>Kickfire is selling a product today and is performing extremely well for our customers.  We feature a small form factor and we don&#8217;t cosume a lot of power.  We can run queries in seconds that MySQL takes DAYS to process.</p>
<p>For example.  We have one customer who bought our appliance.  On their old MySQL servers, one of their most important queries ran for more than 4 DAYS.  Before engaging in a POC with Kickfire, they tried out Infobright.  They got pretty good results.  Their 4 day query ran in four hours.</p>
<p>In the Kickfire POC, this query ran in four minutes.  This very important query can now be run any time they want, it can be changed to look at patterns and it doesn&#8217;t lock their database for hours or days at a time.</p>
<p>Kickfire has show proven real performance numbers on benchmarks like TPC-H(tm) and in customer POCs.  We&#8217;ve proven our solution works.  We&#8217;ll just have to wait and see if Xtremedata can match the very high bar which we have set.</p>
<p>Xtremedata claims to run the TPC-H(tm) queries, but they have not submitted audited results, and they aren&#8217;t allowed to use the TPC-H(tm) name as far as I understand.</p>
<p>The architectural differences are <del datetime="2009-06-30T23:57:02+00:00">moribund</del> manifold.  The Kickfire SQL chip is a true dataflow engine with patented in-memory compression and SQL execution technology.  Just having an FPGA doesn&#8217;t mean you can run &#8220;SQL on a chip&#8221;.</p>
<p>These are my own opinions and I am not speaking directly for Kickfire.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128025</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Mon, 29 Jun 2009 20:35:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128025</guid>
		<description>Zman,

I&#039;m sorry, but I think any more detail would be covered by the embargo.</description>
		<content:encoded><![CDATA[<p>Zman,</p>
<p>I&#8217;m sorry, but I think any more detail would be covered by the embargo.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zman</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128014</link>
		<dc:creator>Zman</dc:creator>
		<pubDate>Mon, 29 Jun 2009 18:45:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128014</guid>
		<description>Can you provide any info on how this differs from Kickfire&#039;s SQL Chip? (NDA permitting)  Thanks!</description>
		<content:encoded><![CDATA[<p>Can you provide any info on how this differs from Kickfire&#8217;s SQL Chip? (NDA permitting)  Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patented SQL on a chip! &#171; EveryDay EssBase</title>
		<link>http://www.dbms2.com/2009/06/29/xtreme-data-readies-a-different-kind-of-fpga-based-data-warehouse-appliance/#comment-128000</link>
		<dc:creator>Patented SQL on a chip! &#171; EveryDay EssBase</dc:creator>
		<pubDate>Mon, 29 Jun 2009 17:48:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/?p=824#comment-128000</guid>
		<description>[...] Patented SQL on a&#160;chip!   Xtreme Data readies a different kind of FPGA-based data warehouse appliance  [...]</description>
		<content:encoded><![CDATA[<p>[...] Patented SQL on a&nbsp;chip!   Xtreme Data readies a different kind of FPGA-based data warehouse appliance  [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

