Cassandra存储与优化-优快云博客

1.SSTable 的大小？取决于刷memtable到磁盘的时间间隔。
2.一个SSTable文件用一次从Memtable中写入？SSTable是只读的。
3.每个CF对应一个Memtable，当Memtable满足刷新条件后批量刷新数据存储到磁盘上的SSTable中，
下一次Memtable需要刷新到一个新的SSTable文件中，这也是保证SSTable中数据是按key的一定顺序排列的。
4.几个写时间瓶颈：
Memtable到阀值后flush到SSTable；
同一个CF的多个SSTable被合并成一个大的SSTable。
5.Write ConsistencyLevel的三种选择：
ONE:确保写入至少一个借点的commitlog和memtable
QUORUM:确保至少写入n/2+1个节点
ALL:确保写入n个节点,有单点失效问题。--?一个节点失效，将导致写失败
6.read
SSTable+Memtable +Bf+Idx
7.一组和MySQL对比的性能数据：
50GB
MySQL 300ms write 350ms read
Cassandra 0.12ms write 15ms read

20万条数据
Cassandra单线程 161125ms write 0.8ms/条
2658516ms read 13ms/条

SSTable是Sorted Strings Table的缩写

commitlog与cf的对应关系：无明确关系，为了减少IO竞争最好讲commitlog存储在单独的磁盘上。

-------------------------------------
Hinted Handoff：
KeyA按照规则首要写入节点N1,复制到N2
加入N1宕机，如果写入N2能够满足ConsistancyLevel要求，
则KeyA对应的RowMutation将封装一个带Hint信息的头部(包含了目标N1的信息）
然后随机的写入一个节点N3，此副本不可读。同时正常复制一份数据到N2，
此副本可以提供读。如果写N2不满足写一致性要求，则写会失败。
--？如果replication factor为大于等于三，是在写N2的同时再多复制一份到下一个
节点?
--?正常情况如果client连接的不是目标写入节点，此节点充当代理，完成首要节点数据的
写入，节点间再通过gossip同步数据。
流程：client写commitlog到代理节点（有可能是一个单独的磁盘，能够减少写SSTableIO竞争），
数据再以RowMutation的形式写入到首要写入节点。
--？随机写入的节点，数据与通常写数据到磁盘一样？写SSTable Index BloomFilter?

MerkleTree是一种HashTree，叶子节点是Key的hash值，父节点是所有叶子节点的hash值，
通过判断父节点的异同可以知道所有子节点的异同。
--？叶子节点是Key的hash值，那么一个CF中同一个Key对应的column value发生变化了，理论上hash值
确是没有变的，不合理？

执行nodetool repair可以启动Anti-Entropys，此操作是IO密集型操作。

-------------------------------------
数据分布策略：
RandomPartitioner
基于MD5的随机Hash分布。i*(2^127-1)/N
OrderPreservingPartitioner
基于Key值(UTF-8)的范围分布
CollatingOrderPreservingPartitioner
基于Key值(不同语言环境排序)的范围分布

-------------------------------------
数据复制：
DatacenterShardStategy
如果replication factor为N,则(N-1)%2的副本复制到不同的数据中心。
所有的副本在两个数据中心均衡分布。
--？
RackAwareStrategy
一个副本不知到不同的数据中心，其他副本复制到同数据中心的不同机架。
异地机房只保有一个副本，主要用于容灾。
RackUnAwareStrategy
不考虑复制节点的物理位置，一般是hash环右边的N-1个节点。

N个节点的数据是否最终都相同？

增加节点，bootstrap会根据initialToken自动从现有节点流到新加入的节点。
旧数据需要通过nodetool cleanup手工清理

替换一个节点：
先删除一个节点，再增加一个节点，需要启动两次bootstrap操作？

--cassandra的环怎么会封闭？
每个节点保存的数据的key的范围在(前一个节点的TOKEN,本节点的TOKEN]的半开半闭的区间内，
所有的节点首位相连，所以第一个节点保存大于最大token,小于等于最小token的数据。

如果节点短时间宕机，则只需要节点机器恢复后正常启动Cassandra即可，系统会自动讲
宕机期间的HintedHandoff数据写会该节点。
如果宕机时间较长，建议采用一台备用的机器作为新节点加入集群。

-------------------------------------
参数解释：
EndPointSnitch：集群节点对应物理机器分布策略，据此路由不同的数据副本。
InitialToken:初始化Token,具体key的第一份副本分布到哪个节点。
CommitLogDirectory：Commitlog文件存放的路径
DataFileDirectory:数据文件存放的路径，可以指定多个路径。
--？
RpcTimeoutInMillis:等待远程节点返回消息的超时设置。
CommitLogRotationThreshholdInMB:commitlog文件大小，超过则进行切换。
DiskAccessMode:磁盘访问模式。64位系统建议设置为mmap，或auto，32位则为standard
--？
RowWarningThresholdInMB:对超长的行进行告警，如果compact时行不能完全放入内存中，
Cassandra会崩溃，所以需要根据内存设置告警阀值。
compation时对整行数据进行反序列化，所以一行数据必须能够全部存放进内存中。
SliceBufferSizeInKB:读取连续列的缓存大小
FlushIndexBufferSizeInMB:刷新Memtable到磁盘索引文件的缓存大小
FlushDataBufferSizeInMB:刷新Memtable到磁盘索引文件的缓存大小
ColumnIndexSizeInKB:当一行长度超过该值时，添加一个列偏移索引。
MemtableThroughputInMB:Memtable大小
GCGraceSeconds:清理带有删除标记的垃圾数据的间隔时间。如果节点宕机
时间超过了这个间隔，则节点会永久失效，只能重新进行初始化后才能加入到集群
默认值为10天。

-------------------------------------
备份恢复：
利用nodetoolde snapshot命令可以生成SSTable的一个快照。
在生成snapshot前，先会执行一次Memtable切换，讲最新的数据保存为SSTable。
复制snapshot即可对节点的数据进行物理的备份。
snapshot实际上是SSTable文件的一个HardLink。
JSON2SSTable
SSTable2JSON

-------------------------------------
cassandra监控：
jconsole JMX地址：
service:jmx:rmi:///jndi/rmi://localhost:8080/jmxrmi
Nagios:
http://www.mahalo.com/how-to-monitor-cassandra-with-nagios
Cassandra web console:
http://github.com/suguru/cassandra-webconsole/downloads

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23937368/viewspace-1050664/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23937368/viewspace-1050664/