<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://www.scylladb.com/2018/06/12/scylla-leverages-control-theory/"/>
	<rdf:li rdf:resource="https://eng.uber.com/cherami/"/>
	<rdf:li rdf:resource="http://rockthecode.io/blog/highly-available-counters-using-cassandra/"/>
	<rdf:li rdf:resource="http://prometheus.io/blog/2016/03/23/interview-with-life360/"/>
	<rdf:li rdf:resource="https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/"/>
	<rdf:li rdf:resource="http://www.scylladb.com/2015/10/13/cluster-benchmark/"/>
	<rdf:li rdf:resource="http://blog.threatstack.com/scaling-cassandra-lessons-learned"/>
	<rdf:li rdf:resource="https://medium.com/@foundev/real-time-analytics-with-spark-streaming-and-cassandra-2f90d03342f7"/>
	<rdf:li rdf:resource="https://timharris.uk/papers/2015-hotos.pdf"/>
	<rdf:li rdf:resource="https://issues.apache.org/jira/browse/CASSANDRA-7486"/>
	<rdf:li rdf:resource="http://www.slideshare.net/WrathOfChris/cassandra-meetup-20150331-46523636"/>
	<rdf:li rdf:resource="http://mail-archives.apache.org/mod_mbox/cassandra-user/201504.mbox/%3CCALamADJu4yo%3DcO8HgA6NpgFc1wQN_VNqpkMn-3SZwhPq9foLBw%40mail.gmail.com%3E"/>
	<rdf:li rdf:resource="http://muratbuffalo.blogspot.co.uk/2015/03/paper-review-simple-testing-can-prevent.html"/>
	<rdf:li rdf:resource="http://tobert.github.io/tldr/cassandra-java-huge-pages.html"/>
	<rdf:li rdf:resource="https://labs.spotify.com/2015/01/09/personalization-at-spotify-using-cassandra/"/>
	<rdf:li rdf:resource="http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html"/>
	<rdf:li rdf:resource="http://engineering.onlive.com/2013/12/12/didnt-use-kafka/"/>
	<rdf:li rdf:resource="https://github.com/tobert/pcstat"/>
	<rdf:li rdf:resource="http://rustyrazorblade.com/2014/09/cassandra-summit-recap-diagnosing-problems-in-production/"/>
	<rdf:li rdf:resource="https://github.com/comeara/pillar"/>
	<rdf:li rdf:resource="http://aws.amazon.com/solutions/case-studies/hailo/"/>
	<rdf:li rdf:resource="https://blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale"/>
	<rdf:li rdf:resource="http://www.fullcontact.com/blog/mongo-to-cassandra-migration/"/>
	<rdf:li rdf:resource="http://www.datastax.com/dev/blog/improving-compaction-in-cassandra-with-cardinality-estimation"/>
	<rdf:li rdf:resource="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads"/>
	<rdf:li rdf:resource="https://github.com/pyr/cyanite"/>
	<rdf:li rdf:resource="http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html"/>
	<rdf:li rdf:resource="http://aphyr.com/posts/299-the-trouble-with-timestamps"/>
	<rdf:li rdf:resource="http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2"/>
	<rdf:li rdf:resource="http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/"/>
	<rdf:li rdf:resource="https://blog.twitter.com/2013/observability-at-twitter"/>
	<rdf:li rdf:resource="https://issues.apache.org/jira/browse/CASSANDRA-5582"/>
	<rdf:li rdf:resource="http://blueflood.io/"/>
	<rdf:li rdf:resource="http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings"/>
	<rdf:li rdf:resource="http://spyced.blogspot.ie/2008/12/couchdb-not-drinking-kool-aid.html"/>
	<rdf:li rdf:resource="http://www.datastax.com/dev/blog/metric-collection-and-storage-with-cassandra"/>
	<rdf:li rdf:resource="http://techo-ecco.com/blog/monitoring-apache-hadoop-cassandra-and-zookeeper-using-graphite-and-jmxtrans/"/>
	<rdf:li rdf:resource="http://techblog.netflix.com/2013/02/netflix-queue-data-migration-for-high.html"/>
	<rdf:li rdf:resource="http://www.odbms.org/blog/2013/02/big-data-analytics-at-netflix-interview-with-christos-kalantzis-and-jason-brown/"/>
	<rdf:li rdf:resource="http://blog.markedup.com/2013/02/cassandra-hive-and-hadoop-how-we-picked-our-analytics-stack/"/>
	<rdf:li rdf:resource="http://www.slideshare.net/adrianco/arch-tutoriallo2of3"/>
	<rdf:li rdf:resource="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html"/>
	<rdf:li rdf:resource="http://news.ycombinator.com/item?id=2434187"/>
	<rdf:li rdf:resource="http://www.slideshare.net/kevinweil/nosql-at-twitter-nosql-eu-2010"/>
	<rdf:li rdf:resource="http://ewh.ieee.org/r6/scv/computer//nfic/2009/IBM-Jun-Rao.pdf"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://www.scylladb.com/2018/06/12/scylla-leverages-control-theory/">
    <title>Taming the Beast: How Scylla Leverages Control Theory to Keep Compactions Under Control - ScyllaDB</title>
    <dc:date>2018-06-14T10:29:17+00:00</dc:date>
    <link>https://www.scylladb.com/2018/06/12/scylla-leverages-control-theory/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a really nice illustration of the use of control theory to set tunable thresholds automatically in a complex storage system.  Nice work Scylla:

