https://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archPartitionerAbout.html
上記Cassandraについてv3.0のドキュメント読んで調べたことをメモします。
実際に動かして確認しているわけではないので、間違いがあるかもしれません。お気づきの点はご指摘ください。
コンシステント・ハッシュ法とパーティション・キー
Cassandraはデータの分散にコンシステント・ハッシュ法を使っています。こちらのスライドで簡潔に説明されています。データ中の特定の部分（キー）をハッシュ関数にかけ、そのハッシュ値によってどのノードにデータを配置するかを決定します。
この方法を用いると、ノードの追加・削除時のデータ移動を少なく済ませられることが多いです。
コンシステント・ハッシュ法はデータを多数のノードに一様分散させる際の定番手法かと思います。
Cassandraにおいて、ハッシュにかけられるキーをパーティション・キー（partition key）と呼びます。設定によって変えられるようですが、基本的（デフォルト？）にはテーブルのプライマリー・キーがパーティション・キーになるようです。
CassandraではCREATE TABLE時にプライマリー・キーの指定が必須です。
テーブルのプライマリー・キーは、こちらで説明されているCassandraのデータモデルにおける、「ロウ」につける「キー」であると思われます。
Partitioner
さて、ここでパーティション・キーをハッシュにかける役割を担っているのがPartitionerです。「Murmur3Partitioner」「RandomPartitioner」「ByteOrderedPartitioner」の3つがあり、それぞれが異なるハッシュ関数をパーティション・キーに適用します。
Murmur3Partitioner
バージョン3.0でのデフォルトのPartitionerです。後述のRandomPartitionerが暗号化アルゴリズムを利用しているのに対し、こちらはより軽量なアルゴリズムを利用しているため、3～5倍高速にハッシュ値を算出できるようです。どちらを使った場合でも、ノード間のデータの分散は一様になります。
RandomPartitioner
Cassandra 1.2以前のデフォルトのPartitionerです。過去バージョンの互換性のために残されています。MD5ハッシュ関数を利用します。
ByteOrderedPartitioner
こちらも過去バージョンの互換性のために残されています。パーティション・キーの値そのものをハッシュ値として扱います。
Partitionerを一度決定してデータを格納すると、容易に他のPartitionerへの変更はできないようです。過去バージョンのデータを引き継ぐのでなければ、基本的にはバージョン3.0のデフォルトであるMurmur3Partitionerを使っておけば問題ないようです。