1 数据存储方式和NoSQL
1.1 数据存储方式
互联网时代各种数据存储方式层出不穷，有传统的关系性数据库如：MySQL、Oracle等，；有全文检索框架如：ElasticSearch、Solr；有NoSQL如：Cassandra、Redis
这些存储方式的特点：
- 关系型数据库：支持事务，二级索引，SQL语句，支持主从架。
- 全文检索：分布式，p2p架构，不支持事务，采用倒排索引提供全文检索。
- NoSQL：一般基于内存，支持分布式，面向列，不支持SQL。
1.2 NoSQL概述
NoSQL，泛指非关系型的数据库，NoSQL去掉关系数据库的关系型特性，数据之间无关系，非常容易扩展。
NoSQL型数据库一般包含一些共同特性：
- 易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展，在架构的层面上带来了可扩展的能力。
- 大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下。一般MySQL使用Query Cache。NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说性能就要高很多。
- 灵活的数据模型
NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。
- 高可用
NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用。
1.3 NoSQL的分类
键值(Key-Value)存储数据库
这一类数据库主要使用[哈希表]，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型的优势在于简单、易部署。代表为： Redis。
列存储数据库
这类数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家组来安排的。如：Cassandra， HBase。
文档型数据库
文档型数据库和第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值，在处理网页等复杂数据时，文档型数据库比传统键值数据库的查询效率更高。如：CouchDB， MongoDb。
图形(Graph)数据库
图形结构的数据库同其他行列以及关系型数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。
2 Cassandra的介绍
2.1、Cassandra概述
Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩展性，被Digg、Twitter等知名Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。
2.2 Cassandra的官网
Cassandra在2009年成为了Apache软件基金会的Incubator项目，并在2010年2月走出孵化器，成为正式的基金会项目。
2.3 Cassandra特点
- 弹性可扩展性 - Cassandra是高度可扩展的; 它允许添加更多的硬件以适应更多的客户和更多的数据根据要求。
- 始终基于架构 - Cassandra没有单点故障，它可以连续用于不能承担故障的关键业务应用程序。
- 快速线性性能 - Cassandra是线性可扩展性的，即它为你增加集群中的节点数量增加你的吞吐量。因此，保持一个快速的响应时间。
- 灵活的数据存储 - Cassandra适应所有可能的数据格式，包括：结构化，半结构化和非结构化。它可以根据您的需要动态地适应变化的数据结构。
- 便捷的数据分发 - Cassandra通过在多个数据中心之间复制数据，可以灵活地在需要时分发数据。
- 事务支持 - Cassandra支持属性，如原子性，一致性，隔离和持久性（ACID）。
- 快速写入 - Cassandra被设计为在廉价的商品硬件上运行。 它执行快速写入，并可以存储数百TB的数据，而不牺牲读取效率。
2.4 Cassandra使用场景
2.4.1 特征
- 数据写入操作密集
- 数据修改操作很少
- 通过主键查询
- 需要对数据进行分区存储
2.4.2 场景举例
- 存储日志型数据
- 类似物联网的海量数据
- 对数据进行跟踪
3 Cassandra下载、安装、访问
3.1 Cassandra下载
https://cassandra.apache.org/_/download.html
https://archive.apache.org/dist/cassandra/
3.2 配置Cassandra
Cassandra依赖JDK，需要提前配置好java环境变量
1、解压安装包
tar -xf apache-cassandra-3.11.16-bin.tar.gz -C /app/module
cd /app/module
mv apache-cassandra-3.11.16 cassandra
mkdir -p /data/cassandra/data /data/cassandra/commitlog /data/cassandra/saved_caches
2、修改配置文件
cd /app/module/cassandra/conf
vim cassandra.yaml
cluster_name: 'Cluster Name'
authenticator: PasswordAuthenticator
data_file_directories
- /data/cassandra/data
commitlog_directory: /data/cassandra/commitlog
saved_caches_directory: /data/cassandra/saved_caches
start_rpc: true
rpc_address: 本机业务IP
cas_contention_timeout_in_ms: 10000
3、启动服务
/app/module/cassandra/bin/cassandra
意思是官方不推荐使用root用户或组来运行Cassandra，请使用其他系统用户来启动Cassandra。
如果就是想用root用户来启动，可以在命令后面加上-R，也就是使用root用户启动的命令是/app/module/cassandra/bin/cassandra -R
4、验证
/app/module/cassandra/bin/cqlsh -u cassandra -p cassandra 本机业务IP 9042
5、重新设置cassandra密码
alter user cassandra with password 'newPassword';3.3 数据分类
cassandra的数据分为3类，这3类数据的存储位置都可以在配置文件中修改
data目录:用于存储真正的数据文件，即后面将要讲到的SSTable文件。如果服务器有多个磁盘，可以指定多个目录，每一个目录都在不同的磁盘中。这样Cassandra就可以利用更多的硬盘空间。
在data目录下，Cassandra 会将每一个 Keyspace 中的数据存储在不同的文件目录下，并且 Keyspace 文件目录的名称与 Keyspace 名称相同。
假设有两个 Keyspace，分别为 ks1 和 ks2，但在 data目录下，将看到3个不同的目录：ks1，ks2和 system。其中 ks1 和 ks2 用于存储系统定义的两个 Keyspace 的数据，另外一个 system 目录是 Cassandra 系统默认的一个 Keyspace，叫做 system，它用来存储 Cassandra 系统的相关元数据信息以及 HINT 数据信息。
commitlog目录: 用于存储未写人SSTable中的数据，每次Cassandra系统中有数据写入，都会先将数据记录在该日志文件中，以保证Cassandra在任何情况下宕机都不会丢失数据。如果服务器有足够多的磁盘，可以将本目录设置在一个与data目录和cache目录不同的磁盘中，以提升读写性能。
cache目录: 用于存储系统中的缓存数据。可以在cassandra. yaml文件中定义Column Family的属性中定义与缓存相关的信息，如缓存数据的大小(对应配置文件中的keys_cached和rOws_ cached)、 持久化缓存数据的时间间隔(对应配置文件中的row cache_save_ period in. seconds 和key. cache save period in seconds)等。当Cassandra系统重启的时候，会从该目录下加载缓存数据。如果服务器有足够多的磁盘空间，可以将本目录设置在一个与data目录和commitlog目录不同的磁盘中，以提升读写性能。
3.4 配置启动脚本
#!/bin/sh
CASSANDRA_DIR="/app/module/cassandra"
echo "************cassandra***************"
case "$1" in
start)
echo "* *"
echo "* starting *"
nohup $CASSANDRA_DIR/bin/cassandra -R >> $CASSANDRA_DIR/logs/system.log 2>&1 &
echo "* started *"
echo "* *"
echo "************************************"
;;
stop)
echo "* *"
echo "* stopping *"
PID_COUNT=`ps aux |grep CassandraDaemon |grep -v grep | wc -l`
PID=`ps aux |grep CassandraDaemon |grep -v grep | awk {'print $2'}`
if [ $PID_COUNT -gt 0 ];then
echo "* try stop *"
kill -9 $PID
echo "* kill SUCCESS! *"
else
echo "* there is no ! *"
echo "* *"
echo "************************************"
fi
;;
restart)
echo "* *"
echo "********* restarting ******"
$0 stop
$0 start
echo "* *"
echo "************************************"
;;
status)
$CASSANDRA_DIR/bin/nodetool status
;;
*)
echo "Usage:$0 {start|stop|restart|status}"
exit 1
esac3.5 Cassandra的端口
7199 - JMX
7000 - 节点间通信（如果启用了TLS，则不使用）
7001 - TLS节点间通信（使用TLS时使用）
9160 - Thrift客户端API
9042 - CQL本地传输端口4 附录配置文件
cluster_name
集群的名字，默认情况下是TestCluster。
对于这个属性的配置可以防止某个节点加入到其他集群中去，所以一个集群中的节点必须有相同的cluster_name属性。
initial_token
Cassandra服务器的初始化Token值，这个值代表了Cassandra服务器在一致性哈希环中的位置。
当Cassandra第一次启动的时候，会从该配置项中读取，如果留空，将随机生成一个Token值。
如果Cassandra不是第一次启动，将从系统表中读取该Token值。
auto_bootstrap
第一次启动的时候，是否在加入Cassandra集群时从其他服务器获取属于本服务器的数据。
如果当前Cassandra服务器不在seed配置选项中，并且是第一次启动，将从Cassandra集群中其他服务器获取属于本服务器的数据。
hinted_handoff_enabled
是否开启当前Cassandra服务器的HINT操作。
如果开启该功能，Cassandra服务器将缓存发送给暂时失效的其他Cassandra服务器的数据，等待失效的服务器恢复后，再将缓存的数据发送给恢复的服务器。
authenticator
验证使用Cassandra的用户是否合法，这是安全认证的第一步。
Cassandra中定义了一系列验证用户的策略，可以选择的项为：
1. org.apache.cassandra.auth.AllowAllAuthenticator
所有的用户都是合法的。
2. org.apache.cassandra.auth.SimpleAuthenticator
合法的用户和对应的密码都在passwd.properties文件中定义。
authority
验证该用户是否具备操作某一个Column Family的权限，这是安全认证的第一步。
Cassandra中定义了一系列验证用户权限的策略，可以选择的项为：
1. org.apache.cassandra.auth.AllowAllAuthority
所有的用户具备所有的权限。
2. org.apache.cassandra.auth.SimpleAuthority
合法的用户和对应的权限都在access.properties文件中定义。
listen_address
Cassandra需要监听的IP或主机名，默认是localhost。建议配置私有IP，不要用0.0.0.0。
commitlog_directory
commit log的保存目录，压缩包安装方式默认是/var/lib/cassandra/commitlog。
通过前面的了解，我们可以知道，把这个目录和数据目录分开存放到不同的物理磁盘可以提高性能。
data_file_directories
数据文件的存放目录，压缩包安装方式默认是/var/lib/cassandra/data。为了更好的效果，建议使用RAID 0或SSD。
save_caches_directory
保存表和行的缓存，压缩包安装方式默认是/var/lib/cassandra/saved_caches。
通常使用：用得比较频繁的属性
在启动节点前，需要仔细评估你的需求。
commit_failure_policy
提交失败时的策略（默认stop）：
stop：关闭gossip和Thrift，让节点挂起，但是可以通过JMX进行检测。
sto_commit：关闭commit log，整理需要写入的数据，但是提供读数据服务。
ignore：忽略错误，使得该处理失败。
disk_failure_policy
设置Cassandra如何处理磁盘故障（默认stop）。
stop：关闭gossip和Thrift，让节点挂起，但是可以通过JMX进行检测。
stop_paranoid：在任何SSTable错误时就闭gossip和Thrift。
best_effort：这是Cassandra处理磁盘错误最好的目标。
如果Cassandra不能读取磁盘，那么它就标记该磁盘为黑名单，可以继续在其他磁盘进行写入数据。
如果Cassandra不能从磁盘读取数据，那个这些SSTable就标记为不可读，其他可用的继续堆外提供服务。
所以就有可能在一致性水平为ONE时会读取到过期的数据。
ignore：用于升级情况。
endpoint_snitch
用于设置Cassandra定位节点和路由请求的snitch
(默认org.apache.cassandra.locator.SimpleSnitch)，必须设置为实现了IEndpointSnitch的类。
rpc_address 一般填写本机ip
用于监听客户端连接的地址。可用的包括：
0.0.0.0监听所有地址
IP地址
主机名
不设置：使用hosts文件或DNS
rpc_port
Cassandra服务器对外提供服务的端口号。
seed_provider
需要联系的节点地址。Cassandra使用-seeds集合找到其他节点并学习其整个环中的网络拓扑。
class_name：
(默认org.apache.cassandra.locator.SimpleSeedProvider)，可用自定义，但通常不必要。
seeds
Cassandra集群中的种子节点地址
这个选项可以设置多个值，即Cassandra集群中有多个种子节点。
集群中所有的服务器在启动的时候，都将于seed节点进行通信，从而获取集群的相关信息。
如果某一台服务器被设置为seed节点，那么在启动的时候，将自动加入集群，并且不会执行Bootstrap的操作，即无法从集群的其他节点中获取相应的数据。
compaction_throughput_mb_per_sec
限制特定吞吐量下的压缩速率。如果插入数据的速度越快，越应该压缩SSTable减少其数量。
推荐16-32倍于写入速度（MB/s）。如果是0表示不限制。
memtable_total_space_in_mb
指定节点中memables最大使用的内存数（默认1/4heap）。
concurrent_reads
（默认32）读取数据的瓶颈是在磁盘上，设置16倍于磁盘数量可以减少操作队列。
concurrent_writes
（默认32）在Cassandra里写很少出现I/O不稳定，所以并发写取决于CPU的核心数量。推荐8倍于CPU数。
incremental_backups
（默认false）最后一次快照发生时备份更新的数据（增量备份）。
当增量备份可用时，Cassandra创建一个到SSTable的的硬链接或者流式存储到本地的备份/子目录。删除这些硬链接是操作员的责任。
snapshot_before_compaction
（默认false）启用或禁用在压缩前执行快照。这个选项在数据格式改变的时候来备份数据是很有用的。
注意使用这个选项，因为Cassandra不会自动删除过期的快照。
phi_convict_threshold
（默认8）调整失效检测器的敏感度。
较小的值增加了把未响应的节点标注为挂掉的可能性，反之就会降低其可能性。
在不稳定的网络环境下（比如EC2），把这个值调整为10或12有助于防止错误的失效判断。大于12或小于5的值不推荐！
性能调优
commit_sync
（默认：periodic）Cassandra用来确认每毫秒写操作的方法。
periodic：
和commitlog_sync_period_in_ms（默认10000 – 10 秒）一起控制把commit log同步到磁盘的频繁度。周期性的同步会立即确认。
batch：和commitlog_sync_batch_window_in_ms（默认disabled）一起控制Cassandra在执行同步前要等待其他写操作多久时间。
当使用该方法时，写操作在同步数据到磁盘前不会被确认。
commitlog_periodic_queue_size
（默认1024*CPU的数量）commit log队列上的等待条目。当写入非常大的blob时，请减少这个数值。
比如，16倍于CPU对于1MB的Blob工作得很好。这个设置应该至少和concurrent_writes一样大。
commitlog_segment_size_in_mb
（默认32）设置每个commit log文件段的大小。
一个commit log段在其所有数据刷新到SSTable后可能会被归档、删除或回收。
数据的总数可以潜在的包含系统中所有表的commit log段。
默认值适合大多数情况，当然你也可以修改，比如8或16MB。
commitlog_total_space_in_mb
（默认32位JVM为32,64位JVM为1024）commit log使用的总空间。
如果使用的空间达到以上指定的值，Cassandra进入下一个临近的部分，或者把旧的commit log刷新到磁盘，删除这些日志段。
该个操作减少了在启动时加载过多数据引起的延迟，防止了把无限更新的表保存到有限的commit log段中。
compaction_preheat_key_cache
（默认true）当设置为true的时候，缓存的row key在压缩期间被跟踪，并且重新缓存其在新压缩的SSTable中的位置。
如果有极其大的key要缓存，把这个值设为false。
concurrent_compactors
（默认每个CPU一个）设置每个节点并发压缩处理的值，不包含验证修复逆商。
并发压缩可以在混合读写工作下帮助保持读的性能——通过减缓把一堆小的SSTable压缩而进行的长时间压缩。
如果压缩运行得太慢或太快，请首先修改compaction_throughput_mb_per_sec的值。
in_memory_compaction_limit_in_mb
（默认64）针对数据行在内存中的压缩限制。超大的行会溢出磁盘并且使用更慢的二次压缩。
当这个情况发生时，会对特定的行的key记录一个消息。推荐5-10%的Java对内存大小。
multithreaded_compaction
（默认false）当设置为true的时候，每个压缩操作使用一个线程，一个线程用于合并SSTable。典型的，这个只在使用SSD的时候有作用。
使用HDD的时候，受限于磁盘I/O（可参考compaction_throughput_mb_per_sec）。
preheat_kernel_page_cache
（默认false） 启用或禁用内核页面缓存预热压缩后的key缓存。
当启用的时候会预热第一个页面（4K）用于由每个数据行的顺序访问。对于大的数据行通常是有危害的。
file_cache_size_in_mb
（小于1/4堆内存或512）用于SSTable读取的缓存内存大小。
memtable_flush_queue_size
（默认4）等待刷新的满的memtable的数量（等待写线程的memtable）。最小是设置一个table上索引的最大数量。
memtable_flush_writers
（默认每数据目录一个）设置用于刷新memtable的线程数量。
这些线程是磁盘I/O阻塞的，每个线程在阻塞的情况下都保持了memtable。
如果有大的堆内存和很多数据目录，可以增加该值提升刷新性能。
column_index_size_in_kb
（默认64）当数据到达这个值的时候添加列索引到行上。这个值定义了多少数据行必须被反序列化来读取列。如果列的值很大或有很多列，那么就需要增加这个值。
populate_io_cache_on_flush
（默认false）添加新刷新或压缩的SSTable到操作系统的页面缓存。
reduce_cache_capacity_to
（默认0.6）设置由reduce_cache_sizes_at定义的Java对内存达到限制时的最大缓存容量百分比。
reduce_cache_sizes_at
（默认0.85）当Java对内存使用率达到这个百分比，Cassandra减少通过reduce_cache_capacity_to定义的缓存容量。禁用请使用1.0。
stream_throughput_outbound_megabits_per_sec
（默认200）限制所有外出的流文件吞吐量。Cassandra在启动或修复时使用很多顺序I/O来流化数据，这些可以导致网络饱和以及降低RPC的性能。
trickle_fsync
（默认false）当使用顺序写的时候，启用该选项就告诉fsync强制操作系统在trickle_fsync_interval_in_kb设定的间隔刷新脏缓存。建议在SSD启用。
trickle_fsync_interval_in_kb
（默认10240）设置fsync的大小