<blockquote>
At any given moment, a database like ScyllaDB has to juggle the admission of foreground requests with background processes like compactions, making sure that the incoming workload is not severely disrupted by compactions, nor that the compaction backlog is so big that reads are later penalized.

In this article, we showed that isolation among incoming writes and compactions can be achieved by the Schedulers, yet the database is still left with the task of determining the amount of shares of the resources incoming writes and compactions will use.

Scylla steers away from user-defined tunables in this task, as they shift the burden of operation to the user, complicating operations and being fragile against changing workloads. By borrowing from the strong theoretical background of industrial controllers, we can provide an Autonomous Database that adapts to changing workloads without operator intervention.</blockquote>

]]></description>
<dc:subject>scylladb storage settings compaction automation thresholds control-theory ops cassandra feedback</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0924f70f896e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylladb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:settings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compaction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thresholds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:control-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:feedback"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://eng.uber.com/cherami/">
    <title>Cherami: Uber Engineering’s Durable and Scalable Task Queue in Go - Uber Engineering Blog</title>
    <dc:date>2016-12-14T11:21:39+00:00</dc:date>
    <link>https://eng.uber.com/cherami/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
a competing-consumer messaging queue that is durable, fault-tolerant, highly available and scalable. We achieve durability and fault-tolerance by replicating messages across storage hosts, and high availability by leveraging the append-only property of messaging queues and choosing eventual consistency as our basic model. Cherami is also scalable, as the design does not have single bottleneck. [...]
Cherami is completely written in Go, a language that makes building highly performant and concurrent system software a lot of fun. Additionally, Cherami uses several libraries that Uber has already open sourced: TChannel for RPC and Ringpop for health checking and group membership. Cherami depends on several third-party open source technologies: Cassandra for metadata storage, RocksDB for message storage, and many other third-party Go packages that are available on GitHub. We plan to open source Cherami in the near future.
</blockquote>]]></description>
<dc:subject>cherami uber queueing tasks queues architecture scalability go cassandra rocksdb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:08be41dbc892/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cherami"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tasks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rocksdb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rockthecode.io/blog/highly-available-counters-using-cassandra/">
    <title>Highly Available Counters Using Cassandra</title>
    <dc:date>2016-09-15T09:52:28+00:00</dc:date>
    <link>http://rockthecode.io/blog/highly-available-counters-using-cassandra/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[solid discussion of building HA counters using CRDTs and similar eventually-consistent data structures]]></description>
<dc:subject>crdts algorithms data-structures cassandra ha counters</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c45847cfbdbb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crdts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ha"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counters"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://prometheus.io/blog/2016/03/23/interview-with-life360/">
    <title>Life360 testimonial for Prometheus</title>
    <dc:date>2016-03-24T13:21:13+00:00</dc:date>
    <link>http://prometheus.io/blog/2016/03/23/interview-with-life360/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Now this is a BIG thumbs up: <blockquote>'Prometheus has been known to us for a while, and we have been tracking it and reading about the active development, and at a point (a few months back) we decided to start evaluating it for production use.  The PoC results were incredible. The monitoring coverage of MySQL was amazing, and we also loved the JMX monitoring for Cassandra, which had been sorely lacking in the past.'</blockquote>

]]></description>
<dc:subject>metrics monitoring time-series prometheus testimonials life360 cassandra jmx mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4405c9925a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testimonials"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:life360"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/">
    <title>Heroic</title>
    <dc:date>2015-12-09T11:35:37+00:00</dc:date>
    <link>https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Spotify wrote their own metrics store on ElasticSearch and Cassandra.  Sounds very similar to Prometheus]]></description>
