下面我们就来了解一下服务器硬盘的性能指标：

• 硬盘的转速（Spindle Speed）：硬盘转速就是指硬盘主轴电机的转动速度，也就是硬盘盘片在一分钟内所能完成的最大转数（rpm）。转速的快慢是标示硬盘档次的重要参数之一，它是决定硬盘内部传输率的关键因素之一，在很大程度上直接影响到硬盘的速度。硬盘的转速越快，硬盘寻找文件的速度也就越快，相对的硬盘的传输速度也就得到了提高。硬盘转速以每分钟多少转来表示，单位表示为RPM，RPM是Revolutions Per minute的缩写，是转/每分钟。RPM值越大，内部传输率就越快，访问时间就越短，硬盘的整体性能也就越好。 然而，转速的提高也带来了磨损加剧、温度升高、噪声增大等一系列负面影响。
• 硬盘数据传输率：的英文拼写为Data Transfer Rate，简称DTR。硬盘数据传输率表现出硬盘工作时数据传输速度，是硬盘工作性能的具体表现，它并不是一成不变的而是随着工作的具体情况而变化的。在读取硬盘不同磁道、不同扇区的数据；数据存放的是否连续等因素都会影响到硬盘数据传输率。因为这个数据的不确定性，所以厂商在标示硬盘参数时，更多是采用外部数据传输率(External Transfer Rate)和内部数据传输率（Internal Transfer Rate）。
• 内部数据传输率（internal data transfer rate）：也叫持续数据传输率（sustained transfer rate），单位Mbits/S，这是兆位/秒的意思（注意与MB/S（兆字节/秒）之间的差别：MB/S=Mbits/S除以8）。它指磁头至硬盘缓存间的最大数据传输率，一般取决于硬盘的盘片转速和盘片数据线密度（指同一磁道上的数据间隔度）。内部传输率可以明确表现出硬盘的读写速度，它的高低才是评价一个硬盘整体性能的决定性因素，它是衡量硬盘性能的真正标准。
• 接口访问速度（Gb/秒）：该指标也称为突发数据传输率（Burst data transfer rate）或外部数据传输率(External Transfer Rate)，它是指从硬盘缓冲区读取数据的速率，也就是计算机通过硬盘接口从缓存中将数据读出交给相应的控制器的速率。在广告或硬盘特性表中常以数据接口速率代替，单位为MB/s。ATA100中的100就代表着这块硬盘的外部数据传输率理论最大值是100MB/s；ATA133则代表外部数据传输率理论最大值是133MB /s；SATA1.0接口的硬盘外部理论数据最大传输率可达150MB/s，而SATAII接口的硬盘外部理论数据最大传输率可达300MB/s。这些只是硬盘理论上最大的外部数据传输率，在实际的日常工作中是无法达到这个数值的，而是更多的取决于内部数据传输率。
• 寻道时间，平均读/写时间（毫秒）：平均寻道时间的英文拼写是Average Seek Time，它是了解硬盘性能至关重要的参数之一。它是指硬盘在接收到系统指令后，磁头从开始移动到移动至数据所在的磁道所花费时间的平均值，它一定程度上体现硬盘读取数据的能力，是影响硬盘内部数据传输率的重要参数，单位为毫秒（ms）。不同品牌、不同型号的产品其平均寻道时间也不一样，但这个时间越低，则产品越好，现今主流的硬盘产品平均寻道时间都在在9ms左右。
• 平均延迟时间（毫秒）：它指的是磁头移动到指定磁道后，还需要多少时间指定的（即要读取或者写入的）扇区才会转到磁头下进行读取或者写入的相关操作，很明显这个时间和盘片的转速有关，平均延迟时间一般指盘片旋转一周所用时间的一半，单位为毫秒(ms)。这样我们就可以很轻松地换算出硬盘转速和平均潜伏期的一一对应关系。               换算公式为：（60*1000）/ 硬盘转速 * 0.5=平均延迟时间                              可以计算出来，5400转 5.556ms，7200转 4.167ms和10000转 3ms
• 平均访问时间(Average Access Time)：这项指标在官方技术文档中一般不会出现，它指的是从相应的读或者写指令发出开始到指定的扇区转到磁头下等待进行读取或者写入（也有的称为从读/写指令发出到第一笔数据读/写所用的时间）为止的这段时间。一般情况下，平均访问时间约等于平均寻道时间和平均延迟时间之和（严格定义中还包括一些指令处理时间，但一般忽略不计）。其单位也为毫秒(ms)，它的值我们可以利用Hdtach和Winbench 99v2.0测试出来。
• 缓存（Cache memory）：缓存是硬盘与外部总线交换数据的场所，是硬盘控制器上的一块内存芯片，具有极快的存取速度。硬盘读数据的过程是将要读取的资料存入缓存，等缓存中填充满数据或者要读取的数据全部读完后再从缓存中以外部传输率传向硬盘外的数据总线。它是硬盘内部存储和外部接口之间的缓冲器。由于硬盘的内部数据传输率和接口访问速度不同，缓存在其中起到一个缓冲的作用。缓存的大小与速度是直接关系到硬盘的传输速度的重要因素，能够大幅度地提高硬盘整体性能。当硬盘存取零碎数据时需要不断地在硬盘与内存之间交换数据，有大缓存，则可以将那些零碎数据暂存在缓存中，减小外系统的负荷，也提高了数据的传输速度。
• 单碟容量：除了对于容量增长的贡献之外，单碟容量的另一个重要意义在于提升硬盘的数据传输速度。单碟容量的提高得益于磁道数的增加和磁道内线性磁密度的增加。磁道数的增加对于减少磁头的寻道时间大有好处，因为磁片的半径是固定的，磁道数的增加意味着磁道间距离的缩短，而磁头从一个磁道转移到另一个磁道所需的就位时间就会缩短。这将有助于随机数据传输速度的提高。而磁道内线性磁密度的增长则和硬盘的持续数据传输速度有着直接的联系，磁道内线性密度的增加使得每个磁道内可以存储更多的数据，从而在碟片的每个圆周运动中有更多的数据被从磁头读至硬盘的缓冲区里。

