三， 数据压缩
要看数据压缩部分的实现，主要从dmsCompress.cpp 开始看。SequoiaDB基于snappy来实现数据压缩。Snappy是Google发明的数据压缩算法，它不是追求高压缩率，而是追求快，是Google在内部广泛使用的，也在BigTable和HBase中使用，所以基于这个，数据压缩这块应该是很靠谱的，在不影响性能的情况下，如果能够大幅减少存储空间，当然求之不得。
在dmsStorageData.cpp实现了数据存储服务，如insertRecord实现数据的压缩存储。可以有上下文参数决定是否压缩。
if ( OSS_BIT_TEST ( context->mb()->_attributes,
DMS_MB_ATTR_COMPRESSED ) )
{
rc = dmsCompress( cb, record, ((CHAR*)(&oid)), oidLen,
&compressedData, &compressedDataSize ) ;
PD_RC_CHECK ( rc, PDERROR, "Failed to compress record[%s], rc: %d",
record.toString().c_str(), rc ) ;
dmsRecordSize = compressedDataSize + sizeof(INT32) ;
PD_TRACE2 ( SDB__DMSSTORAGEDATA_INSERTRECORD,
PD_PACK_STRING ( "size after compress" ),
PD_PACK_UINT ( dmsRecordSize ) ) ;
if ( dmsRecordSize > (UINT32)(record.objsize() + oidLen) )
{
dmsRecordSize = record.objsize() ;
}
else
{
addOID = FALSE ;
oidLen = 0 ;
isCompressed = TRUE ;
}
}
四， 数据索引分离
我想SequoiaDB之所以设计数据和索引分离，应该是看到MongoDB在这方面的局限性吧。在MongoDB中，数据和索引是存储在一块的，所以默认情况下，构建索引会阻塞集合上的其他所有操作，所以如果当数据集特别大的时候，建立索引要花很长的时间，这会让数据查询和写入操作陷入停顿。MongoDB在建立索引时，也可以选择后台建立索引的方式，并且在2.4版本以后允许同时建立多个后台索引。SequoiaDB直接把索引单独存放，这样的好处是不但能够破除对数据操作的影响，而且可以通过把索引存储在单独的物理磁盘之上，避免数据，索引和日志对磁盘IO的竞争，从而支持更大规模的数据集。因此，从这一点上，SequoiaDB的后发优势十分明显。
最后，谈一点在探索SequoiaDB的过程中和Mongodb的比较使用感受和期望吧。第一印象，MongoDB比SequoiaDB更容易上手，文档更齐全，社区更活跃。
MongoDB提供了Windows，Linux，Mac平台的可执行文件，并且几乎是开箱即用，根本没有学习难度。国内普通的开发人员用windows的居多，所以提供全平台的执行文件能够大大降低开发人员去尝试的门槛。居然在Mac上也没提供可执行文件，而且编译脚本也不支持Mac，所以我是在Linux服务器上在尝试使用SequoiaDB的。
MongoDB可以无需看文档，下载下来，运行就可以用了。而SequoiaDB我的确是探索了一番。举个例子，谁能想到sdbcmart居然是sdbcm_start的意思，我居然想到什么“艺术”之类的去了；另外sdbcmtop怎么能不让联想到sdbcm_top呢（查状态），而居然是sdbcm_stop!非得去看文档才搞清楚这几个执行文件的意思。
另外，MongoDB还提供了诸如Capped Collection，地理位置查询等一些贴心的小功能，我在自己的项目中用得很爽，因此我觉得这在讨取开发人员欢心方面是很奏效的。
总体而言，觉得在目前阶段MongoDB更Sexy，而SequoiaDB相对来说内秀一点，不过如果瞄准企业级市场，专注于这一块做出特色，而且在国家层面支持的软件国产化战略大局中，后势可期！