<dc:subject>cassandra elasticsearch spotify monitoring metrics heroic</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cdb427d86615/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticsearch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spotify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heroic"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.scylladb.com/2015/10/13/cluster-benchmark/">
    <title>Cluster benchmark: Scylla vs Cassandra</title>
    <dc:date>2015-10-15T10:49:07+00:00</dc:date>
    <link>http://www.scylladb.com/2015/10/13/cluster-benchmark/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ScyllaDB (the C* clone in C++) is now actually looking promising -- still need more reassurance about its consistency/reliabilty side though]]></description>
<dc:subject>scylla databases storage cassandra nosql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aa43216c9e0e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.threatstack.com/scaling-cassandra-lessons-learned">
    <title>Scale it to Billions — What They Don’t Tell you in the Cassandra README</title>
    <dc:date>2015-09-28T15:30:07+00:00</dc:date>
    <link>http://blog.threatstack.com/scaling-cassandra-lessons-learned</link>
    <dc:creator>jm</dc:creator><description><![CDATA[large-scale C* tips]]></description>
<dc:subject>cassandra configuration tuning scale ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:41bfcab2a82b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:configuration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@foundev/real-time-analytics-with-spark-streaming-and-cassandra-2f90d03342f7">
    <title>Real Time Analytics With Spark Streaming and Cassandra</title>
    <dc:date>2015-09-03T20:58:52+00:00</dc:date>
    <link>https://medium.com/@foundev/real-time-analytics-with-spark-streaming-and-cassandra-2f90d03342f7</link>
    <dc:creator>jm</dc:creator><description><![CDATA[...and Kafka
]]></description>
<dc:subject>spark-streaming kafka analytics cassandra architecture data batch</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b0d85df5ec49/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark-streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:batch"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://timharris.uk/papers/2015-hotos.pdf">
    <title>&quot;Trash Day: Coordinating Garbage Collection in Distributed Systems&quot;</title>
    <dc:date>2015-05-06T16:34:59+00:00</dc:date>
    <link>https://timharris.uk/papers/2015-hotos.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Another GC-coordination strategy, similar to Blade (qv), with some real-world examples using Cassandra]]></description>
<dc:subject>blade via:adriancolyer papers gc distsys algorithms distributed java jvm latency spark cassandra</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf80614a2fb9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:adriancolyer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distsys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://issues.apache.org/jira/browse/CASSANDRA-7486">
    <title>Cassandra moving to using G1 as the default recommended GC implementation</title>
    <dc:date>2015-04-29T15:42:34+00:00</dc:date>
    <link>https://issues.apache.org/jira/browse/CASSANDRA-7486</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a big indicator that G1 is ready for primetime. CMS has long been the go-to GC for production usage, but requires careful, complex hand-tuning -- if G1 is getting to a stage where it's just a case of giving it enough RAM, that'd be great.

Also, looks like it'll be the JDK9 default: https://twitter.com/shipilev/status/593175793255219200]]></description>
<dc:subject>cassandra tuning ops g1gc cms gc java jvm production performance memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0b4b3d1abe38/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/WrathOfChris/cassandra-meetup-20150331-46523636">
    <title>Time Series Metrics with Cassandra</title>
    <dc:date>2015-04-06T20:37:04+00:00</dc:date>
    <link>http://www.slideshare.net/WrathOfChris/cassandra-meetup-20150331-46523636</link>
    <dc:creator>jm</dc:creator><description><![CDATA[slides from Chris Maxwell of Ubiquiti Networks describing what he had to do to get cyanite on Cassandra handling 30k metrics per second; an experimental "Date-tiered compaction" mode from Spotify was essential from the sounds of it.  Very complex :(]]></description>
<dc:subject>cassandra spotify date-tiered-compaction metrics graphite cyanite chris-maxwell time-series-data</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7af91a493440/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spotify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:date-tiered-compaction"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cyanite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chris-maxwell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series-data"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mail-archives.apache.org/mod_mbox/cassandra-user/201504.mbox/%3CCALamADJu4yo%3DcO8HgA6NpgFc1wQN_VNqpkMn-3SZwhPq9foLBw%40mail.gmail.com%3E">
    <title>Cassandra remote code execution hole (CVE-2015-0225)</title>
    <dc:date>2015-04-01T15:11:51+00:00</dc:date>
    <link>http://mail-archives.apache.org/mod_mbox/cassandra-user/201504.mbox/%3CCALamADJu4yo%3DcO8HgA6NpgFc1wQN_VNqpkMn-3SZwhPq9foLBw%40mail.gmail.com%3E</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ah now lads.

<blockquote>Under its default configuration, Cassandra binds an unauthenticated
JMX/RMI interface to all network interfaces.  As RMI is an API for the
transport and remote execution of serialized Java, anyone with access
to this interface can execute arbitrary code as the running user.</blockquote>

]]></description>
<dc:subject>cassandra jmx rmi java ops security</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f1a9c3b5500d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rmi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://muratbuffalo.blogspot.co.uk/2015/03/paper-review-simple-testing-can-prevent.html">
    <title>Paper review: &quot;Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems&quot;</title>
    <dc:date>2015-03-27T09:36:04+00:00</dc:date>
    <link>http://muratbuffalo.blogspot.co.uk/2015/03/paper-review-simple-testing-can-prevent.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Race conditions, and errors at startup, seem to be particularly problematic]]></description>