可靠性与数据完整性指标：

• 平均无故障时间（MTBF，小时）:平均无故障时间(Mean Time Between Failures，简称MTBF)是指硬盘平均能够正常运行多长时间，才发生一次故障。这是衡量硬盘可靠性的重要参数，平均无故障时间越长，硬盘的可靠性就越高。目前主流产品的平均无故障时间(MTBF)达到了一百万小时以上。
• 全天候不间断运行的可靠性级别 (AFR)
• 不可恢复读错误/被读数据（位）
• 每年运行小时数
• 字节数/扇区

参考：最大内部数据传输率   硬盘转速 硬盘  服务器硬盘的选择

2 人人网技术架构介绍

3 Facebook网站的前端性能优化

如果你的错误页面过于简单，比如你的404页面上只有一句话“404”，那么IE将显示默认的友好错误信息，如下图：

问题原因：

Internet Explorer 5和更高版本为以下友好错误信息提供了HTML模板替换项：400.403.404.405.406.408.409.410.500.501和505。每个错误都有一个名称值对（例如“404”，512）。第一个值为错误代码。第二个值是表示字节大小的值，Internet Explorer 5或更高版本使用该值来检测何时用自己的信息替换错误信息。因此，当Internet Explorer 5版的Wininet.dll文件得到HTTP错误信息时，Wininet.dll文件将确定HTML错误中附带的HTTP内容是否为正确设计的Web 页。这是在页面大小的基础上进行的。它在注册表中对每个错误的阈值进行评估。如果Web页太小，该Web页将被拒绝，并显示友好HTTP状态Web页。

在Internet Explorer 4中，当Wininet.dll无法解决请求时，它显示一个嵌入式HTML错误信息和一个非描述性定义，例如：“Navigation Canceled”（导航已取消）或“Unable to retrieve Webpage in Offline mode”（在脱机模式下无法检索网页）。这些错误信息是Shdocvw.dll文件的资源（res:）。资源是指程序出于显示目的所使用的HTML代码，它嵌入在动态链接库（DLL）文件中。在Internet Explorer 5或更高版本中，这些错误信息是作为Shdoclc.dll文件的资源存储的。当收到错误信息时，它被相应的HTML模板取代，此模板可能包含以下任意类型的信息：

　　•有关此问题的信息。
　　•有关如何更正或解决此问题的信息。
　　•指向前一页的链接。
　　•指向Internet Explorer支持页的链接。
　　•指向同一页的链接，以便您能尝试重新连接到该页。
　　•指向缓存中的页面副本的链接（如果创建了应用程序编程接口API）。

　　友好HTTP状态错误信息存储在以下注册表项中：HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\ErrorThresholds。

解决此问题的办法有：

1 将页面的内容做的丰富一些，内容多一些（加一些table或者div之类的）！

