CASSANDRA学习笔记 （三） 创建keyspace 键空间

cassandra的键空间（keyspace）相当于数据库，我们创建一个键空间即是创建了一个数据库。

语句

CREATE KEYSPACE <identifier> WITH <properties>

CREATE KEYSPACE语句有两个属性：replication和durable_writes。

这里我们先学习一下repication的概念：

 （1）什么是Replication?

在Cassandra中，Replication是存储数据的到多个节点来保证可靠性和出错容忍性。当你创建一个keyspace时候（相当于关系数据库中的表）的时候，就必须给出一个副本放置策略 （Replica Placement Strategy)

（2）什么是副本因子(Replica Factor)？

这个数决定了有几份副本，比如如果设置为1，则表示每一行只有一个副本，以此类推。所有的副本地位都是相等的， 没有主从之分。注意，副本因子最多不可以超过节点的数量，（没这么多节点让你放这么多副本）否则写操作会被拒绝。

（3）什么是副本放置策略（Replica Placement Strategy)?

这个策略决定了一个keyspace的副本如何放置在集群中（当创建keyspace时候就指定了）

a.简单策略(SimpleStrategy):

当使用Cassandra CLI 命令行工具创建keyspace时的默认副本放置策略。假定根据partitioner得到第一个节点设为N1，它的顺时针的节点为N2，N3...则这种策略会把keyspace的第一个副本放置在N1上，然后其他副本依次放置在N2，N3..上

 

b.网络拓扑策略(NetworkTopologyStrategy):

这种策略用于当你知道节点如何在数据中心(Data Center 我理解为物理上在同个机房/网段的机器组)分组的情况或者你希望部署集群横跨多个数据中心，此时你必须指定每个数据中心要多少个副本，(一般推荐设为2或者3）。在这种情况下，副本放置策略由数据中心自己决定。具体为，先由partitioner决定第一个node设为N1，在架子(rack1)上，属于数据中心DC1，则第一个副本放在N1，其他副本也必须分别放在DC1中，优先选择不是rack1的架子，如果没有其他rack，则只能放在rack1上。

比如如图所示，现在有两个数据中心，蓝色表示DC1，绿色表示DC2，DC1上有2个架子，分别是Rack1和Rack2。则如果partitioner选择的第一个节点是DC1的节点N3的话，那么副本R1就放在DC1的节点N3 上，而这个副本的下一个副本R2就放在同一个DC，也就是DC1的下一个rack上（如果有），它刚好发现，顺时针的下一个节点N4刚好也是DC1，但是是另外一个架子(Rack2),所以副本R2放在N4上。对于属于DC2的2个副本也遵循同样的策略。

 

现在我们可以回来看创建keyspace时的第一个属性：replication

replication（复制策略）

复制选项用于指定副本位置策略和所需副本的数量。下表列出了所有副本位置策略。

策略名称	描述
简单的策略	为集群指定简单的副本因子（有几个副本）。
网络拓扑策略	使用此选项，可以单独为每个数据中心设置复制因子。
旧网络拓扑策略	使用此选项，可以单独为每个数据中心设置复制因子。（是否已弃用？）

使用此选项，您可以选择Cassandra是否对当前KeySpace的更新使用commitlog，默认为true。 （commitlog的概念后续补充）

 

示例

下面给出了创建KeySpace的示例。

• 这里我们创建一个名为TutorialsPoint 的KeySpace。

• 我们使用第一个副本放置策略，即简单策略。

• 我们选择复制因子为1个副本。

cqlsh.> CREATE KEYSPACE tutorialspoint
WITH replication = {'class':'SimpleStrategy', 'replication_factor' : 1};

验证

可以使用命令Describe验证是否创建表。

 

接下来我们看第二各属性：Durable_writes

设置Cassandra是否对当前KeySpace的更新使用commitlog，默认为true。如果设为false，则请求直接写memTable，有可能有数据丢失风险。

 

此时补充学习一下cassandra的存储机制，了解一下commitlog是什么概念：

 

存储机制

Cassandra的存储机制借鉴了Bigtable的设计，采用Memtable和SSTable的方式。

CommitLog

和HBase一样，Cassandra在写数据之前，也需要先记录日志，称之为Commit Log，然后数据才会写入到Column Family对应的MemTable中，且MemTable中的数据是按照key排序好的。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。（我理解，cassandra对数据的三级操作第一步写日志是为了快速同步到多个副本，第二步和第三步的拆分是因为新的数据更容易变化，所以使用memTable暂存，最后写入SSTable时，每个SSTable文件都不可以再被修改，因此利用了磁盘顺序写的性能）

 

MenTable

MemTable是一种内存结构，当数据量达到块大小时，将批量flush到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。所以我们可以认为Cassandra中只有顺序写操作，没有随机写操作。

 

SSTable

SSTable是Read Only的，且一般情况下，一个CF会对应多个SSTable，当用户检索数据时，Cassandra使用了Bloom Filter，即通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。

为了减少大量SSTable带来的开销，Cassandra会定期进行compaction，简单的说，compaction就是将同一个CF的多个SSTable合并成一个SSTable（就是根据数据变动记录，定期整理和合并数据嘛）。在Cassandra中，compaction主要完成的任务是：

1） 垃圾回收： cassandra并不直接删除数据，因此磁盘空间会消耗得越来越多，compaction 会把标记为删除的数据真正删除；

2） 合并SSTable：compaction 将多个 SSTable 合并为一个（合并的文件包括索引文件（这里需要查一下cassandra的索引原理），数据文件，bloom filter文件），以提高读操作的效率；

3） 生成 MerkleTree：在合并的过程中会生成关于这个 CF 中数据的 MerkleTree，用于与其他存储节点对比以及修复数据。

 

示例

下面给出了示例持久写入属性的使用示例。

cqlsh> CREATE KEYSPACE test
... WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 }
... AND DURABLE_WRITES = false;

可以用以下语句验证DURABLE_WRITES属性是否设置成功。

SELECT * FROM system.schema_keyspaces;