<dc:subject>race-conditions startup bugs failure fault-tolerance hbase redis reliability ops papers concurrency exception-handling cassandra hdfs mapreduce</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3dd7b48e5fed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:race-conditions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:startup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hbase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exception-handling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mapreduce"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tobert.github.io/tldr/cassandra-java-huge-pages.html">
    <title>TL;DR: Cassandra Java Huge Pages</title>
    <dc:date>2015-02-03T22:09:12+00:00</dc:date>
    <link>http://tobert.github.io/tldr/cassandra-java-huge-pages.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Al Tobey does some trial runs of -XX:+AlwaysPreTouch and -XX:+UseHugePages]]></description>
<dc:subject>jvm performance tuning huge-pages vm ops cassandra java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d448b5d53e34/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huge-pages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://labs.spotify.com/2015/01/09/personalization-at-spotify-using-cassandra/">
    <title>Personalization at Spotify using Cassandra</title>
    <dc:date>2015-01-12T22:29:19+00:00</dc:date>
    <link>https://labs.spotify.com/2015/01/09/personalization-at-spotify-using-cassandra/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Lots and lots of good detail into the Spotify C* setup (via Bill de hOra)]]></description>
<dc:subject>via:dehora spotify cassandra replication storage ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:13abf373f291/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:dehora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spotify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html">
    <title>Hack workaround to get JVM thread priorities working on Linux</title>
    <dc:date>2015-01-05T17:56:26+00:00</dc:date>
    <link>http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[As used in Cassandra ( http://grokbase.com/t/hbase/dev/13bf9kezes/about-xx-threadprioritypolicy-42 )!

<blockquote>if you just set the "ThreadPriorityPolicy" to something else than the legal values 0 or 1, [...] a slight logic bug in Sun's JVM code kicks in, and thus sets the policy to be as if running with root - thus you get exactly what one desire. The operating system, Linux, won't allow priorities to be heightened above "Normal" (negative nice value), and thus just ignores those requests (setting it to normal instead, nice value 0) - but it lets through the requests to set it lower (setting the nice value to some positive value).</blockquote>

]]></description>
<dc:subject>cassandra thread-priorities threads java jvm linux nice hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:abed46e6d700/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thread-priorities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.onlive.com/2013/12/12/didnt-use-kafka/">
    <title>Why We Didn’t Use Kafka for a Very Kafka-Shaped Problem</title>
    <dc:date>2014-11-04T17:12:53+00:00</dc:date>
    <link>http://engineering.onlive.com/2013/12/12/didnt-use-kafka/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A good story of when Kafka _didn't_ fit the use case:

<blockquote>We came up with a complicated process of app-level replication for our messages into two separate Kafka clusters. We would then do end-to-end checking of the two clusters, detecting dropped messages in each cluster based on messages that weren’t in both.

It was ugly. It was clearly going to be fragile and error-prone. It was going to be a lot of app-level replication and horrible heuristics to see when we were losing messages and at least alert us, even if we couldn’t fix every failure case.

Despite us building a Kafka prototype for our ETL — having an existing investment in it — it just wasn’t going to do what we wanted. And that meant we needed to leave it behind, rewriting the ETL prototype.</blockquote>

]]></description>
<dc:subject>cassandra java kafka scala network-partitions availability multi-region multi-az aws replication onlive</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6bbae76b03db/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network-partitions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multi-region"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multi-az"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:onlive"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/tobert/pcstat">
    <title>pcstat</title>
    <dc:date>2014-09-19T09:58:07+00:00</dc:date>
    <link>https://github.com/tobert/pcstat</link>
    <dc:creator>jm</dc:creator><description><![CDATA[get page cache statistics for files.

<blockquote>A common question when tuning databases and other IO-intensive applications is, "is Linux caching my data or not?" pcstat gets that information for you using the mincore(2) syscall.  I wrote this is so that Apache Cassandra users can see if ssTables are being cached.</blockquote>

]]></description>
<dc:subject>linux page-cache caching go performance cassandra ops mincore fincore</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4b9a6fb3fd3a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:page-cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mincore"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fincore"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rustyrazorblade.com/2014/09/cassandra-summit-recap-diagnosing-problems-in-production/">
    <title>Cassandra Summit Recap: Diagnosing Problems in Production</title>
    <dc:date>2014-09-19T09:55:25+00:00</dc:date>
    <link>http://rustyrazorblade.com/2014/09/cassandra-summit-recap-diagnosing-problems-in-production/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great runbook for C* ops]]></description>