JAVA代码<table width="563" border="0" align="center" cellpadding="0" cellspacing="0">
  <tr>
    <td height="125">&nbsp;</td>
  </tr>
  <tr>
    <td height="195" background="/1.gif" bgcolor="#FFFFFF"><table border="0" align="center" cellpadding="0" cellspacing="0">
        <tr>
          <td width="210"><a href="#"><img src="/404-2.gif" alt="" width="210" height="80" border="0" /></a></td>
          <td style="color:#333333; font-size:14px; font-weight:bold;">页面没有找到，5秒钟之后将带您进入首页！</td>
        </tr>
      </table></td>
  </tr>
</table>

2 在404页面中设置状态码为200，response.setStatus(200);

3  设置IE的选项   工具–>Internet选项–>高级—>显示友好http错误信息(取消选择) 。

ps：在firefox下如果用了google的工具条也会有一样的问题，当然解决办法也是一样的！

未来"云–端"精彩生活畅想

微软愿景：未来健康

SLF4J库类似于Apache Commons-Logging，但Apache Commons-Logging采用的是动态绑定机制，使用ClassLoader寻找和载入底层的日志库，而在OSGI中，不同的插件使用自己的ClassLoader，OSGI的这种机制保证了插件互相独立，然而却使得Apache Commons-Logging无法在OSGI的环境下工作了。SLF4J却没有这个问题，它是如何做到的呢？

一个简单的例子：

package chapters.introduction;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld1 {

  public static void main(String[] args) {

    Logger logger = LoggerFactory.getLogger("chapters.introduction.HelloWorld1");
    logger.debug("Hello world.");
  }
}

SLF4J与日志系统的绑定过程是在getLogger方法中完成的！下面介绍整个绑定过程。

通过上图大家可以发现整个静态绑定机制的核心是通过查找类路径下面的org/slf4j/impl/StaticLoggerBinder.class，所以类路径下只能有一个这个类。看到这里大家可能会问了，这个类的包名是org.slf4j.impl，找这个类如何与其他的日志系统连接呢？呵呵，这个很简单，其实slf4j的发布包中包含了为多种日志系统写好的绑定代理，每个日志系统都写好了一个独立的StaticLoggerBinder，由这个类调用相关日志系统的对象！

下图是slf4j发布包中的为各个日志系统写好的绑定代理。

为什么没有logback的绑定代理？呵呵，因为logback中已经内置了slf4j的绑定代理。

[root@liunx389 img]# egrep ‘vmx|svm’ /proc/cpuinfo
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm

假如一个vmx标志出现的话，就表示您拥有Intel 处理器的虚拟化支持。

假如一个svm标志出现的话，就表示您拥有AMD 处理器的虚拟化支持。

如果内容为空表明cpu不支持虚拟化。

除了检查中央处理器旗标以外，您也应该要使您系统 BIOS 中的完整虚拟化生效。

2 安装 KVM

安装 KVM 所需要的软件包：

3 创建镜像

有了启用了虚拟化支持的引导内核，接下来的一个步骤是为客户操作系统创建一个磁盘映像。

您可以使用 qeumu-img 来完成此操作，如下所示。注意这个映像的大小是 5GB，但是使用 QEMU 的写时复制格式（copy-on-write，qcow）时，整个文件将根据需要增长，而不是完全占据这 5 GB 的空间。

qemu-img create -f qcow2 centos.img 5G 

如果需要创建固定大小的磁盘镜像文件可以使用如下命令：

qemu-img create -f raw centos.img 5G 

dd if=/dev/zero of=centos.img bs=1024k count=5000

ext4下可以使用：fallocate -l 5G centos.img

4 安装GuestOS

分布式存储概念

与目前常见的集中式存储技术不同，分布式存储技术并不是将数据存储在某个或多个特定的节点上，而是通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。

具体技术及应用：

海量的数据按照结构化程度来分，可以大致分为结构化数据，非结构化数据，半结构化数据。

本文接下来将会分别介绍这三种数据如何分布式存储。

结构化数据的存储及应用

所谓结构化数据是一种用户定义的数据类型，它包含了一系列的属性，每一个属性都有一个数据类型，存储在关系数据库里,可以用二维表结构来表达实现的数据。

大多数系统都有大量的结构化数据，一般存储在Oracle或MySQL的等的关系型数据库中，当系统规模大到单一节点的数据库无法支撑时，一般有两种方法：垂直扩展与水平扩展。

· 垂直扩展：垂直扩展比较好理解，简单来说就是按照功能切分数据库，将不同功能的数据，存储在不同的数据库中，这样一个大数据库就被切分成多个小数据库，从而达到了数据库的扩展。一个架构设计良好的应用系统，其总体功能一般肯定是由很多个松耦合的功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一张或多张表。各个功能模块之间交互越少，越统一，系统的耦合度越低，这样的系统就越容易实现垂直切分。

