<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: Twitter&#8217;s Lead Architect Leaves</title>
	<atom:link href="http://www.lastpodcast.net/2008/04/23/twitters-lead-architect-leaves/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lastpodcast.net/2008/04/23/twitters-lead-architect-leaves/</link>
	<description>Opinionated Web 2.0 News and Commentary</description>
	<lastBuildDate>Tue, 16 Mar 2010 15:58:59 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
	<atom:link rel="hub" href="http://superfeedr.com/hubbub" />
		<item>
		<title>By: Alan Wilensky</title>
		<link>http://www.lastpodcast.net/2008/04/23/twitters-lead-architect-leaves/comment-page-1/#comment-49671</link>
		<dc:creator>Alan Wilensky</dc:creator>
		<pubDate>Wed, 23 Apr 2008 19:08:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.lastpodcast.net/2008/04/23/twitters-lead-architect-leaves/#comment-49671</guid>
		<description>They are all learning the same lesson over and over again. RDBMS systems that cater to high write rate events with transient small joins are the most brittle critters. I know this first hand. 

Now, Fitzpatrick solved this years ago at Livejournal and Typepad. He is now a Google man. he get&#039;s it.

There is such an investment in the off-the shelf mysql databases that has literally created a whole class of scaling problems. As a matter of fact, the clustering options for these write throughput problems are worse that what they are trying to cure!

They didn&#039;t think this through - it&#039;s too easy to set up a few database servers and wait for the madness. &quot;Gee harry, things seem to be fine, for now.&quot;

Don&#039;t  get me started on what conventional wisdom regarding wen applications and RDBMS has wrought on my vertical systems and mobile messaging systems work. Thank G-d I found http://www.db4o.com/default.aspx</description>
		<content:encoded><![CDATA[<p>They are all learning the same lesson over and over again. RDBMS systems that cater to high write rate events with transient small joins are the most brittle critters. I know this first hand. </p>
<p>Now, Fitzpatrick solved this years ago at Livejournal and Typepad. He is now a Google man. he get&#8217;s it.</p>
<p>There is such an investment in the off-the shelf mysql databases that has literally created a whole class of scaling problems. As a matter of fact, the clustering options for these write throughput problems are worse that what they are trying to cure!</p>
<p>They didn&#8217;t think this through &#8211; it&#8217;s too easy to set up a few database servers and wait for the madness. &#8220;Gee harry, things seem to be fine, for now.&#8221;</p>
<p>Don&#8217;t  get me started on what conventional wisdom regarding wen applications and RDBMS has wrought on my vertical systems and mobile messaging systems work. Thank G-d I found <a href="http://www.db4o.com/default.aspx" rel="nofollow">http://www.db4o.com/default.aspx</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