<dc:subject>cassandra ops storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f0c6dff42d2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/comeara/pillar">
    <title>Pillar</title>
    <dc:date>2014-06-16T12:56:53+00:00</dc:date>
    <link>https://github.com/comeara/pillar</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Manages migrations for your Cassandra data stores. Pillar grew from a desire to automatically manage Cassandra schema as code. Managing schema as code enables automated build and deployment, a foundational practice for an organization striving to achieve Continuous Delivery.

Pillar is to Cassandra what Rails ActiveRecord migrations or Play Evolutions are to relational databases with one key difference: Pillar is completely independent from any application development framework.</blockquote>

]]></description>
<dc:subject>migrations database ops pillar cassandra activerecord scala continuous-delivery automation build</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acc70894611d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pillar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activerecord"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:continuous-delivery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aws.amazon.com/solutions/case-studies/hailo/">
    <title>AWS Case Study: Hailo</title>
    <dc:date>2014-04-28T11:35:23+00:00</dc:date>
    <link>http://aws.amazon.com/solutions/case-studies/hailo/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ubuntu, C*, HAProxy, MySQL, RDS, multiple AWS regions.]]></description>
<dc:subject>hailo cassandra ubuntu mysql rds aws ec2 haproxy architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:210362e2cd0c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hailo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haproxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale">
    <title>Manhattan, our real-time, multi-tenant distributed database for Twitter scale | Twitter Blogs</title>
    <dc:date>2014-04-03T12:59:08+00:00</dc:date>
    <link>https://blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Impressive, but a fierce whiff of "NIH" off of this]]></description>
<dc:subject>manhattan consistency database twitter eventual-consistency nosql voldemort cassandra riak time-series</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5ce9c084548e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:manhattan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consistency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eventual-consistency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.fullcontact.com/blog/mongo-to-cassandra-migration/">
    <title>Migrating from MongoDB to Cassandra</title>
    <dc:date>2014-02-12T10:49:07+00:00</dc:date>
    <link>http://www.fullcontact.com/blog/mongo-to-cassandra-migration/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting side-effect of using LUKS for full-disk encryption: 'For every disk read, we were pulling in 3MB of data (RA is sectors, SSZ is sector size, 6144*512=3145728 bytes) into cache. Oops. Not only were we doing tons of extra work, but we were trashing our page cache too. The default for the device-mapper used by LUKS under Ubuntu 12.04LTS is incredibly sub-optimal for database usage, especially our usage of Cassandra (more small random reads vs. large rows). We turned this down to 128 sectors — 64KB.']]></description>
<dc:subject>cassandra luks raid linux tuning ops blockdev disks sdd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9e9bd44bf027/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:luks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blockdev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sdd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.datastax.com/dev/blog/improving-compaction-in-cassandra-with-cardinality-estimation">
    <title>Improving compaction in Cassandra with cardinality estimation</title>
    <dc:date>2014-01-28T22:51:37+00:00</dc:date>
    <link>http://www.datastax.com/dev/blog/improving-compaction-in-cassandra-with-cardinality-estimation</link>
    <dc:creator>jm</dc:creator><description><![CDATA[nice use of HyperLogLog]]></description>
<dc:subject>hyperloglog hll algorithms cassandra bloom-filters sstables cardinality</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cca5dc02afd5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hll"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bloom-filters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sstables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cardinality"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads">
    <title>Cassandra: tuning the JVM for read heavy workloads</title>
    <dc:date>2014-01-24T10:14:24+00:00</dc:date>
    <link>http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The cluster we tuned is hosted on AWS and is comprised of 6 hi1.4xlarge EC2 instances, with 2 1TB SSDs raided together in a raid 0 configuration. The cluster’s dataset is growing steadily. At the time of this writing, our dataset is 341GB, up from less than 200GB a few months ago, and is growing by 2-3GB per day. The workload on this cluster is very read heavy, with quorum reads making up 99% of all operations.</blockquote>

Some careful GC tuning here.  Probably not applicable to anyone else, but good approach in general.]]></description>
<dc:subject>java performance jvm scaling gc tuning cassandra ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bc4cff6803b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/pyr/cyanite">
    <title>Cyanite</title>
    <dc:date>2013-12-09T10:08:22+00:00</dc:date>
    <link>https://github.com/pyr/cyanite</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a metric storage daemon, exposing both a carbon listener and a simple web service. Its aim is to become a simple, scalable and drop-in replacement for graphite's backend.</blockquote>