· 水平扩展：简单来说，可以将数据的水平切分理解为按照数据行来切分，就是将表中的某些行切分到一个数据库中，而另外的某些行又切分到其他的数据库中。为了能够比较容易地判断各行数据切分到了哪个数据库中，切分总是需要按照某种特定的规则来进行的，如按照某个数字字段的范围，某个时间类型字段的范围，或者某个字段的hash值。

垂直扩展与水平扩展各有优缺点，一般一个大型系统会将水平与垂直扩展结合使用。

实际应用：图1是为核高基项目设计的结构化数据分布式存储的架构图。

图1可水平&垂直切分扩展的数据访问框架

· 采用了独立的分布式数据访问层，后端分布式数据库集群对前端应用透明。

· 集成了Memcached集群，减少对后端数据库的访问，提高数据的查询效率。

· 同时支持垂直及水平两种扩展方式。

· 基于全局唯一性主键范围的切分方式，减轻了后续维护的工作量。

· 全局唯一性主键的生成采用DRBD+Heartbeat技术保证了可靠性。

· 利用MySQL Replication技术实现高可用的架构。

注:以上的数据切分方案并不是唯一扩展MySql的方法，有兴趣的读者可以关注一下” 云计算时代的MySQL-Clustrix Sierra分布式数据库系统”。

非结构化数据的存储及应用

相对于结构化数据而言,不方便用数据库二维逻辑表来表现的数据即称为非结构化数据,包括所有格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等。

分布式文件系统是实现非结构化数据存储的主要技术，说到分布式文件系统就不得不提GFS（全称为“Google File System”），GFS的系统架构图如下图所示。

图2 Google-file-system架构图

图3 Google-file-system架构图（详细）

GFS将整个系统分为三类角色：Client（客户端）、Master（主服务器）、Chunk Server（数据块服务器）。

· Client（客户端）：是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。

· Master（主服务器）：是GFS的管理节点，主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括：命名空间（Name Space），也就是整个文件系统的目录结构，一个能将64位标签映射到数据块的位置及其组成文件的表格，Chunk副本位置信息和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新（“Heart- beat”）来让元数据保持最新状态。

· Chunk Server（数据块服务器）：负责具体的存储工作，用来存储Chunk。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每一个Chunk以Block为单位进行划分，大小为64KB，每个Chunk有一个唯一的64位标签。GFS采用副本的方式实现容错，每一个Chunk有多个存储副本（默认为三个）。 Chunk Server的个数可有有多个，它的数目直接决定了GFS的规模。

GFS之所以重要的原因在于，在Google公布了GFS论文之后，许多开源组织基于GFS的论文开发了各自的分布式文件系统，其中比较知名的有HDFS，MooseFS，MogileFS等。

实际应用：由于核高基的项目中未来会有大量的数据与应用需要存储，所以我们设计时也采用分布式文件系统的方案，由于开源的分布式文件系统可以基本满足我们需求，另外从时间上来说也比较紧张，所以我们采用了开源的MooseFS作为底层的分布式文件系统。

· MooseFS存在的问题：由于MooseFS是也是按照GFS论文设计的，只有一个Master（主服务器），虽然可以增加一个备份的日志服务器，但是还是存在Master无法扩展的问题，当单一Master节点上存储的元数据越来越多的时候，Master节点占用的内存会越来越多，直到达到服务器的内存上限，所以单一Master节点存在内存上的瓶颈，只能存储有限的数据，可扩展性差，并且不稳定。

· 对MooseFS的优化：面对MooseFS存在的问题，我们采用了类似分布式数据库中的“Sharding”技术，设计了一个分布式文件系统访问框架，可以做到对分布式文件系统做垂直与水平切分。这样就最大限度的保证了MooseFS系统的可扩展性与稳定性。

下图是为核高基项目设计的非结构化数据分布式存储的架构图。我们设计了两种访问方式，一种是类似GFS的API访问方式，以库文件的方式提供，应用程序通过调用API直接访问分布式文件系统。第二种是通过RESTful web Service访问。

图4可水平&垂直切分扩展的分布式文件系统访问框架（API版）

图5可水平&垂直切分扩展的分布式文件系统访问框架（RESTful web Service版）

半结构化数据的存储及应用

就是介于完全结构化数据（如关系型数据库、面向对象数据库中的数据）和完全无结构的数据（如声音、图像文件等）之间的数据， 半结构化数据模型具有一定的结构性，但较之传统的关系和面向对象的模型更为灵活。半结构数据模型完全不基于传统数据库模式的严格概念，这些模型中的数据都是自描述的。

