<story><title>Turning the database inside-out with Apache Samza</title><url>http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/</url></story><parent_chain><item><author>coffeemug</author><text>Slava @ rethink here.&lt;p&gt;This is a really interesting subject -- I should do a talk&amp;#x2F;blog post about this at some point. Here is a quick summary.&lt;p&gt;RethinkDB&amp;#x27;s storage engine heavily relies on the notion of immutability&amp;#x2F;append-only. We never modify blocks of data in place on disk -- all changes are recorded in new blocks. We have a concurrent, incremental compaction algorithm that goes through the old blocks, frees the ones that are outdated, and moves things around when some blocks have mostly garbage.&lt;p&gt;The system is very fast and rock solid. But...&lt;p&gt;Getting a storage engine like that to production state is an enormous amount of work and takes a very long time. Rethink&amp;#x27;s storage engine is really a work of art -- I consider it a marvel of engineering, and I don&amp;#x27;t mean that as a compliment. If we were starting from scratch, I don&amp;#x27;t think we&amp;#x27;d use this design again. It&amp;#x27;s great now, but I&amp;#x27;m not sure if all the work we put into it was ultimately worth the effort.</text></item><item><author>slashdev</author><text>Immutability is hardly a cure-all, see the discussion here for why RethinkDB moved away from it: &lt;a href=&quot;http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.xaprb.com&amp;#x2F;blog&amp;#x2F;2013&amp;#x2F;12&amp;#x2F;28&amp;#x2F;immutability-mvcc-and-g...&lt;/a&gt;&lt;p&gt;The reality is shared, mutable state is the most efficient way of working with memory-sized data. People can rant and rave all they want about the benefits of immutability vs mutability, but at the end of the day, if performance is important to you, you&amp;#x27;d be best to ignore them.&lt;p&gt;Actually, to be more honest, reality is more complicated still. MVCC that many databases use to get ACID semantics over a shared mutable dataset is really a combination of mutable and immutable.</text></item></parent_chain><comment><author>boredandroid</author><text>I really think there are a couple of levels of immutability that it is easy to conflate.&lt;p&gt;Specifically immutability for&lt;p&gt;1. In memory data structures...this is the contention of the functional programming people.&lt;p&gt;2. Persistent data stores. This is the lsm style of data structure that substitutes linear writes and compaction for buffered in-place mutation.&lt;p&gt;3. Distributed system internals--this is a log-centric, &amp;quot;state machine replication&amp;quot; style of data flow between nodes. This is a classic approach in distributed databases, and present in systems like PNUTs.&lt;p&gt;4. Company-wide data integration and processing around streams of immutable records between systems. This is what I have argued for (&lt;a href=&quot;http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;engineering.linkedin.com&amp;#x2F;distributed-systems&amp;#x2F;log-what...&lt;/a&gt;) and I think Martin is mostly talking about.&lt;p&gt;There are a lot of analogies between these but they aren&amp;#x27;t the same. Success of one of these things doesn&amp;#x27;t really imply success for any of the others. Functional programming could lose and log-structured data stores could win or vice versa. Pat Helland has made an across the board call for immutability (&lt;a href=&quot;http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.cidrdb.org&amp;#x2F;cidr2015&amp;#x2F;Papers&amp;#x2F;CIDR15_Paper16.pdf&lt;/a&gt;), but that remains a pretty strong assertion. So it is worth being specific about which level you are thinking about.&lt;p&gt;For my part I am pretty bullish about stream processing and data flow between systems being built around a log or stream of immutable records as the foundational abstraction. But whether those systems internally are built in functional languages, use lsm style data layout on disk is kind of an implementation detail. From my point of view immutability is a lot more helpful in the large than in the small--I have never found small imperative for loops particularly hard to read, but process-wide mutable state is a big pain, and undisciplined dataflow between disparate systems, caches, and applications at the company level can be a real disaster.</text></comment>
<story><title>Turning the database inside-out with Apache Samza</title><url>http://blog.confluent.io/2015/03/04/turning-the-database-inside-out-with-apache-samza/</url></story><parent_chain><item><author>coffeemug</author><text>Slava @ rethink here.&lt;p&gt;This is a really interesting subject -- I should do a talk&amp;#x2F;blog post about this at some point. Here is a quick summary.&lt;p&gt;RethinkDB&amp;#x27;s storage engine heavily relies on the notion of immutability&amp;#x2F;append-only. We never modify blocks of data in place on disk -- all changes are recorded in new blocks. We have a concurrent, incremental compaction algorithm that goes through the old blocks, frees the ones that are outdated, and moves things around when some blocks have mostly garbage.&lt;p&gt;The system is very fast and rock solid. But...&lt;p&gt;Getting a storage engine like that to production state is an enormous amount of work and takes a very long time. Rethink&amp;#x27;s storage engine is really a work of art -- I consider it a marvel of engineering, and I don&amp;#x27;t mean that as a compliment. If we were starting from scratch, I don&amp;#x27;t think we&amp;#x27;d use this design again. It&amp;#x27;s great now, but I&amp;#x27;m not sure if all the work we put into it was ultimately worth the effort.</text></item><item><author>slashdev</author><text>Immutability is hardly a cure-all, see the discussion here for why RethinkDB moved away from it: &lt;a href=&quot;http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.xaprb.com&amp;#x2F;blog&amp;#x2F;2013&amp;#x2F;12&amp;#x2F;28&amp;#x2F;immutability-mvcc-and-g...&lt;/a&gt;&lt;p&gt;The reality is shared, mutable state is the most efficient way of working with memory-sized data. People can rant and rave all they want about the benefits of immutability vs mutability, but at the end of the day, if performance is important to you, you&amp;#x27;d be best to ignore them.&lt;p&gt;Actually, to be more honest, reality is more complicated still. MVCC that many databases use to get ACID semantics over a shared mutable dataset is really a combination of mutable and immutable.</text></item></parent_chain><comment><author>eloff</author><text>It&amp;#x27;s that merge (edit: GC is a better term) step that&amp;#x27;s difficult to get right. Google screwed this up badly with LevelDB which had(still has?) horrible performance issues caused by compaction. Even with concurrent compaction it can be difficult due to needing additional disk space, adding additional read and write pressure to the storage subsystem and the effects that has on latency. I&amp;#x27;m not sure what RethinkDB&amp;#x27;s approach was there, but I&amp;#x27;m very curious to know.</text></comment>