Pretty alpha for now, but definitely worth keeping an eye on to potentially replace our burgeoning Carbon fleet...
]]></description>
<dc:subject>graphite carbon cassandra storage metrics ops graphs service-metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d96de514fb8f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:carbon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html">
    <title>Introducing Chaos to C*</title>
    <dc:date>2013-10-19T20:19:28+00:00</dc:date>
    <link>http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Autoremediation, ie. auto-replacement, of Cassandra nodes in production at Netflix]]></description>
<dc:subject>ops autoremediation outages remediation cassandra storage netflix chaos-monkey</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:08c65b108c70/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoremediation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:remediation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chaos-monkey"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aphyr.com/posts/299-the-trouble-with-timestamps">
    <title>The trouble with timestamps</title>
    <dc:date>2013-10-14T09:45:54+00:00</dc:date>
    <link>http://aphyr.com/posts/299-the-trouble-with-timestamps</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Timestamps, as implemented in Riak, Cassandra, et al, are fundamentally unsafe ordering constructs. In order to guarantee consistency you, the user, must ensure locally monotonic and, to some extent, globally monotonic clocks. This is a hard problem, and NTP does not solve it for you. When wall clocks are not properly coupled to the operations in the system, causal constraints can be violated. To ensure safety properties hold all the time, rather than probabilistically, you need logical clocks.</blockquote>

]]></description>
<dc:subject>clocks time distributed databases distcomp ntp via:fanf aphyr vector-clocks last-write-wins lww cassandra riak</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dcc3c0071909/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aphyr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vector-clocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:last-write-wins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lww"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2">
    <title>Rapid read protection in Cassandra 2.0.2</title>
    <dc:date>2013-10-05T20:56:35+00:00</dc:date>
    <link>http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nifty new feature -- if a request takes over the 99th percentile for requests to that server, it'll be repeated against another replica.  Unnecessary for Voldemort, of course, which queries all replicas anyway!]]></description>
<dc:subject>cassandra nosql replication distcomp latency storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:74b80ef24320/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/">
    <title>Why Tellybug moved from Cassandra to Amazon DynamoDB</title>
    <dc:date>2013-10-02T12:55:23+00:00</dc:date>
    <link>http://attentionshard.wordpress.com/2013/09/30/why-tellybug-moved-from-cassandra-to-amazon-dynamodb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Summary: poor reliability, better latencies, and cheaper (!)]]></description>
<dc:subject>aws dynamodb cassandra nosql storage tellybug counters scalability reliability latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8b0a38474b92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tellybug"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.twitter.com/2013/observability-at-twitter">
    <title>Observability at Twitter</title>
    <dc:date>2013-09-11T21:40:35+00:00</dc:date>
    <link>https://blog.twitter.com/2013/observability-at-twitter</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bit of detail into Twitter's TSD metric store.

