分布式数据库详解，第 2 部分 数据结构和数据读写.docVIP

分布式数据库详解，第 2 部分 数据结构与数据读写 Cassandra分布式数据库详解，第2部分：数据结构与数据读写(转自IBM)2011-04-06 16：36Cassandra分布式数据库详解，第2部分：数据结构与数据读写 许令波,Java工程师,淘宝网 简介：这部分主要介绍Cassandra中数据的存储格式，包括在内存中的数据和磁盘中数据。Cassandra的写的性能表现非常好，为什么写的性能这么好?和它的数据结构有没有关系，以及和它的写的机制又有多大的关系。同时也将分析哪些因素会影响读的性能Cassandra又做了哪些改进。 发布日期：2010年9月10日 级别：初级 访问情况2923次浏览 建议： 平均分(共9个评分)Cassandra中的数据主要分为三种： CommitLog：主要记录下客户端提交过来的数据以及操作。这个数据将被持久化到磁盘中，以便数据没有被持久化到磁盘时可以用来恢复。Memtable：用户写的数据在内存中的形式，它的对象结构在后面详细介绍。其实还有另外一种形式是BinaryMemtable这个格式目前Cassandra并没有使用，这里不再介绍了。SSTable：数据被持久化到磁盘，这又分为Data、Index和Filter三种数据格式。 CommitLog的数据只有一种，那就是按照一定格式组成byte组数，写到IO缓冲区中定时的被刷到磁盘中持久化，在上一篇的配置文件详解中已经有说到CommitLog的持久化方式有两种，一个是Periodic一个是Batch，它们的数据格式都是一样的，只是前者是异步的，后者是同步的，数据被刷到磁盘的频繁度不一样。关于CommitLog的相关的类结构图如下： 图1.CommitLog的相关的类结构图 它持久化的策略也很简单，就是首先将用户提交的数据所在的对象RowMutation序列化成byte数组，然后把这个对象和byte数组传给LogRecordAdder对象，由LogRecordAdder对象调用CommitLogSegment的write方法去完成写操作，这个write方法的代码如下： public CommitLogSegment.CommitLogContext write(RowMutation rowMutation,Object serializedRow){long currentPosition=-1L；.Checksum checkum=new CRC32()；if(serializedRow instanceof DataOutputBuffer){DataOutputBuffer buffer=(DataOutputBuffer)serializedRow；logWriter.writeLong(buffer.getLength())；logWriter.write(buffer.getData(),0,buffer.getLength())；checkum.update(buffer.getData(),0,buffer.getLength())；}else{assert serializedRow instanceof byte；byte bytes=(byte)serializedRow；logWriter.writeLong(bytes.length)；logWriter.write(bytes)；checkum.update(bytes,0,bytes.length)；}logWriter.writeLong(checkum.getValue())；.} 这个代码的主要作用就是如果当前这个根据columnFamily的id还没有被序列化过，将会根据这个id生成一个CommitLogHeader对象，记录下在当前的CommitLog文件中的位置，并将这个header序列化，覆盖以前的header。这个header中可能包含多个没有被序列化到磁盘中的RowMutation对应的columnFamily的id。如果已经存在，直接把RowMutation对象的序列化结果写到CommitLog的文件缓存区中后面再加一个CRC32校验码。Byte数组的格式如下： 图2.CommitLog文件数组结构 上图中每个不同的columnFamily的id都包含在header中，这样做的目的是更容易的判断那些数据没有被序列化。 CommitLog的作用是为恢复没有被写到磁盘中的数据，那如何根据CommitLog文件中存储的数据恢复呢?这段代码在recover方法中： public static void recover(File clogs)throws IOException{.final CommitLogHeader clHeader=Commi