svn commit: r1513199 - /incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html

[cr...@apache.org]

Author: criccomini
Date: Mon Aug 12 17:02:18 2013
New Revision: 1513199

URL: http://svn.apache.org/r1513199
Log:
fix broken image in comparison intro page.

Modified:
    incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html

Modified: incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html
URL: http://svn.apache.org/viewvc/incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html?rev=1513199&r1=1513198&r2=1513199&view=diff
==============================================================================
--- incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html (original)
+++ incubator/samza/site/learn/documentation/0.7.0/comparisons/introduction.html Mon Aug 12 17:02:18 2013
@@ -89,7 +89,7 @@
 
 <p>This means that you can view a Samza job as being both a piece of processing code, but also a co-partitioned &quot;table&quot; of state. This allows rich local queries and scans against this state. These tables are made fault-tolerant by producing a &quot;changelog&quot; stream which is used to restore the state of the table on fail-over. This stream is just another Samza stream, it can even be used as input for other jobs.</p>
 
-<p><img src="/img/samza_state.png" alt="Stateful Processing"></p>
+<p><img src="/img/0.7.0/learn/documentation/introduction/samza_state.png" alt="Stateful Processing"></p>
 
 <p>In our experience most processing flows require joins against other data sourceIn the absence of state maintenance, any joining or aggregation has to be done by querying an external data system. This tends to be one or two orders of magnitude slower than sequential processing. For example per-node throughput for Kafka would easily be in the 100k-500k messages/sec range (depending on message size) but remote queries against a key-value store tend to be closer to 1-5k queries-per-second per node.</p>