<blockquote>There are separate online clusters for different data sets: application and operating system metrics, performance critical write-time aggregates, long term archives, and temporal indexes. A typical production instance of the time series database is based on four distinct Cassandra clusters, each responsible for a different dimension (real-time, historical, aggregate, index) due to different performance constraints. These clusters are amongst the largest Cassandra clusters deployed in production today and account for over 500 million individual metric writes per minute. Archival data is stored at a lower resolution for trending and long term analysis, whereas higher resolution data is periodically expired. Aggregation is generally performed at write-time to avoid extra storage operations for metrics that are expected to be immediately consumed. Indexing occurs along several dimensions–service, source, and metric names–to give users some flexibility in finding relevant data.</blockquote>

]]></description>
<dc:subject>twitter monitoring metrics service-metrics tsd time-series storage architecture cassandra</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f55dd143a82/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://issues.apache.org/jira/browse/CASSANDRA-5582">
    <title>[#CASSANDRA-5582] Replace CustomHsHaServer with better optimized solution based on LMAX Disruptor</title>
    <dc:date>2013-09-03T22:29:45+00:00</dc:date>
    <link>https://issues.apache.org/jira/browse/CASSANDRA-5582</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Disruptor: decimating P99s since 2011]]></description>
<dc:subject>disruptor cassandra java p99 latency speed performance concurrency via:kellabyte</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:70d101c721e7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disruptor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p99"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:kellabyte"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blueflood.io/">
    <title>Blueflood by rackerlabs</title>
    <dc:date>2013-09-02T15:19:32+00:00</dc:date>
    <link>http://blueflood.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Rackspace's large-scale TSD storage system, built on Cassandra, Java, ASL2]]></description>
<dc:subject>cassandra tsd storage time-series data open-source java rackspace</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9991bb557631/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rackspace"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings">
    <title>Instagram: Making the Switch to Cassandra from Redis, a 75% 'Insta' Savings</title>
    <dc:date>2013-06-09T21:47:43+00:00</dc:date>
    <link>http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings</link>
    <dc:creator>jm</dc:creator><description><![CDATA[shifting data out of RAM and onto SSDs -- unsurprisingly, big savings.

<blockquote>a 12 node cluster of EC2 hi1.4xlarge instances; we store around 1.2TB of data across this cluster. At peak, we're doing around 20,000 writes per second to that specific cluster and around 15,000 reads per second. We've been really impressed with how well Cassandra has been able to drop into that role.</blockquote>

]]></description>
<dc:subject>ram ssd cassandra databases nosql redis instagram storage ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:971263030ef5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instagram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://spyced.blogspot.ie/2008/12/couchdb-not-drinking-kool-aid.html">
    <title>CouchDB: not drinking the kool-aid</title>
    <dc:date>2013-04-09T09:43:42+00:00</dc:date>
    <link>http://spyced.blogspot.ie/2008/12/couchdb-not-drinking-kool-aid.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Jonathan Ellis on some CouchDB negatives:

<blockquote>Here are some reasons you should think twice and do careful testing before using CouchDB in a non-toy project:
Writes are serialized.  Not serialized as in the isolation level, serialized as in there can only be one write active at a time.  Want to spread writes across multiple disks?  Sorry.
CouchDB uses a MVCC model, which means that updates and deletes need to be compacted for the space to be made available to new writes.  Just like PostgreSQL, only without the man-years of effort to make vacuum hurt less.
CouchDB is simple.  Gloriously simple.  Why is that a negative?  It's competing with systems (in the popular imagination, if not in its author's mind) that have been maturing for years.  The reason PostgreSQL et al have those features is because people want them.  And if you don't, you should at least ask a DBA with a few years of non-MySQL experience what you'll be missing.  The majority of CouchDB fans don't appear to really understand what a good relational database gives them, just as a lot of PHP programmers don't get what the big deal is with namespaces.
A special case of simplicity deserves mention: nontrivial queries must be created as a view with mapreduce.  MapReduce is a great approach to trivially parallelizing certain classes of problem.  The problem is, it's tedious and error-prone to write raw MapReduce code.  This is why Google and Yahoo have both created high-level languages on top of it (Sawzall and Pig, respectively).  Poor SQL; even with DSLs being the new hotness, people forget that SQL is one of the original domain-specific languages.  It's a little verbose, and you might be bored with it, but it's much better than writing low-level mapreduce code.</blockquote>

]]></description>
<dc:subject>cassandra couch nosql storage distributed databases consistency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ea7fb334af3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:couch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consistency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.datastax.com/dev/blog/metric-collection-and-storage-with-cassandra">
    <title>Metric Collection and Storage with Cassandra | DataStax</title>
    <dc:date>2013-03-12T21:48:41+00:00</dc:date>
    <link>http://www.datastax.com/dev/blog/metric-collection-and-storage-with-cassandra</link>
    <dc:creator>jm</dc:creator><description><![CDATA[DataStax' documentation on how they store TSD data in Cass.  Pretty generic]]></description>
<dc:subject>datastax nosql metrics analytics cassandra tsd time-series storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:307f55e4ee22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datastax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techo-ecco.com/blog/monitoring-apache-hadoop-cassandra-and-zookeeper-using-graphite-and-jmxtrans/">
    <title>Monitoring Apache Hadoop, Cassandra and Zookeeper using Graphite and JMXTrans</title>
    <dc:date>2013-03-06T10:34:40+00:00</dc:date>
    <link>http://techo-ecco.com/blog/monitoring-apache-hadoop-cassandra-and-zookeeper-using-graphite-and-jmxtrans/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[nice enough, but a lot of moving parts.  It would be nice to see a simpler ZK+Graphite setup using the 'mntr' verb]]></description>
<dc:subject>graphite monitoring ops zookeeper cassandra hadoop jmx jmxtrans graphs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b5aa3112e5b1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zookeeper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmxtrans"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techblog.netflix.com/2013/02/netflix-queue-data-migration-for-high.html">
    <title>Netflix Queue: Data migration for a high volume web application</title>
    <dc:date>2013-03-06T09:46:52+00:00</dc:date>
    <link>http://techblog.netflix.com/2013/02/netflix-queue-data-migration-for-high.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>There will come a time in the life of most systems serving data, when there is a need to migrate data to [another] data store while maintaining or improving data consistency, latency and efficiency. This document explains the data migration technique we used at Netflix to migrate the user’s queue data between two different distributed NoSQL storage systems [SimpleDB to Cassandra].</blockquote>

]]></description>
<dc:subject>cassandra netflix migrations data schema simpledb storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d3773b000a99/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schema"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simpledb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.odbms.org/blog/2013/02/big-data-analytics-at-netflix-interview-with-christos-kalantzis-and-jason-brown/">
    <title>Big Data Analytics at Netflix. Interview with Christos Kalantzis and Jason Brown.</title>
    <dc:date>2013-02-25T22:07:17+00:00</dc:date>
    <link>http://www.odbms.org/blog/2013/02/big-data-analytics-at-netflix-interview-with-christos-kalantzis-and-jason-brown/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good interview with the Cassandra guys at Netflix, and some top Mongo-bashing in the comments]]></description>
