NinGoo's blog

Cassandra Commitlog

上一篇blog中，大致介绍了一下Cassandra的存储机制，通过将最新的写操作放在内存中的Memtable，然后定期刷新到磁盘持久化为SSTable，Cassandra将随机写操作转换成了顺序写操作，这可以提升IO性能。

最新写入的脏数据是在内存Memtable表中，因此必须有机制来确保异常情况下，能够将内存中的数据恢复出来。和关系型数据库系统一样，Cassandra也是采用的先写日志再写数据的方式，其日志称之为Commitlog。

和Memtable/SSTable不一样的是，Commitlog是server级别的，不是Column Family级别的。每个Commitlog文件的大小是固定的，称之为一个Commitlog Segment，目前版本(0.5.1)中，这个大小是128MB，这是硬编码在代码(src\java\org\apache\cassandra\db\Commitlog.java)中的。当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自动清除。

每个Commitlog文件(Segment)都有一个固定大小（大小根据Column Family的数目而定）的CommitlogHeader结构，其中有两个重要的数组，每一个Column Family在这两个数组中都存在一个对应的元素。其中一个是位图数组(BitSet dirty)，如果Column Family对应的Memtable中有脏数据，则置为1，否则为0，这在恢复的时候可以指出哪些Column Family是需要利用Commitlog进行恢复的。另外一个是整数数组(int[] lastFlushedAt)，保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。通过这两个数组结构，Cassandra可以在异常重启服务的时候根据持久化的SSTable和Commitlog重构内存中Memtable的内容，也就是类似Oracle等关系型数据库的实例恢复。

当Memtable flush到磁盘的SStable时，会将所有Commitlog文件的dirty数组对应的位清零，而在Commitlog达到大小限制创建新的文件时，dirty数组会从上一个文件中继承过来。如果一个Commitlog文件的dirty数组全部被清零，则表示这个Commitlog在恢复的时候不再需要，可以被清除。因此，在恢复的时候，所有的磁盘上存在的Commitlog文件都是需要的。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureCommitLog

Cassandra存储机制

在2009年兴起的NoSQL运动中，Cassandra是其中重要的一个分布式key-value数据库产品，由Facebook在2008年开源，目前是Apache的顶级项目。最近twitter的一篇声明，表示将从MySQL迁移到Cassandra，更让其声名大振。Cassandra是结合了Google Bigtable的数据模型和Amazon Dynamo高可用框架的一个产品。其数据模型可以参考张瑞的blog。

值得说一下的是Cassandra的存储机制，也是借鉴了Bigtable的设计，采用Memtable和SSTable的方式。和关系数据库一样，Cassandra在写数据之前，也需要先记录日志，称之为commitlog，然后数据才会写入到Column Family对应的Memtable中，并且Memtable中的内容是按照key排序好的。Memtable是一种内存结构，满足一定条件后批量刷新到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

因为SSTable数据不可更新，可能导致同一个Column Family的数据存储在多个SSTable中，这时查询数据时，需要去合并读取Column Family所有的SSTable和Memtable，这样到一个Column Family的数量很大的时候，可能导致查询效率严重下降。因此需要有一种机制能快速定位查询的Key落在哪些SSTable中，而不需要去读取合并所有的SSTable。Cassandra采用的是Bloom Filter算法，通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。关于Bloom Filter，有兴趣的可以去看看参考文章4,5和6。

为了避免大量SSTable带来的性能影响，Cassandra也提供一种定期将多个SSTable合并成一个新的SSTable的机制，因为每个SSTable中的key都是已经排序好的，因此只需要做一次合并排序就可以完成该任务，代价还是可以接受的。所以在Cassandra的数据存储目录中，可以看到三种类型的文件，格式类似于：

• Column Family Name-序号-Data.db
• Column Family Name-序号-Filter.db
• Column Family Name-序号-index.db