由于半结构化数据没有严格的schema定义，所以不适合用传统的关系型数据库进行存储，适合存储这类数据的数据库被称作“NoSQL”数据库。

NoSQL的定义：

被称作下一代的数据库，具有非关系型，分布式，轻量级，支持水平扩展且一般不保证遵循ACID原则的数据储存系统。“NoSQL”其实是具有误导性的别名，称作Non Relational Database(非关系型数据库)更为恰当。所谓“非关系型数据库”指的是：

· 使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模(Map，列，文档，图表等)，而不是使用固定的关系模式元组来构建数据模型。

· 以遵循于CAP定理（能保证在一致性，可用性和分区容忍性三者中中达到任意两个）的跨多节点数据分布模型而设计，支持水平伸缩。这意味着对于多数据中心和动态供应（在生产集群中透明地加入/删除节点）的必要支持，也即弹性(Elasticity)。

· 拥有在磁盘或内存中，或者在这两者中都有的，对数据持久化的能力，有时候还可以使用可热插拔的定制存储。

· 支持多种的‘Non-SQL’接口(通常多于一种)来进行数据访问。

图6是Sourav Mazumder提出的NoSQL总体架构：

图6 NoSQL总体架构

· 接口：REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，语言特定的API(MongoDB)。

· 逻辑数据模型：面向键值对的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文档的(Couch DB，MongoDB等)，面向图的(Neo4j， Infogrid等)

· 数据分布模型：致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分区性(Cassandra等)。一致性和可分区性的组合会导致一些非额定的节点产生可用性的损失。有趣的是目前还没有一个“非关系型数据库”支持这一组合。

· 数据持久性：基于内存的(如Redis，Scalaris， Terrastore)，基于磁盘的(如MongoDB，Riak等)，或内存及磁盘二者的结合(如 HBase，Hypertable，Cassandra)。存储的类型有助于我们辨别该解决方案适用于哪种类型。然而，在大多数情况下人们发现基于组合方 案的解决方案是最佳的选择。既能通过内存数据存储支持高性能，又能在写入足够多的数据后存储到磁盘来保证持续性。

NoSQL中的重要理论基础：

CAP理论：

· C: Consistency 一致性

· A: Availability 可用性(指的是快速获取数据)

· P: Tolerance of network Partition 分区容忍性(分布式)

图7 CAP理论

CAP原理告诉我们，这三个因素最多只能满足两个，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说，分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么 传统数据库的扩展能力有限的原因。

BASE模型：

说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。

· Basically Availble –基本可用

· Soft-state –软状态/柔性事务

· Eventual Consistency –最终一致性

BASE模型是传统ACID模型的反面，不同于ACID模型，BASE强调牺牲高一致性，从而获得可用性或可靠性。

基本可用是指通过Sharding，允许部分分区失败。

软状态是指异步，允许数据在一段时间内的不一致，只要保证最终一致就可以了。

最终一致性是整个NoSQL中的一个核心理念，强调最终数据是一致的就可以了，而不是时时一致。

Quorum NRW：

图8 Quorum NRW

N: 复制的节点数，即一份数据被保存的份数。
R: 成功读操作的最小节点数，即每次读取成功需要的份数。
W: 成功写操作的最小节点数 ，即每次写成功需要的份数。

这三个因素决定了可用性，一致性和分区容错性。只需W + R > N，就可以保证强一致性。

实际应用： 今年上半年我在aspire的搜索团队中负责互联网搜索的设计与开发，我设计的网页爬虫系统就是采用Cassandra来存储网页与链接信息的。下面结合我的实际使用经验谈谈我对Cassandra的看法：

优点：

· 弹性扩展：由于Cassandra是完全分布式的，使用时不需要再像使用MySQL那样自己设计复杂的数据切分方案，也不再配置复杂的DRBD+Heartbeat，一切都变得非常简单了，只需要简单的配置就可以给一个集群中增加一个新的节点，而且对客户端完全是透明的，不需要任何更改。

· 灵活的schema：不需要象数据库一样预先设计schema，增加或者删除字段非常方便。

· 使用简单：由于没有类似SQL这样复杂的查询语言，学习成本不高，很容易上手。

缺点：

· 稳定性差：在我们的实际使用过程中发现，单机数据量达到200G以上，时不时就会发生宕机现象。

· 缺乏管理与分析工具：传统的关系型数据都有比较好用的管理与分析工具，使用这些工具可以轻松的管理数据库，查看数据，分析性能瓶颈等，而Cassandra确缺少类似的工具，就连简单的查看一条数据，都要通过编程才能看到。