<dc:subject>cassandra netflix user-stories testimonials nosql storage ec2 mongodb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:979bc48e6cf8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:user-stories"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testimonials"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mongodb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.markedup.com/2013/02/cassandra-hive-and-hadoop-how-we-picked-our-analytics-stack/">
    <title>Cassandra, Hive, and Hadoop: How We Picked Our Analytics Stack</title>
    <dc:date>2013-02-25T15:35:01+00:00</dc:date>
    <link>http://blog.markedup.com/2013/02/cassandra-hive-and-hadoop-how-we-picked-our-analytics-stack/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[reasonably good whole-stack performance testing and analysis; HBase, Riak, MongoDB, and Cassandra compared.  Riak did pretty badly :(]]></description>
<dc:subject>riak mongodb cassandra hbase performance analytics hadoop hive big-data storage databases nosql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b335abec7a75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mongodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hbase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/adrianco/arch-tutoriallo2of3">
    <title>Cloud Architecture Tutorial - Platform Component Architecture (2of3)</title>
    <dc:date>2012-03-14T00:08:44+00:00</dc:date>
    <link>http://www.slideshare.net/adrianco/arch-tutoriallo2of3</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazing stuff from Adrian Cockroft at last week's QCon.  Faceted object model, lots of Cassandra automation]]></description>
<dc:subject>cassandra api design oo object-model java adrian-cockroft slides qcon scaling aws netflix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:047c60818c5c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-model"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:adrian-cockroft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qcon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html">
    <title>Benchmarking Cassandra Scalability on AWS - Over a million writes per second</title>
    <dc:date>2011-11-03T22:58:25+00:00</dc:date>
    <link>http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[NetFlix' benchmarks -- impressively detailed.  '48, 96, 144 and 288 instances', across 3 EC2 AZs in us-east, successfully scaling linearly]]></description>
<dc:subject>ec2 aws cassandra scaling benchmarks netflix performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5f9c3bbde44/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://news.ycombinator.com/item?id=2434187">
    <title>Hacker News | Copy-on-write B-tree finally beaten</title>
    <dc:date>2011-04-13T21:45:40+00:00</dc:date>
    <link>http://news.ycombinator.com/item?id=2434187</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting discussion ]]></description>
<dc:subject>algorithms database data-structures b-trees hacker-news cassandra</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:5576a3613ad1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b-trees"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacker-news"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/kevinweil/nosql-at-twitter-nosql-eu-2010">
    <title>NoSQL at Twitter (NoSQL EU 2010) [PDF]</title>
    <dc:date>2010-04-22T10:33:14+00:00</dc:date>
    <link>http://www.slideshare.net/kevinweil/nosql-at-twitter-nosql-eu-2010</link>
    <dc:creator>jm</dc:creator><description><![CDATA[specifically, Hadoop and Pig for log/metrics analytics, Cassandra going forward; great preso, lots of detail and code examples.   also, impressive number-crunching going on at Twitter]]></description>
<dc:subject>twitter analytics cassandra databases hadoop pdf logs metrics number-crunching nosql pig presentation slides scribe</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:29181b7623c2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:number-crunching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scribe"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ewh.ieee.org/r6/scv/computer//nfic/2009/IBM-Jun-Rao.pdf">
    <title>BlueRunner: Email in the Cloud with Cassandra [PDF]</title>
    <dc:date>2010-04-15T11:14:59+00:00</dc:date>
    <link>http://ewh.ieee.org/r6/scv/computer//nfic/2009/IBM-Jun-Rao.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting prez from some IBM researchers on using Cassandra as a mail store, via Jeremy]]></description>
<dc:subject>via:jzawodny mail cassandra database data ibm nosql performance presentation pdf</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:6e9057ce7983/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jzawodny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ibm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>