2016/3/18の「RDB技術者のためのNoSQLガイド」出版記念セミナーの懇親会で「Cassandraの紹介」発表者の原沢さんにいろいろ聞いてみたので、後で調べたこととも合わせて忘れないうちにメモ。
[Q1]Cassandraならではの罠はないか?
「書いたものがすぐには見えない」などCassandraに限らず一貫性を保証しないNoSQLアーキテクチャ特有の課題があることに注意が必要。
一貫性を保証しないが故に、「readよりwriteの方が速い」という結果になっているとのこと。
[Q2]事例では何万ものノードを使用しているものもあるが、本当にその規模までスケールできるのか?
現状では、1クラスタだと1000ノード程度までが限界。
Gossipプロトコルでノード間通信をしている(参考: ノード間のコミュニケーション（ゴシップ）)が、1000ノードくらいになるとネットワークが溢れる。
ただし、現在Appleがこれを改善しようと頑張っているとのこと。
通常はサービス単位や地域単位でクラスタを分けているのではないか。
[Q3]想定されるデータ量に対して、どの程度の規模のノードを見積ればよいのか?
最新(3.x)だと1ノード1TBくらいで見積もるとよい。旧バージョンだと500GBくらいとのこと。(1ノードで2-3TBほどさばけるとのことだが、replication factor = 3 とすると取り扱うデータ量の3倍のストレージが必要になるので、だいたい計算に合う)
その他 (後で調べたことも含む)
- read時に問い合わせる先のノードはクライアント側(のドライバ)が決定する。
- 直接データを持っているノードにリクエストすることも、空いているノードにリクエストしてそのノード経由で読み込むこともできる。
- 問い合わせはデータを持っている全てのノードに対して行う。高速なレスポンスが必要なら1つのノードから返ってきた段階で結果を返す、ある程度の整合性が必要なら複数のノードから返ってきた結果が一致したら結果を返す、といった指定が可能。
- 負荷分散やメモリ効率を考慮したデータ構造の設計が必要。
- Javaベースなので(?)、1つのレコード(?)に大量のカラムを詰め込むと、読み込み時に不要なカラムまでメモリに載ってきて効率が低下する。
- 特定のノードにのみ負荷が集中したりデータが肥大化したりする場合がある。(参考: Cassandraのデータ設計で注意していること)
- 検索はRDBのようにはいかず、主キー(?)以外のカラムを検索する場合はインデックスを張る必要があるが、公式ドキュメントに「どのような場合にインデックスを使用しないか」という記事まであるので一筋縄ではいかない模様。
- アーキテクチャの特性上、大量に発生するデータを取り扱う必要はあるが厳密な一貫性は求めないIoT関連での引き合いが多いとのこと。
- 有償版の価格はノード数(コア数?)に比例?
追加すべき点や修正すべき点がありましたらコメントをお願いします。