我参加了2016年3月18日举办的“为RDB技术人员准备的NoSQL指南”出版纪念研讨会的交流会，在那里我询问了介绍Cassandra的主讲人原沢先生一些问题，并及时将他的回答与后来调查的结果做了记录，以免忘记。

[Q1] 有没有Cassandra独有的陷阱？

需要注意的是，不仅仅是Cassandra，所有NoSQL架构都存在不保证一致性的特定问题，比如「写入的内容不能立即看到」。正因为不保证一致性，所以出现了”写入比读取快”的结果。

[Q2] 在一些例子中使用了成千上万个节点，但它真的能够扩展到那种规模吗？

目前，一个集群的上限大约是1000个节点。
节点之间通过Gossip协议进行通信（参考：节点间的通信（Gossip）），但当节点数量达到1000左右时，网络会被淹没。
不过，据说苹果目前正在努力改善这个问题。
通常情况下，集群可能是按照服务单位或地区单位划分的。

[Q3] 针对预定的数据量，需要估计何种规模的节点？

最新版本（3.x）的估计是每个节点大约需要1TB的空间。而旧版本则约为500GB。（虽然据说每个节点可以处理约2-3TB的数据，但如果设置复制因子=3，就需要比处理数据量多3倍的存储空间，所以大致计算是吻合的。）

其他（包括稍后查证的内容）

• read時に問い合わせる先のノードはクライアント側(のドライバ)が決定する。

直接データを持っているノードにリクエストすることも、空いているノードにリクエストしてそのノード経由で読み込むこともできる。
問い合わせはデータを持っている全てのノードに対して行う。高速なレスポンスが必要なら1つのノードから返ってきた段階で結果を返す、ある程度の整合性が必要なら複数のノードから返ってきた結果が一致したら結果を返す、といった指定が可能。

負荷分散やメモリ効率を考慮したデータ構造の設計が必要。

Javaベースなので(?)、1つのレコード(?)に大量のカラムを詰め込むと、読み込み時に不要なカラムまでメモリに載ってきて効率が低下する。
特定のノードにのみ負荷が集中したりデータが肥大化したりする場合がある。(参考: Cassandraのデータ設計で注意していること)

検索はRDBのようにはいかず、主キー(?)以外のカラムを検索する場合はインデックスを張る必要があるが、公式ドキュメントに「どのような場合にインデックスを使用しないか」という記事まであるので一筋縄ではいかない模様。
アーキテクチャの特性上、大量に発生するデータを取り扱う必要はあるが厳密な一貫性は求めないIoT関連での引き合いが多いとのこと。
有償版の価格はノード数(コア数?)に比例?

如果有需要添加或修正的地方，请在评论中提出意见。