前言：
上次谈了一些语义网应用发展的趋势的个人看法（见 我对语义网（Semantic Web）应用发展的一些看法），这次我们回过头来看看随着web应用的不断发展，其下作技术支撑的基础架构的演变趋势。
Web应用的通用基础服务平台包含数据存储、分布计算、消息通讯、安全认证等等多方面内容。我这里不去一一谈到（很多我也不熟悉，呵呵！），而是有重点的谈谈随目前web应用规模化之后变的尤为突出的——“数据存储平台”和“数据分布计算平台”的架构特点。
第一部分：WEB应用中的数据存储架构
过去我们要想去搭建个一般网站，数据存储方面无需多想，直接使用mysql,sql2000等关系数据库就绰绰有余。但是当前的大规模web应用往往传统的关系数据库就有些力不从心了。究其原因是因为大规模web应用数据存储、访问、和数据组织上出现的一些的新特点：
数据存储特点 —— 数据量很大！远超过了传统单机关系数据库容纳的能力。
数据访问方式 —— 并发压力很大，需要承受并发访问能力强；重视系统的可用性，可适当牺牲数据一致性这些特性有的和传统关系数据库设计初衷有相悖之处
数据的组织特点 —— 更多的非结构化数据和半结构化数据，而非关系数据库擅长的结构化数据。
下面我们具体来看看这些新特性，以及架构上需要进行的改变。
1.1 WEB应用的数据存储需求和对策
需求很简单,归纳起来，有三点中重要：
支持海量数据 —— 互联网应用作为全球化应用，其数据量变的越来越大（可想像一下，动暨数以白亿计的网页内容需要多大的存储容量）。
支持方便扩容 —— 当你需要更多机器支持存储需要时，要能方便快速和安全的——尽量不影响或者少影响业务——进行存储扩容。
保证数据可靠性 —— 数据就是财富，马虎不得。互联网企业往往为了成本而使用大量的廉价机器做存储，其稳定性自然不能和实验室的高性能存储服务器相比，所以机器故障的风险高了许多。
存储架构上的相应对策如下：
1 支持海量数据最直接方法是分布存储。分布存储方法很多，最简单的就是对数据做分区（Partation）。
2 扩容目标是将一台机器的数据劈开，从而将一部分转移到新添加的存储点上。要降低存储扩容对系统服务的影响有很多策略——按分区逐步扩容，这样只会影响该分区的数据访问；还有就是避免劈表（劈表往往需要扫表并对数据重新组织这种耗时的重运算）所采用的数据分段方式（也就是在一台机器内再进行更细的数据分区），如此一来避免了避表，只需要将部分段迁移就可。Amzon 的Dynamo的系统就是采用该方法（具体描述可见前文对云计算中几种基础设施（Dynamo,Bigtable,Map/Reduce等）的朴素看法）。
3 数据可靠性保证一般采用多副本技术——一份数据同时在不同机器上存储几个相同副本（不但有利于实现数据冗余存储，而且还能起到负载均衡作用）。比如对一份数据存储3个副本，那么三台机器同期发生故障的机会几乎没有，所以大可认为该数据是安全的。
1.2 WEB应用的数据访问需求和对策：
Web数据的访问的主要特点可归纳如下：
高并发访问，尤其是读优先。
高可用性——系统访问服务不中断（对互联网应用来说这点往往是被重点强调的）。
较高的容错要求——系统要求能容忍一定程度的网络链接故障、网络分区故障、机器故障。因为机器多了、分布广了出问题的概率也多得多了。
数据访问并非需要严格一直性。
存储架构上的相应对策如下：
最大的技术策略是放弃传统数据访问所要求的 ACID 特性而遵循 BASE + CAP特性—— 所谓ACID 是指：DBMS强调ACID：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性 (Durability)。这些特性保证数据的一致性和安全性，但实现起来必然降低了系统的可用性和访问速度。因而现在普遍认可的方向是保证可用性和速度，而放弃一定的数据一致性和安全性（互联网应用中多数数据是可再生的，或者容忍错误的，不要求那么准）。 BASE + CAP正式这种策略的抽象含义。BASE 是指：基本可用（Basically Availble）；软状态（Soft-state）；最终一致性（Eventual Consistency ）。CAP特性是指：一致性（Consistency）；可用性（Availability）；分区容忍性（Tolerance of network Partition）等三个需求无法同时满足，必须有取舍。（如果不熟悉这些概念去google 找找吧，尤其是最终一致性这点最为精彩，可参看 /eventually_consistent.html）
为了提高系统吞吐和数据安全，上面我们谈到使用副本技术。而副本系统的访问策略则有一些不同选择。罗列一下吧:副本传播方式可有——同步方式和异步方式，所谓同步方式是说写入所有副本到给定点需要同步完成；而异步方式则是先写一份到某个点上，然后该点将在延后一定时刻后才将其传播到其它点上。显然同步方式更安全、各副本数据一致性，但可用性低（如果严格同步要求，则是一个点死掉，则写操作即认为失败）、效率低。而异步则效率高（可合并数个请求再一次传播）、可用性高（不要求所有待写入点都严格可用）、但各副本会有一个不一致窗口（因为数据有可能还没传播完成）。
访问逻辑控制方式可有—— 多master 和单master 方式。多master是指每个副本存储点都可接受读写请求，且由其控制传播逻辑。而单master则只能有制定的点负责接收请求，其他点只负责接收 master传播过来的读写请求。显然多master效率更高，但更需要控制请求顺序，修正数据冲突。——往往需要借助诸如“数据核对”、“集中决算”等副本冲突解决机制。而单master由于读写都在一个点上串行化了，因此不用解决数据冲突，但缺点就是效率低。
上述四个方式可相互组合，各有利弊。你需要根据自己的应用情况，来选择合适的策略组合。（上述的各种技术google上都能找到丰富资料！）
1.3 WEB数据组织特点
WEB数据的组织特性可归纳如下：
1．非结构化和半结构化数据 —— web数据常常属于这种无明确schema的数据。它们字段稀疏、字段个数目不定、且字段可不断演化。
2．有向图的点边关系描述 —— 诸如朋友关系等信息，更适合有向图存储，而非关系数据库。
存储架构上的相应对策如下：
1 使用Truple space的方法存储非结构化数据。Truple space的特点是一条记录可包含任意多的属性值（muti map类似）。这和关系数据库不同，你的记录可以无固定的schema，因此很合适存储非机构化数据（目前amzon 的simpledb就是采用了此结构完成存储）
2 另外数据组织也更面向列。因为web数据挖掘更多不需要使用整条记录，而一般仅仅需要其中部分列就够了。另外web数据的产生也多是按列产生，而非一次就将以整条记录全部写入。由于这些原因，将数据按列组织、顺序存放数据更有利于磁头移动效率，也就是更有利于存储效率。
3 采用面向图的数据库。图数据库更有利于描述对象关系，而且很方便按照关系来遍历数据，对很多web应用更有效（代表例子是neo4j项目）。
另外要说明，WEB应用中的数据的检索要求一般较传统应用中低一些，很多情况下不需要支持join等多表间的联合操作。所以上述组织结构能满足大多数需求了。
第二部分：海量计算架构
当前大规模web应用的需要大量的计算能力（可想像一下page rank的计算量），显然单机已经提供这种计算力，所以计算自然需要采用分布计算。
分布计算的关键问题有两点：
1 算法是否可以划分成独立部分,以便能做分布计算。
2 获取计算数据以及中间结果存储代价很高，因为海量数据的读取会带来沉重的IO压。
对于这两个特点，目前采用的普遍架构是—— Map/Reduce架构，其概括来讲就是将计算划分成子计算,然后将计算程序下发到数据存储节点，就地进行计算——以减少IO消耗——后在合并出最终结果。（这并非一个创新思想，很久之前就有诸多尝试：比如IBM曾经搞国一个叫Aglet的移动代理项目，就是将计算程序下发到各节点计算和收集信息）。 Map就是划分任务阶段，reduce则是合并任务阶段；而任务划分是放到存储点进行本地计算的，最后再把这些中间结果交给reduce计算得到最终结果的。（关于这方面的资料请去看hadoop的开源实现吧）
第三部分：云计算
其概念看看：对云计算中几种基础设施（Dynamo,Bigtable,Map/Reduce等）的朴素看法
技术架构可参看：
1 谈谈云计算的部署方式——关于分布化实现
2 谈谈云计算的部署方式——关于虚拟化实现
