<?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 for Clustrix</title>
	<atom:link href="http://www.clustrix.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.clustrix.com</link>
	<description>Clustrix - Clustered Database Systems</description>
	<lastBuildDate>Tue, 24 Aug 2010 22:51:56 +0000</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Surprising Advice For Startups by th</title>
		<link>http://www.clustrix.com/blog/2010/06/25/surprising-advice-for-startups/comment-page-1/#comment-73</link>
		<dc:creator>th</dc:creator>
		<pubDate>Tue, 24 Aug 2010 22:51:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.clustrix.com/?p=426#comment-73</guid>
		<description>Aaron,

While a lot of startups do follow your thinking on coding the core idea/next minimum piece of functionality, and then rewrite frequently as needed, one could equally stress the need for not forgetting core software engineering practices of documentation, diagnostics, and the need for a long term architectural roadmap. 

Indeed, the more small companies that work out the long term product risk, engineering cost, and complexity of scaling out a reliable online service, the more your solution will make sense. 

I think you are one of the few startups out there building complex core technology, and wish you all the best. I for one will be checking out your Careers page for server developers in first quarter 2011!</description>
		<content:encoded><![CDATA[<p>Aaron,</p>
<p>While a lot of startups do follow your thinking on coding the core idea/next minimum piece of functionality, and then rewrite frequently as needed, one could equally stress the need for not forgetting core software engineering practices of documentation, diagnostics, and the need for a long term architectural roadmap. </p>
<p>Indeed, the more small companies that work out the long term product risk, engineering cost, and complexity of scaling out a reliable online service, the more your solution will make sense. </p>
<p>I think you are one of the few startups out there building complex core technology, and wish you all the best. I for one will be checking out your Careers page for server developers in first quarter 2011!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Not All Clusters Are the Same by Peter Godman</title>
		<link>http://www.clustrix.com/blog/2010/04/29/not-all-clusters-are-the-same/comment-page-1/#comment-60</link>
		<dc:creator>Peter Godman</dc:creator>
		<pubDate>Tue, 27 Jul 2010 23:14:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.clustrix.com/?p=249#comment-60</guid>
		<description>How would you compare this approach to other &quot;bring the code to the data&quot; approaches, like MapReduce?  Unlike a filesystem, a database likely never passes on most of the data it processes to the user (as in SELECT COUNT * FROM mytable)!  It totally seems like the right way to go.  Code is light, and data is heavy.  One doesn&#039;t bring the supermarket to one&#039;s shopping bag, eh?</description>
		<content:encoded><![CDATA[<p>How would you compare this approach to other &#8220;bring the code to the data&#8221; approaches, like MapReduce?  Unlike a filesystem, a database likely never passes on most of the data it processes to the user (as in SELECT COUNT * FROM mytable)!  It totally seems like the right way to go.  Code is light, and data is heavy.  One doesn&#8217;t bring the supermarket to one&#8217;s shopping bag, eh?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Surprising Advice For Startups by Peter Godman</title>
		<link>http://www.clustrix.com/blog/2010/06/25/surprising-advice-for-startups/comment-page-1/#comment-59</link>
		<dc:creator>Peter Godman</dc:creator>
		<pubDate>Tue, 27 Jul 2010 23:10:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.clustrix.com/?p=426#comment-59</guid>
		<description>Great points Aaron.  I&#039;m right there with you about being disheartened at the NoSQL movement.  It seems like the retaliation is really about weak and unscalable implementations or behemoth vendors rather than about the fundamental properties of SQL.  Like getting pissed off about your car breaking down and declaring war on four-wheeled vehicles.

It is interesting, though, that most of the great properties of the relational model, like transactionality, expressive support for aggregates, single point of query, and consistency are undermined as soon as you have to split your data across separate monolithic databases.  I can easily imagine that for a lot of those panelists, by the time they&#039;d started with a MySQL database and then dealt with all the headaches accompanying trying to provide for all those great relational properties after leaving the single-instance nest, they&#039;d feel some ill-will toward the fundamental relational properties that they presumably see as impractical in web-scale applications.

If you were to enumerate the properties (virtues or flaws) of an RDBMS, like natural language, ACID properties, aggregates, efficient, consistent query, single point of query, built-in replication etc. et. al., can you tell us where you think that traditional RDBMSs failed these panelists, and how Clustrix approaches things differently?  Were there any SQL products that could have made the experience less painful?  Do you think that there was a better experience available to them using some existing technology?

You also mention &quot;SQL&quot; a lot in your posts.  Am I to take it that you&#039;re referring to all relational databases?  Or just ones that use SQL the language?</description>
		<content:encoded><![CDATA[<p>Great points Aaron.  I&#8217;m right there with you about being disheartened at the NoSQL movement.  It seems like the retaliation is really about weak and unscalable implementations or behemoth vendors rather than about the fundamental properties of SQL.  Like getting pissed off about your car breaking down and declaring war on four-wheeled vehicles.</p>
<p>It is interesting, though, that most of the great properties of the relational model, like transactionality, expressive support for aggregates, single point of query, and consistency are undermined as soon as you have to split your data across separate monolithic databases.  I can easily imagine that for a lot of those panelists, by the time they&#8217;d started with a MySQL database and then dealt with all the headaches accompanying trying to provide for all those great relational properties after leaving the single-instance nest, they&#8217;d feel some ill-will toward the fundamental relational properties that they presumably see as impractical in web-scale applications.</p>
<p>If you were to enumerate the properties (virtues or flaws) of an RDBMS, like natural language, ACID properties, aggregates, efficient, consistent query, single point of query, built-in replication etc. et. al., can you tell us where you think that traditional RDBMSs failed these panelists, and how Clustrix approaches things differently?  Were there any SQL products that could have made the experience less painful?  Do you think that there was a better experience available to them using some existing technology?</p>
<p>You also mention &#8220;SQL&#8221; a lot in your posts.  Am I to take it that you&#8217;re referring to all relational databases?  Or just ones that use SQL the language?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How Clustrix was born by Jake Maizel</title>
		<link>http://www.clustrix.com/blog/2010/04/15/how-clustrix-was-born/comment-page-1/#comment-5</link>
		<dc:creator>Jake Maizel</dc:creator>
		<pubDate>Tue, 04 May 2010 05:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.clustrix.com/?p=4#comment-5</guid>
		<description>Nice one Paul.  Things are looking great.  Very exciting.</description>
		<content:encoded><![CDATA[<p>Nice one Paul.  Things are looking great.  Very exciting.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