其中Data.db文件是SSTable数据文件，SSTable是Sorted Strings Table的缩写，按照key排序后存储key/value键值字符串。index.db是索引文件，保存的是每个key在数据文件中的偏移位置，而Filter.db则是Bloom Filter算法生产的映射文件。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureOverview
[2].http://wiki.apache.org/cassandra/MemtableSSTable
[3].http://wiki.apache.org/cassandra/ArchitectureSSTable
[4].http://blog.csdn.net/jiaomeng/archive/2007/01/27/1495500.aspx
[5].http://www.hellodba.net/2009/04/bloom_filter.html
[6].http://www.googlechinablog.com/2007/07/bloom-filter.html
[7].http://labs.google.com/papers/bigtable.html

CAP原理与最终一致性

CAP原理(CAP Theorem)

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：

• 一致性(Consistency)
• 可用性(Availability)
• 分区容忍性(Partition tolerance)

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

• 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
• “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
• 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
• 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
• 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

• N — 数据复制的份数
• W — 更新数据是需要保证写完成的节点数
• R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

• 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
• 如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

参考文章：
[1].http://devblog.streamy.com/2009/08/24/cap-theorem/
[2].http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
[3].http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
[4].http://www.infoq.com/cn/news/2008/01/consistency-vs-availability

dstat:一款简单直观的os实时监控工具

在oschina上闲逛，发现一款不错的os实时监控工具dstat，整合了vmstat, iostat, ifstat, netstat等常见os监控工具的优点，输出的结果简单直观，并且结果可以保存到csv文件，这样再写一个简单的perl脚本，就能将os的主要监控信息一次性全部抓取出来，保存到监控数据库中用于分析展示。试用了一下觉得非常不错，因此在这里分享一下这个用python写的工具。

$dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
 22   2  74   0   0   2|   0   416k| 621k  219k|   0     0 |1158    26k
 23   3  72   0   0   2|  64k  484k|  11k   11k|   0     0 |1109    30k
 21   3  75   0   0   2|4096B  416k|  77k   77k|   0     0 |2104    25k
 29   4  66   0   0   2|   0  1240k| 996k  425k|   0     0 |1350    28k

$dstat -ta --output osstat.csv
-----time----- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
  date/time   |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
05-02 11:37:08|  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
05-02 11:37:09| 16   4  78   0   0   3|   0  1404k|1478k  939k|   0     0 |4316    33k
05-02 11:37:10| 20   2  76   0   0   2|   0  1144k|1109k  828k|   0     0 |5653    28k
05-02 11:37:11| 13   2  83   0   0   2|   0   588k|2590k 1684k|   0     0 |4256    23k

$dstat -h
Usage: dstat [-afv] [options..] [delay [count]]
Versatile tool for generating system resource statistics

Dstat options:
  -c, --cpu              enable cpu stats
     -C 0,3,total           include cpu0, cpu3 and total
  -d, --disk             enable disk stats
     -D total,hda           include hda and total
  -g, --page             enable page stats
  -i, --int              enable interrupt stats
     -I 5,eth2              include int5 and interrupt used by eth2
  -l, --load             enable load stats
  -m, --mem              enable memory stats
  -n, --net              enable network stats
     -N eth1,total          include eth1 and total
  -p, --proc             enable process stats
  -s, --swap             enable swap stats
     -S swap1,total         include swap1 and total
  -t, --time             enable time/date output
  -T, --epoch            enable time counter (seconds since epoch)
  -y, --sys              enable system stats
  --ipc                  enable ipc stats
  --lock                 enable lock stats
  --raw                  enable raw stats
  --tcp                  enable tcp stats
  --udp                  enable udp stats
  --unix                 enable unix stats

  -M stat1,stat2         enable external stats
     --mods stat1,stat2

  -a, --all              equals -cdngy (default)
  -f, --full             expand -C, -D, -I, -N and -S discovery lists
  -v, --vmstat           equals -pmgdsc -D total

  --integer              show integer values
  --nocolor              disable colors (implies --noupdate)
  --noheaders            disable repetitive headers
  --noupdate             disable intermediate updates
  --output file          write CSV output to file

  delay is the delay in seconds between each update
  count is the number of updates to display before exiting
  The default delay is 1 and count is unspecified (unlimited)

常用标签： oracle MySQL Oracle11g dba blog 新特性 oow oow2009 wordpress ASM

最新评论 | Recent comments

最近文章 | Recent posts

站点信息 | Statistics