云存储“有效”应用和云存储“无效”应用——2009-1-15 CTO俱乐部第一次聚会“云计算”后记

　　CTO俱乐部第一次聚会的主题是“云计算”，也有幸认识了北京美地森科技创始人游峰先生，聆听游峰先生关于云存储方面进展的介绍。后来吕建伟老师还针对这次聚会专门写了一篇文章：
　　http://lvjianwei.cto.csdn.net/Hot_Discuss.aspx?Name=lvjianwei&pointid=97
其中涉及到了我们目前的业务，由于聚会时间短暂，我没有详细解释很多细节，下面我将就此问题展开说明。我昨天半夜写了一篇CTO俱乐部第一次聚会的文章：
　　http://blog.csdn.net/hu_zhenghui/archive/2009/01/16/3793180.aspx
其中依据我们自身的业务情况，我提出了从存储（特指硬盘存储）、带宽和CPU这三方面考察资源使用率，并优化资源使用率。在资源达到或接近上限时，就不得不将一个应用从一个计算单元迁移到另一个计算单元。这样在切换时，就会影响到服务。我在举这个例子时，主要是针对云计算和网格计算两个概念之间的辨析，并没有展开说明这个问题所涉及的细节，所以一个直观的思路就是，在硬盘存储充裕的情况下，就可以减少甚至消除这种迁移，但是在实际应用中，还需要考虑更多方面的细节。
　　由于硬盘存储是持久数据，而带宽和CPU都是随着使用的情况而变化的，也就是说，当没有用户使用时，带宽和CPU的消耗几乎为零。如果借助于云存储共享硬盘存储，那么存储资源就不会到达上限，也就不会因为存储资源达到上限导致应用在计算单元中迁移。而且在计算单元中迁移应用时，也不需要迁移硬盘存储。更进一步，由于带宽和CPU是依赖于用户使用的，只需要将用户的访问交给另一台计算单元处理，就可以完成计算单元间的迁移。如果再配合一个统一的网络入口来控制用户访问的计算单元，就可以实现无缝迁移。但是在实际生产环境中，还需要考虑更多的细节。

　　首先就是应用的类型，从云存储的角度来看应用的类型，可以先从两个极端的典型应用开始，第一个典型应用是NFS网络文件系统，对于云存储来说，网络文件系统只是云存储的一个特例，但是在实际应用中，仍需要考虑几个问题，首先要有journal日志特性，即便云存储能实现单点故障的容错，但是并不能解决使用云存储的应用故障，因此在使用基于云存储的网络文件系统的应用出现故障时，网络文件系统应当具备自动恢复一致性和数据完好性的能力。其次需要考虑文件夹的实现以及ACL访问控制列表的实现。虽然有这些问题，但是对于云存储来说，NFS仍是一个轻量级应用。

　　另一个极端的典型应用就是关系型数据库。目前为止，关系型数据库仍不能通过云存储来实现其负荷的扩展。而是通过集群来实现，而且这个集群上限的瓶颈很快也将达到。虽然目前数据库中应用最广泛的是关系型数据库，但是由于关系型数据库的集群瓶颈导致其负荷极限的瓶颈。因此在需要更高负荷的时候，会将关系型数据库按表放置在不同的服务器上，当一台服务器不能容纳一个表时，又会将表中的数据分区切片存放在不同的服务器上。这样看来，似乎解决了关系型数据库的负荷瓶颈，但是这种实现方式也极大的限制了关系型数据库的使用，很多简单的SQL查询都不能实现，或者对性能有极大的影响。
　　通过这两个极端的例子可以看出，不是所有的应用都适用于云存储，但是数据库又是应用中必不可少的一部分，如果寻找云存储和数据库的结合点呢？还是回到前面关系型数据库的例子继续看，在关系型数据库的优势无法展现的时候，不妨考虑其他类型的数据库，此时，常见的选择就是通过文件分别保存索引的数据库（由于文件型数据库也经常指通过访问文件而不是网络端口的关系型数据库，例如ACCESS或SQLite，所以在这里没有使用文件型数据库这个容易混淆的名词）。文件索引的数据库适合保存树型结构数据、大容量文件和没有表间关系的小型数据表等数据结构。文件索引数据库同时也符合云存储的特性。因此，文件索引数据库能满足要求的应用，也必然是可以借助于云存储扩展负荷，例如邮件存储应用（包括POP3、IMAP或者其他借助于HTTP等通讯协议实现类似于 IMAP的协议），UGC应用（用户创造内容，包括文本、图片、视频和文件等）
　　因此在尝试借助于云存储扩展负荷时，首先需要判断应用本身是云存储“有效”应用，还是云存储“无效”应用，对于云存储“无效”应用，就需要借助于其他方式来扩容。当然本文讨论的是无间断服务扩容，在允许间断服务的情况下，借助于云存储可以有更为灵活的负荷扩容方案。
　　最后，再次感谢CSDN和《程序员》杂志组织CTO俱乐部的聚会，感谢吕建伟老师和游峰先生对于我们业务的关注。