从Google Spanner漫谈分布式存储与数据库技术

第一篇：从Google Spanner漫谈分布式存储与数据库技术

从Google Spanner漫谈分布式存储与数据库技术

文/曹伟

Spanner 的设计反映了 Google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 Megastore 的数据模型，Chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 BigTable 中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner 代表了分布式数据库领域的新趋势——NewSQL。

Spanner 是 Google 最近公开的新一代分布式数据库，它既具有 NoSQL 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 SQL 的查询语言、支持表连接、支持事务（包括分布式事务）。Spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 Spanner 集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google 广告业务的后台（F1）已从 MySQL 分库分表方案迁移到了 Spanner 上。

数据模型

传统的 RDBMS（例如 MySQL）采用关系模型，有丰富的功能，支持 SQL 查询语句。而 NoSQL 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner 继承了 Megastore 的设计，数据模型介于 RDBMS 和 NoSQL 之间，提供树形、层次化的数据库 schema，一方面支持类 SQL 的查询语言，提供表连接等关系数据库的特性，功能上类似于 RDBMS；另一方面整个数据库中的所有记录都存储在同一个 key-value 大表中，实现上类似于 BigTable，具有 NoSQL 系统的可扩展性。

在 Spanner 中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表——用户表（Users）和相册表（Albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一个用户）对应着相册表中的多条记录（多个相册）。此外，要求子节点的主键必须以父节点的主键作为前缀。例如，用户表的主键（用户 ID）就是相册表主键（用户 ID+ 相册 ID）的前缀。

图 1 schema 示例，表之间的层次关系，记录排序后交错的存储

显然所有表的主键都将根节点的主键作为前缀，Spanner 将根节点表中的一条记录，和以其主键作为前缀的其他表中的所有记录的集合称作一个 Directory。例如，一个用户的记录及该用户所有相册的记录组成了一个 Directory。Directory 是 Spanner 中对数据进行分区、复制和迁移的基本单位，应用可以指定一个 Directory 有多少个副本，分别存放在哪些机房中，例如把用户的 Directory 存放在这个用户所在地区附近的几个机房中。

这样的数据模型具有以下好处。

 一个 Directory 中所有记录的主键都具有相同前缀。在存储到底层 key-value 大表时，会被分配到相邻的位置。如果数据量不是非常大，会位于同一个节点上，这不仅提高了数据访问的局部性，也保证了在一个 Directory 中发生的事务都是单机的。

 Directory 还实现了从细粒度上对数据进行分区。整个数据库被划分为百万个甚至更多个 Directory，每个 Directory 可以定义自己的复制策略。这种 Directory-based 的数据分区方式比 MySQL 分库分表时 Table-based 的粒度要细，而比 Yahoo!的 PNUTS 系统中 Row-based 的粒度要粗。

 Directory 提供了高效的表连接运算方式。在一个 Directory 中，多张表上的记录按主键排序，交错（interleaved）地存储在一起，因此进行表连接运算时无需排序即可在表间直接进行归并。

复制和一致性

Spanner 使用 Paxos 协议在多个副本间同步 redo 日志，从而保证数据在多个副本上是一致的。Google 的工程师钟情于 Paxos 协议，Chubby、Megastore 和 Spanner 等一系列产品都是在 Paxos 协议的基础上实现一致性的。

Paxos 的基本协议很简单。协议中有三个角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分别是读者和写者，Acceptor 相当于存储节点。整个协议描述的是，当系统中有多个 Proposer 和 Acceptor 时，每次 Proposer 写一个变量就会启动一轮决议过程（Paxos instance），如图 2 所示。决议过程可以保证即使多个 Proposer 同时写，结果也不会在 Acceptor 节点上不一致。确切地说，一旦某个 Proposer 提交的值被大多数 Acceptor 接受，那么这个值就被选中，在整轮决议的过程中该变量就不会再被修改为其他值。如果另一个 Proposer 要写入其他值，必须启动下一轮决议过程，而决议过程之间是串行（serializable）的。

图 2 Paxos 协议正常执行流程

一轮决议过程分为两个阶段，即 prepare 阶段和 accept 阶段。

 第一阶段A：Proposer 向所有 Acceptor 节点广播 prepare 消息，消息中只包含一个序号——N。Proposer 需要保证这个序号在这轮决议过程中是全局唯一的（这很容易做到，假如系统中有两个 Proposer，那么一个 Proposer 使用1，3，5，7，9，„„，另一个 Proposer 则使用0，2，4，6，8，„„）。



第一阶段B：Acceptor 接收到 prepare 消息后，如果N是到目前为止见过的最大序号，就返回一个 promise 消息，承诺不会接受序号小于N的请求；如果已接受过其他 Proposer 提交的值，则会将这个值连同提交这个值的请求的序号一同返回。 第二阶段A：当 Proposer 从大多数 Acceptor 节点收到了 promise 消息后，就可以选择接下来要向 Acceptor 提交的值了。一般情况下，当然选原本打算写入的值，但如果从收到的 promise 消息中发现已经有其他值被 Acceptor 接受了，那么为了避免造成数据不一致的风险，这时 Proposer 就必须“大义灭亲”，放弃自己打算写入的值，从其他 Proposer 提交的序号中选择一个最大的值。接下来 Proposer 向所有的 Acceptor 节点发送 accept 包，其中包含在第一阶段中挑选的序号N和刚才选择的值V。



第二阶段B：Acceptor 收到 accept 包之后，如果N的大小不违反对其他

Proposer 的承诺，就接受这个请求，记录下值V和序号N，返回一个 ack 消息。反之，则返回一个 reject 消息。

如果 Proposer 从大多数 Acceptor 节点收到了 ack 消息，说明写操作成功。而如果在写操作过程中失败，Proposer 可以增大序号，重新执行第一阶段。

基本的 Paxos 协议可以保证值一旦被选出后就一定不会改变，但不能保证一定会选出值来。换句话说，这个投票算法不一定收敛。有两个方法可以加速收敛的过程：一个是在出现冲突后通过随机延迟把机会让给其他 Proposer，另一个是尽量让系统中只有一个 Proposer 去提交。在 Chubby 和 Spanner 系统中这两种方法都用上了，先用随机延迟的方法通过一轮 Paxos 协议，在多个 Proposer 中选举出一个 leader 节点。接下来所有的写操作都通过这个 leader 节点，而 leader 节点一般还是比较“长寿”的，在广域网环境下平均“任期”可以达到一天以上。而 Megastore 系统中没有很好地解决这个问题，所有的 Proposer 都可以发起写操作，这是 Megastore 写入性能不高的原因之一。

基本的 Paxos 协议还存在性能上的问题，一轮决议过程通常需要进行两个回合通信，而一次跨机房通信的代价为几十到一百毫秒不等，因此两个回合的通信就有点开销过高了。不过幸运的是，绝大多数情况下，Paxos 协议可以优化到仅需一个回合通信。决议过程的第一阶段是不需要指定值的，因此可以把 prepare/promise 的过程捎带在上一轮决议中完成，或者更进一步，在执行一轮决议的过程中隐式地涵盖接下来一轮或者几轮决议的第一阶段。这样，当一轮决议完成之后，其他决议的第一阶段也已经完成了。如此看来，只要 leader 不发生更替，Paxos 协议就可以在一个回合内完成。为了支持实际的业务，Paxos 协议还需要支持并发，多轮决议过程可以并发执行，而代价是故障恢复会更加复杂。

因为 leader 节点上有最新的数据，而在其他节点上为了获取最新的数据来执行 Paxos 协议的第一阶段，需要一个回合的通信代价。因此，Chubby 中的读写操作，以及 Spanner 中的读写事务都仅在 leader 节点上执行。而为了提高读操作的性能，减轻 leader 节点的负载，Spanner 还提供了只读事务和本地读。只读事务只在 leader 节点上获取时间戳信息，再用这个时间戳在其他节点上执行读操作；而本地读则读取节点上最新版本的数据。

与 Chubby、Spanner 这种读写以 leader 节点为中心的设计相比，Megastore 体现了一定的“去中心化”设计。每个客户端都可以发起 Paxos 写操作，而读操作则尽可能在本地执行。如果客户端发现本地数据不是最新的，会启动 catchup 流程更新数据，再执行本地读操作返回给客户端。

最后，对比下其他系统中 replication 的实现。在 BigTable 系统中每个 tablet 服务器是没有副本的，完全依赖底层 GFS 把数据存到多台机器上。数据的读写都通过单个 tablet 服务器，在 tablet 服务器出现故障的时需要 master 服务器将 tablet 指派到其他 tablet 服务器上才能恢复可用。Dynamo 系统则贯彻了“去中心化”的思想，将数据保存在多个副本上，每个副本都可以写入（update everywhere）。而不同副本同时写入的数据可能会存在不一致，则需要使用版本向量（version vector）记录不同的值和时间戳，由应用去解释或合并不一致的数据。尽管 Dynamo 系统还提供了 NWR 的方式来支持有一致性保证的读写操作，但总的来说 Dynamo 为了高可用性牺牲了一致性。ZooKeeper、MongoDB 与 Chubby、Spanner 类似，通过 leader 选举协议从多个副本中选择一个 leader，所有写操作都在经过 leader 节点序列化后，同步到其他副本上。ZooKeeper 则是在写入大多数节点后返回，而 MongoDB 主要采用异步的主从复制方式。

分布式事务

Spanner 系统中的分布式事务通过两阶段提交协议（2PC）实现。2PC 是一类特殊的一致性协议，假设一个分布式事务涉及了多个数据节点，2PC 可以保证在这些节点上的操作要么全部提交，要么全部失败，从而保证了整个分布式事务的原子性（ACID 里的A）。协议中包含两个角色：协调者（coordinator）和参与者（participant/cohort）。协调者是分布式事务的发起者，而参与者是参与了事务的数据节点。在协议最基本的形式中，系统中有一个协调者和多个参与者。

顾名思义，2PC 也包含两个阶段，即投票阶段和提交阶段（如图 3 所示）。

图 3 两阶段提交协议  在第一阶段，协调者向所有的参与者发送投票请求，每个参与者决定是否要提交事务。如果打算提交的话需要写好 redo、undo 等日志，并向协调者回复 yes 或 no。

 在第二阶段，协调者收到所有参与者的回复，如果都是 yes，那么决定提交这个事务，写好日志后向所有参与者广播提交事务的通知。反之，则中止事务并且通知所有参与者。参与者收到提交/中止事务的命令后，执行相应操作，如果提交的话还需要写日志。

协议过程包括两回合的通信，在协调者和参与者端需要多次写日志，而且整个过程中所有参与者都占有读锁、写锁，可见 2PC 开销不菲。

2PC 最令人诟病之处还不在于性能，而是在有些故障条件下，会造成所有参与者占有读锁、写锁堵塞在第二阶段，需要人工干预才能继续，存在严重的可用性隐患。假设故障发生在第二阶段，协调者在做出决定后，通知完一个参与者就宕机了，更糟糕的是被通知的这位参与者在执行完“上级指示”之后也宕机了，这时对其他参与者来说，就必须堵塞在那里等待结果。

Spanner 利用基于 Paxos 协议的复制技术，改善了 2PC 的可用性问题。2PC 协议过程中的协调者和参与者生成的日志都会利用 Paxos 协议复制到所有副本中，这样无论是协调者或参与者宕机，都会有其他副本代替它们，完成 2PC 过程而不至于堵塞。在 Paxos 协议上实现 2PC 这一思路很巧妙，Paxos 协议保证了大多数节点在线情况下的可用性，而 2PC 保证了分布式协议的一致性。

事件的顺序

传统上，在设计一个分布式系统时，都会假设每个节点的运行速度和时钟的快慢各不相同的情况，并且在节点之间进行同步的唯一方法就是异步通信。系统中的每个节点都扮演着观察者的角色，并从其他节点接收事件发生的通知。判断系统中两个事件的先后顺序主要依靠分析它们的因果关系，包括 Lamport 时钟、向量时钟等算法，而这一切都存在通信开销。

因此，Spanner 提出了一种新的思路，在不进行通信的情况下，利用高精度和可观测误差的本地时钟（TrueTime API）给事件打上时间戳，并且以此比较分布式系统中两个事件的先后顺序。利用这个方法，Spanner 实现了事务之间的外部一致性（external consistency）（如图 4 所示），也就是说，一个事务结束后另一个事务才开始，Spanner 可以保证第一个事务的时间戳比第二个事务的时间戳要早，从而两个事务被串行化后也一定能保持正确的顺序。

图 4 事务外部一致性的实现

TrueTime API 是一个提供本地时间的接口，但与 Linux 上 gettimeofday 接口不一样的是，它除了可以返回一个时间戳t，还会给出一个误差ε。例如，返回的时间戳是 1 分 30 秒 350 毫秒，而误差是 5 毫秒，那么真实的时间在 1 分 30 秒 345 毫秒到 355 毫秒之间。真实的系统中ε平均下来是 4 毫秒。

利用 TrueTime API，Spanner 可以保证给出的事务标记的时间戳介于事务开始的真实时间和事务结束的真实时间之间。假如事务开始时 TrueTime API 返回的时间是{t1, ε1}，此时真实时间在 t1-ε1到 t1+ε1之间；事务结束时 TrueTime API 返回的时间是{t2, ε2}，此时真实时间在 t2-ε2到 t2+ε2之间。Spanner 会在 t1+ε1和 t2-ε2之间选择一个时间点作为事务的时间戳，但这需要保证 t1+ε1小于 t2-ε2，为了保证这点，Spanner 会在事务执行过程中等待，直到 t2-ε2大于 t1+ε1时才提交事务。由此可以推导出，Spanner 中一个事务至少需要2ε的时间（平均 8 毫秒）才能完成。

由此可见，这种新方法虽然避免了通信开销，却引入了等待时间。为了保证外部一致性，写延迟是不可避免的，这也印证了 CAP 定理所揭示的法则，一致性与延迟之间是需要权衡的。

最后介绍一下 TrueTime API 的实现。TrueTime API 的实现大体上类似于网络时间协议（NTP），但只有两个层次。第一层次，服务器是拥有高精度计时设备的，每个机房若干台，大部分机器都装备了 GPS 接收器，剩下少数机器是为 GPS 系统全部失效的情况而准备的，叫做“末日”服务器，装备了原子钟。所有的 Spanner 服务器都属于第二层，定期向多个第一层的时间服务器获取时间来校正本地时钟，先减去通信时间，再去除异常值，最后求交集。

NewSQL

六年前，BigTable 展示了一个简洁、优美、具有高可扩展性的分布式数据库系统，引起了 NoSQL 浪潮。然而 Spanner 的设计者们指出了 BigTable 在应用中遇到的一些阻力。

 缺少类似 SQL 的界面，缺少关系数据库拥有的丰富的功能。 只支持单行事务，缺少跨行事务。



需要在跨数据中心的多个副本间保证一致性。

这些来自应用开发者的需求催生了 Spanner，一个既拥有 key-value 系统的高可扩展性，也拥有关系数据库的丰富功能（包括事务、一致性等特性）的系统。这类兼顾可扩展性和关系数据库功能的产品被称为“NewSQL”，Spanner 的公开会不会开启 NewSQL 的时代呢？我们拭目以待。

总结

最后从 CAP 定理的角度来分析下 Spanner。

CAP 定理是指在网络可能出现分区故障的情况下，一致性和可用性不可得兼。形式化地说就是，P => 非(A与P)，可以更进一步地总结为，一致性和延迟之间必须进行权衡。Paxos 协议在C和A之间选择了严格的一致性，而A则降级为大多数一致性（majority available）。

Spanner 还通过在事务中增加延迟的方法实现了外部一致性，每个事务需要至少两倍的时钟误差才能完成。如果时钟出现故障造成误差增长，那么完成事务所需的时间也就随之增长。在这里，时钟故障也应当认为是P的一种形式。在发生时钟故障（P）的情况下，为了保证一致性（C），而必须增加延迟（A），这一点充分印证了 CAP 定理。

从 Spanner 系统中，我们可以学习到一些经验。

 MegaStore、Spanner 和 F1 系统所选择的树形、层次化的数据库 schema 是很精妙的，它能支持高效的表连接，这既提供了类似关系模型的范式，也提供了一个合适的粒度进行数据分区，具有好的可扩展性，H-Store 也采用了这样的 schema。

 跨数据中心的多个副本间保持一致是可行的，Paxos 协议的性能可以优化到一个可接受的范围。

 在 Paxos 协议的基础之上实现的两阶段提交的可用性得到了提高。 在一个分布式系统中，本地时钟的作用可以比我们之前想象的大很多。

作者曹伟，淘宝核心系统数据库组技术专家，从事高性能服务器、IM、P2P、微博等各类型分布式系统、海量存储产品的开发，关注系统高可用性和一致性及分布式事务领域。

第二篇：Google Megastore分布式存储技术全揭秘

Google Megastore分布式存储技术全揭秘

导读：本文根据Google最新Megastore论文翻译而来，原作者为Google团队，团队人员包括：Jason Baker，Chris Bond，James C.Corbett，JJ Furman，Andrey Khorlin，James Larson，Jean-Michel Léon，Yawei Li，Alexander Lloyd，Vadim Yushprakh。翻译者为国内知名IT人士。

在上个月举行的创新数据系统研讨会上(CIDR)，Google公开了其Megastore分布式存储技术的白皮书。

Megastore是谷歌一个内部的存储系统，它的底层数据存储依赖Bigtable，也就是基于NoSql实现的，但是和传统的NoSql不同的是，它实现了类似RDBMS的数据模型(便捷性)，同时提供数据的强一致性解决方案(同一个datacenter，基于MVCC的事务实现)，并且将数据进行细颗粒度的分区(这里的分区是指在同一个datacenter，所有datacenter都有相同的分区数据)，然后将数据更新在机房间进行同步复制(这个保证所有datacenter中的数据一致)。Megastore的数据复制是通过paxos进行同步复制的，也就是如果更新一个数据，所有机房都会进行同步更新，因为使用paxos进行复制，所以不同机房针对同一条数据的更新复制到所有机房的更新顺序都是一致的，同步复制保证数据的实时可见性，采用paxos算法则保证了所有机房更新的一致性，所以个人认为megastore的更新可能会比较慢，而所有读都是实时读(对于不同机房是一致的)，因为部署有多个机房，并且数据总是最新。

为了达到高可用性，megastore实现了一个同步的，容错的，适合长距离连接的日志同步器 为了达到高可扩展性，megastore将数据分区成一个个小的数据库，每一个数据库都有它们自己的日志，这些日志存储在NoSql中 Megastore将数据分区为一个Entity Groups的集合，这里的Entity Groups相当于一个按id切分的分库，这个Entity Groups里面有多个Entity Group(相当于分库里面的表)，而一个Entity Group有多个Entity(相当于表中的记录)

在同一个Entity Group中(相当于单库)的多个Entity的更新事务采用single-phase ACID事务，而跨Entity Group(相当于跨库)的Entity更新事务采用two-phase ACID事务(2段提交)，但更多使用Megastore提供的高效异步消息实现。需要说明的一点是，这些事务都是在同一个机房的，机房之间的数据交互都是通过数据复制来实现的。

传统关系型数据库使用join来满足用户的需求，对于Megastore来说，这种模型(也就是完全依赖join的模型)是不合适的。原因包括

1.高负载交互性型应用能够从可预期的性能提升得到的好处多于使用一种代价高昂的查询语言所带来的好处。2.Megastore目标应用是读远远多于写的，所以更好的方案是将读操作所需要做的工作转移到写操作上面(比如通过具体值代替外键以消除join)3.因为megastore底层存储是采用BigTable，而类似BigTable的key-value存储对于存取级联数据是直接的

所以基于以上几个原因，Megastore设计了一种数据模型和模式语言来提供基于物理地点的细颗粒度控制，级联布局，以及申明式的不正规数据存储来帮助消除大部分joins。查询时只要指定特定表和索引即可。

当然可能有时候不得不使用到join，Megastore提供了一种合并连接算法实现，具体算法这里我还是没弄清楚，原文是[the user provides multiple queries that return primary keys for the same table in the same order;we then return the intersection of keys for all the provided queries.] 使用Megastore的应用通过并行查询实现了outer joins。通常先进行一个初始的查询，然后利用这个查询结果进行并行索引查询，这个过程我理解的是，初始查询查出一条数据，就马上根据这个结果进行并行查询，这个时候初始查询继续取出下一条数据，再根据这个结果并行查询(可能前面那个外键查询还在继续，使用不同的线程)。这种方法在初始查询数据量较小并且外键查询使用并行方式的情况下，是一种有效的并且具有sql风格的joins。Megastore的数据结构介于传统的RDBMS和NoSql之间的，前者主要体现在他的schema表示上，而后者体现在具体的数据存储上(BigTable)。和RDBMS一样，Megastore的数据模型是定义schema中并且是强类型的。每一个schema有一个表集合，每个表包含一个实体集合(相当于record)，每个实体有一系列的属性(相当于列属性)，属性是命名的，并且指定类型，这些类型包括字符串，各种数字类型，或者google的protocol buffer。这些属性可以被设置成必需的，可选的，或者可重复的(一个属性上可以具有多个值)。一个或者多个属性可以组成一个主键。

在上图中，User和Photo共享了一个公共属性user_id，IN TABLE User这个标记直接将Photo和User这两张表组织到了同一个BigTable中，并且键的顺序(PRIMARY KEY(user_id,photo_id)？是这个还是schema中定义的顺序？)保证Photo的实体存储在对应的User实体邻接位置上。这个机制可以递归的应用，加速任意深度的join查询速度。这样，用户能够通过操作键的顺序强行改变数据级联的布局。其他标签请参考原文。Megastore支持事务和并发控制。一个事务写操作会首先写入对应Entity Group的日志中，然后才会更新具体数据。BigTable具有一项在相同row/column中存储多个版本带有不同时间戳的数据。正是因为有这个特性，Megastore实现了多版本并发控制(MVCC，这个包括oracle，innodb都是使用这种方式实现ACID，当然具体方式会有所不同)：当一个事务的多个更新实施时，写入的值会带有这个事务的时间戳。读操作会使用最后一个完全生效事务的时间戳以避免看到不完整的数据.读写操作不相互阻塞，并且读操作在写事务进行中会被隔离(？)。

Megastore 提供了current，snapshot，和inconsistent读，current和snapshot级别通常是读取单个entity group。当开始一个current读操作时，事务系统会首先确认所有之前提交的写已经生效了；然后系统从最后一个成功提交的事务时间戳位置读取数据。对于snapshot读取，系统拿到己经知道的完整提交的事务时间戳并且从那个位置直接读取数据，和current读取不同的是，这个时候可能提交的事务更新数据还没有完全生效(提交和生效是不同的)。Megastore提供的第三种读就是inconsistent读，这种读无视日志状态并且直接读取最后一个值。这种方式的读对于那些对减少延迟有强烈需求，并且能够容忍数据过期或者不完整的读操作是非常有用的。

一个写事务通常开始于一个current读操作以便确定下一个可用的日志位置。提交操作将数据变更聚集到日志，并且分配一个比之前任何一个都高的时间戳，并且使用Paxos将这个log entry加入到日志中。这个协议使用了乐观并发：即使有可能有多个写操作同时试图写同一个日志位置，但只会有1个成功。所有失败的写都会观察到成功的写操作，然后中止，并且重试它们的操作。咨询式的锁定能够减少争用所带来的影响。通过特定的前端服务器分批写入似乎能够完全避免竞争(这几句有些不能理解)[ Advisory locking is available to reduce the effects of contention.Batching writes through session affinity to a particular front-end server can avoid contention altogether.]。完整事务生命周期包括以下步骤：

1.读：获取时间戳和最后一个提交事务的日志位置

2.应用逻辑：从BigTable读取并且聚集写操作到一个日志Entry 3.提交：使用Paxos将日志Entry加到日志中 4.生效：将数据更新到BigTable的实体和索引中 5.清理：删除不再需要的数据

写操作能够在提交之后的任何点返回，但是最好还是等到最近的副本(replica)生效(再返回)。Megastore提供的消息队列提供了在不同Entity Group之间的事务消息。它们能被用作跨Entity Group的操作，在一个事务中分批执行多个更新，或者延缓工作(？)。一个在单个Entity Group上的事务能够原子性地发送或者收到多个信息除了更新它自己的实体。每个消息都有一个发送和接收的Entity Group；如果这两个Entity Group是不同的，那么传输将会是异步的。

消息队列提供了一种将会影响到多个Entity Group的操作的途径，举个例子，日历应用中，每一个日历有一个独立的Entity Group，并且我们现在需要发送一个邀请到多个其他人的日历中，一个事务能够原子地发送邀请消息到多个独立日历中。每个日历收到消息都会把邀请加入到它自己的事务中，并且这个事务会更新被邀请人状态然后删除这个消息。Megastore大规模使用了这种模式：声明一个队列后会自动在每一个Entity Group上创建一个收件箱。Megastore支持使用二段提交进行跨Entity Group的原子更新操作。因为这些事务有比较高的延迟并且增加了竞争的风险，一般不鼓励使用。

接下来内容具体来介绍下Megastore最核心的同步复制模式：一个低延迟的Paxos实现。Megastore的复制系统向外提供了一个单一的，一致的数据视图，读和写能够从任何副本(repli ca)开始，并且无论从哪个副本的客户端开始，都能保证ACID语义。每个Entity Group复制结束标志是将这个Entity Group事务日志同步地复制到一组副本中。写操作通常需要一个数据中心内部的网络交互，并且会跑检查健康状况的读操作。current级别的读操作会有以下保证：

1.一个读总是能够看到最后一个被确认的写。(可见性)2.在一个写被确认后，所有将来的读都能够观察到这个写的结果。(持久性，一个写可能在确认之前就被观察到)数据库典型使用Paxos一般是用来做事务日志的复制，日志中每个位置都由一个Paxos实例来负责。新的值将会被写入到之前最后一个被选中的位置之后。

Megastore在事先Paxos过程中，首先设定了一个需求，就是current reads可能在任何副本中进行，并且不需要任何副本之间的RPC交互。因为写操作一般会在所有副本上成功，所以允许在任何地方进行本地读取是现实的。这些本地读取能够很好地被利用，所有区域的低延迟，细颗粒度的读取failover，还有简单的编程体验。

Megastore设计实现了一个叫做Coordinator(协调者)的服务，这个服务分布在每个副本的数据中心里面。一个Coordinator服务器跟踪一个Entity Groups集合，这个集合中的Entity Groups需要具备的条件就是它们的副本已经观察到了所有的Paxos写。在这个集合中的Entity Groups，它们的副本能够进行本地读取(local read)。

写操作算法有责任保持Coordinator状态是保守的，如果一个写在一个副本上失败了，那么这次操作就不能认为是提交的，直到这个entity group的key从这个副本的coordinator中去除。(这里不明白)为了达到快速的单次交互的写操作，Megastore采用了一种Master-Slave方式的优化，如果一次写成功了，那么会顺带下一次写的保证(也就是下一次写就不需要prepare去申请一个log position)，下一次写的时候，跳过prepare过程，直接进入accept阶段。Megastore没有使用专用的Masters，但是使用Leaders。

Megastore为每一个日志位置运行一个Paxos算法实例。[ The leader for each log position is a distinguished replica chosen alongside the preceding log position's consensus value.] Leader仲裁在0号提议中使用哪一个值。第一个写入者向Leader提交一个值会赢得一个向所有副本请求接收这个值做为0号提议最终值的机会。所有其他写入者必需退回到Paxos的第二阶段。

因为一个写入在提交值到其他副本之前必需和Leader交互，所以必需尽量减少写入者和Leader之间的延迟。Megastore设计了它们自己的选取下一个写入Leader的规则，以同一地区多数应用提交的写操作来决定。这个产生了一个简单但是有效的原则：使用最近的副本。(这里我理解的是哪个位置提交的写多，那么使用离这个位置最近的副本做为Leader)Megastore的副本中除了有日志有Entity数据和索引数据的副本外，还有两种角色，其中一种叫做观察者(Witnesses)，它们只写日志，并且不会让日志生效，也没有数据，但是当副本不足以组成一个quorum的时候，它们就可以加入进来。另外一种叫只读副本(Read-Only)，它刚刚和观察者相反，它们只有数据的镜像，在这些副本上只能读取到最近过去某一个时间点的一致性数据。如果读操作能够容忍这些过期数据，只读副本能够在广阔的地理空间上进行数据传输并且不会加剧写的延迟。

上图显示了Megastore的关键组件，包括两个完整的副本和一个观察者。应用连接到客户端库，这个库实现了Paxos和其他一些算法：选择一个副本进行读，延迟副本的追赶，等等。

Each application server has a designated local replica.The client library makes Paxos operations on that replica durable by submitting transactions directly to the local Bigtable.To minimize wide-area roundtrips, the library submits remote Paxos operations to stateless intermediary replication servers communicating with their local Bigtables.客户端，网络，或者BigTable失败可能让一个写操作停止在一个中间状态。复制的服务器会定期扫描未完成的写入并且通过Paxos提议没有操作的值来让写入完成。

接下来介绍下Megastore的数据结构和算法，每一个副本存有更新和日志Entries的元数据。为了保证一个副本能够参与到一个写入的投票中即使是它正从一个之前的宕机中恢复数据，Megastore允许这个副本接收不符合顺序的提议。Megastore将日志以独立的Cells存储在BigTable中。

当日志的前缀不完整时(这个前缀可能就是一个日志是否真正写入的标记，分为2段，第一段是在写入日志之前先写入的几个字节，然后写入日志，第二段是在写入日志之后写入的几个字节，只有这个日志前缀是完整的，这个日志才是有效的)，日志将会留下holes。下图表示了一个单独Megastore Entity Group的日志副本典型场景。0-99的日志位置已经被清除了，100的日志位置是部分被清除，因为每个副本都会被通知到其他副本已经不需要这个日志了。101日志位置被所有的副本接受了(accepted)，102日志位置被Y所获得，103日志位置被A和C副本接受，B副本留下了一个hole，104日志位置因为副本A和B的不一致，复本C的没有响应而没有一致结果。

在一个current读的准备阶段(写之前也一样)，必需有一个副本要是最新的：所有之前更新必需提交到那个副本的日志并且在该副本上生效。我们叫这个过程为catchup。省略一些截止超时的管理，一个current读算法步骤如下：

1.本地查询：查询本地副本的Coordinator，判定当前副本的Entity Group是最新的 2.查找位置：确定最高的可能已提交的日志位置，然后选择一个己经将这个日志位置生效的副本

a.(Local read)如果步骤1发现本地副本是最新的，那么从本地副本中读取最高的被接受(accepted)的日志位置和时间戳。

b.(Majority read)如果本地副本不是最新的(或者步骤1或步骤2a超时)，那么从一个多数派副本中发现最大的日志位置，然后选取一个读取。我们选取一个最可靠的或者最新的副本，不一定总是是本地副本

3.追赶：当一个副本选中之后，按照下面的步骤追赶到已知的日志位置: a.对于被选中的不知道共识值的副本中的每一个日志位置，从另外一个副本中读取值。对于任何一个没有已知已提交的值的日志位置，发起一个没有操作的写操作。Paxos将会驱动多数副本在一个值上打成共识-----可能是none-op的写操作或者是之前提议的写操作 b.顺序地将所有没有生效的日志位置生效成共识的值，并将副本的状态变为到分布式共识状态(应该是Coordinator的状态更新)如果失败，在另外一个副本上重试。4.验证：如果本地副本被选中并且之前没有最新，发送一个验证消息到coordinator断定(entity group,replica)能够反馈(reflects)所有提交的写操作。不要等待回应----如果请求失败，下一个读操作会重试。

5.查询数据：从选中的副本中使用日志位置所有的时间戳读取数据。如果选中的副本不可用，选取另外一个副本重新开始执行追赶，然后从它那里读取。一个大的读取结果有可能从多个副本中透明地读取并且组装返回

注意在实际使用中 1和2a通常是并行执行的。

在完整的读操作算法执行后，Megastore发现了下一个没有使用的日志位置，最后一个写操作的时间戳，还有下一个leader副本。在提交时刻，所有更新的状态都变为打包的(packaged)和提议(proposed)，并且包含一个时间戳和下一个leader 候选人，做为下一个日志位置的共识值。如果这个值赢得了分布式共识，那么这个值将会在所有完整的副本中生效。否则整个事务将会终止并且必需重新从读阶段开始。

就像上面所描述的，Coordinators跟踪Entity Groups在它们的副本中是否最新。如果一个写操作没有被一个副本接受，我们必需将这个Entity Group的键从这个副本的Coordinator中移除。这个步骤叫做invalidation(失效)。在一个写操作被认为提交的并且准备生效，所有副本必需已经接受或者让这个Entity Group在它们coordinator上失效。写算法的步骤如下：

1.接受Leader：请求Leader接受值做为0号提议的值。如果成功。跳到第三步

2.准备：在所有副本上执行Paxos Prepare阶段，使用一个关于当前log位置更高的提议号。将值替换成拥有最高提议号的那个值。[Replace the value being written withthe highest-numbered proposal discovered, if any] 3.接受：请求余下的副本接受这个值。如果多数副本失败，转到第二步。4.失效：将没有接受值的副本coordinator失效掉。错误处理将在接下来描述

5.生效：将更新在尽可能多的副本上生效。如果选择的值不同于原始提议的，返回冲突错误[？]

Coordinator进程在每一个数据中心运行并且只保持其本地副本的状态。在上述的写入算法中，每一个完整的副本必需接受或者让其coordinator失效，所以这个可能会出现任何单个副本失效就会引起不可用。在实际使用中这个不是一个寻常的问题。Coordinator是一个简单的进程，没有其他额外的依赖并且没有持久存储，所以它表现得比一个BigTable服务器更高的稳定性。然而，网络和主机失败仍然能够让coordinator不可用。

Megastore使用了Chubby锁服务：Coordinators在启动的时候从远程数据中心获取指定的Chubby locks。为了处理请求，一个Coordinator必需持有其多数locks。一旦因为宕机或者网络问题导致它丢失了大部分锁，它就会恢复到一个默认保守状态----认为所有在它所能看见的Entity Groups都是失效的。随后(该Coordinator对应的)副本中的读操作必需从多数其他副本中得到日志位置直到Coordinator重新获取到锁并且Coordinator的Entries重新验证的。

写入者通过测试一个Coordinator是否丢失了它的锁从而让其在Coordinator不可用过程中得到保护：在这个场景中，一个写入者知道在恢复之前Coordinator会认为自己是失效的。在一个数据中心活着的Coordinator突然不可用时，这个算法需要面对一个短暂(几十秒)的写停顿风险---所有的写入者必需等待Coordinator的Chubby locks过期(相当于等待一个master failover后重新启动)，不同于master failover，写入和读取都能够在coordinator状态重建前继续平滑进行。除了可用性问题，对于Coordinator的读写协议必需满足一系列的竞争条件。失效的信息总是安全的，但是生效的信息必需小心处理。在coordinator中较早的写操作生效和较晚的写操作失效之间的竞争通过带有日志位置而被保护起来。标有较高位置的失效操作总是胜过标有较低位置的生效操作。一个在位置n的失效操作和一个在位置m

总体来说，使用Coordinator从而能够在任何数据中心进行快速的本地读取对于可用性的影响并不是完全没有的。但是实际上，以下因素能够减轻使用Coordinator所带来的问题。1.Coordinators是比任何的BigTable 服务器更加简单进程，机会没有依赖，所以可用性更高。

2.Coordinators简单，均匀的工作负载让它们能够低成本地进行预防措施。3.Coordinators轻量的网络传输允许使用高可用连接进行服务质量监控。

4.管理员能够在维护期或者非安全期集中地让一批Coordinators失效。对于默写信号的监测是自动的。

5.一个Chubby qunrum能够监测到大多数网络问题和节点不可用。总结

文章总体介绍了下google megastore的实现思路，其主要解决的问题就是如何在复杂的环境下(网络问题,节点失效等等)保证数据存取服务的可用性。对于多机房，多节点，以及ACID事务支持，实时非实时读取，错误处理等等关键问题上给出了具体方案。

第三篇：分布式OA系统的数据库同步复制技术

分布式OA系统的数据库同步复制技术

一、背景概述

随着政府上网、电子政务的不断普及和深入，IBM公司的Lotus Domino系统在国内得到广泛的应用。其中不乏大型的、跨地域的企事业单位或集团公司应用案例。这些案例一般采用分布式系统结构，即分布在全国各地的分支机构分别设有独立的数据库服务器，各地数据库服务器采用数据库同步复制的方式更新本地数据库复本内容。从而使得各地终端用户及时、快捷、可靠地访问到最新公告、新闻等。

本文结合呼和浩特铁路局客运公司办公自动化系统案例讨论基于IBM公司的Lotus Domino技术构建的分布式OA系统中数据库之间的同步复制技术。

二、几个概念

IBM公司的Lotus产品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server为后台数据库平台，Lotus Notes为客户端，Lotus Domino Administrator为系统管理平台，Lotus Domino Designer设计开发工具。先介绍几个Domino中和同步复制有关的概念。

1、复制

Notes允许在多个服务器或工作站上保存数据库的多个拷贝，这些拷贝称做“复本”。它们使各个地方的不同网络上的用户共享相同的信息。复本与文件的拷贝不同之处在于在复制时源文件与其复本具有相同的复本标识符。

复制是在复本之间共享更改信息的过程。复制时，Notes通过把更改信息从一个复本拷贝到另一个复本来更新复本。最终，Notes 使所有复本保持一致。可以选择在复本拷贝之间进行复制，这时两个复本都发送并接收更新信息，或者选择仅从一个复本复制到另一个复本。

也可以定期安排复制，或者根据需要手动进行复制。复制可以在两台服务器之间或者在服务器和工作站之间进行。如果设定为定期进行完整复制，那么 Notes会根据时间使所有复本保持同步。

2、复本标识符

复本与源文件或数据库有相同的复本标识符。这是数据库的复本与拷贝的区别所在，因为有共同的标识符才能使复本与源数据库之间可以复制更改信息。如果数据库的两个拷贝具有不同的复本标识符，则不能在它们之间进行复制。

3、复制冲突和保存冲突

在复制之间，如果有两个或多个用户对相同文档的不同复本进行了编辑，就会导致复制冲突。而保存冲突则是在两个或多个用户同时编辑服务器上同一个数据库的同一个文档时发生。当发生复制冲突或保存冲突时，Notes 将在视图页面左边把发生冲突的文档标注出来。

Notes对复制冲突的处理是这样的，在两个或多个用户编辑并保存同一个文档之后，下次进行复制时，Notes 将编辑和保存最频繁的文档指定为主文档，而将其他文档显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。如果用户在一个复本中编辑并保存了某文档，然后另一个用户将该文档删除，则认为该文档是被删除的。然而，如果文档被编辑和保存了多次，或者在该文档被删除之后又被另一个用户编辑和保存过，则把编辑过的文档作为主文档。

Note对保存冲突的处理如下，当多个用户同时打开相同的文档进行编辑时，Notes指定最先保存的文档为主文档。当另一个用户试图保存同一文档时，Notes 就会提示该用户把它作为“保存冲突”文档来保存。如果用户这样做了，那么 Notes 将它显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。

根据笔者的经验，在实际开发过程中，我们应该通过设计控制保存冲突，避免文档产生“保存冲突”的答复文档。对于复制冲突可以设置数据库合并复制冲突，这样如果产生增量改动，服务器在复制过程中会自动合并冲突。需要说明的是，Notes在进行复制时，并不是传统意义上的完全拷贝，而是一系列的规则进行增量的合并。

4、复制类型

Domino中支持四种不同的复制方式

拉入推出：是一个双向过程。此过程进行时，呼叫服务器从响应服务器拉入更新，然后向响应服务器推出自己的更新。使用“拉入推出”时，呼叫服务器上的 Replicator 任务执行所有的工作。拉入推出是系统缺省的复制方式。

分别拉入：是两个服务器交换更新的双向过程。使用“分别拉入”时，两个复制器（一个在呼叫服务器上，另一个在响应服务器上）共同进行复制工作。

只推出：是呼叫服务器向响应服务器推出更新的单向过程。单向复制总是比双向复制耗时少。只拉入：是呼叫服务器从响应服务器拉入更新的单向过程。单向复制总是比双向复制耗时少。

三、案例

笔者曾经参与呼和浩特铁路局客运公司办公自动化系统的设计、开发和实施工作。呼和浩特铁路局客运公司包括三个信息中心，分别在呼和浩特市、包头市和东河区三个地方，三地之间通过64K的DDN专线连接。因为带宽的限制，用户远程访问速度成为本系统的瓶颈，经过再三论证，我们决定构建分布式数据库存储架构，采用后台数据库实时同步复制技术使三个异地服务器内容一致，将远程访问转化为本地访问，从而提高终端用户访问速度。

详细步骤如下。

1、安装服务器

在三地信息中心分别安装Domino服务器，服务器的详细配置并不复杂，读者可以参阅相关资料，一般情况下按照安装配置向导四步就可以快捷配置完毕。注意三台Domino服务器不要同名，其简单拓扑结构如下：

图中呼市处于相对中心的位置，所以呼市和包头之间，呼市和东河之间分别建立了互推复制机制，为了降低网络负担和流通环节，没有建立包头和东河之间的复制，各地直接通过与呼市同步来保持三地数据的一致。一般而言，如果各分支机构处于平等位置，互相之间的数据流量相当，也可以两两之间建立复制机制。

2、建立服务器之间的连接

对于两个服务器之间进行的复制，应创建一个“连接”文档来指定进行信息交换的方式和时间。“连接”文档存储在“Domino 目录”中。一次仅使用一个“连接”文档来处理每对服务器之间的所有复制。创建不必要的“连接”文档会增加网络传输量和阻塞。

缺省情况下，邮件路由和复制都已被启用，但是可以更改此设置并使用单独的“连接”文档来安排每项任务。这样，就可以分别控制复制和邮件路由的特定时间、时间范围或重复间隔，并根据需要增加或减小这些设置。

怎么保证服务器之间的连接能顺利的连通？实际上对于物理连接形式Domino并不关心，也就是说物理上无论通过什么连接方式，专线、光纤、X.25、电话拨号等，只要TCP/IP通，简单说只要能Ping通，就能够保证服务器之间顺利连接。

下面给出了建立服务器之间连接的操作步骤和主要参数的设置说明：

A）在 Domino Administrator 中单击“配置”附签。

B）在“使用目录”域中选择连接服务器的“Domino 目录”。

C）单击“服务器”，然后单击“连接”。

D）单击“添加连接”。

F）关键域配置描述：

域输入

源服务器连接服务器的名称

使用以下端口连接服务器或源服务器使用的网络端口（或协议）名称

使用优先级选择一个：“一般”（缺省）“低”

目标服务器响应服务器的名称

可选网络地址与所选协议相适应的目标服务器的地址。对于 TCP/IP，应使用完全有效的网络域名称（首选）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

对 TCP/IP 或其他需要特定网络地址的协议，建议填写此域。

复制类型缺省情况下，Domino 的复制方向为“拉入推出”。但根据实际情况，为了平衡服务器之间的负载，充分发挥每个服务器的性能，我们可以设定双方互推或者互拉，本例中我们采用服务器双方互推的方式，即每个服务器上的连接复制类型都是由源服务器向目标服务器推出。

复制文件/目录如果为空，则服务器将DATA目录下的所有存在复本的数据库全部进行复制，否则填写哪个库系统就复制哪个库。

安排在安排中可以设置连接时间、重复间隔、每周复制日期等参数。可根据实际情况设定，本例设置为每日8：00到晚上10：00连接，连接期间每一小时进行同步复制或服务器依据增量自动复制，非连接时间服务器处理其他性能调优动作，如更新数据库索引等。

H）保存文档。

3、建立数据库复本

连接建立成功以后，保证服务器之间可以进行通讯了，下一步就是对要进行同步的数据库建立复本，当建立了复本以后，通过连接设定就能保证异地各个复本之间的数据完全一致。

这里需要说明的是，我们在第一台服务器上建立了一套数据库系统，对于需要同步复制的所有数据库，在其他服务器上只需要产生他们的复本，而不能再在每台服务器上分别创建相同的数据库。在本例中我们在呼市客运公司信息中心安装配置好第一台服务器后，在包头信息中心和东河信息中心的Domino服务器上则通过呼市信息中心服务器建立各自本地所有需要的数据库复本。

如果要在本地Domino服务器上创建源Domino服务器的复本数据库，需要本地服务器的系统管理员具有对源服务器访问和创建复本的权限，因为Domino对权限控制很严格，尤其是多域用户之间的访问，其目的就是为了充分保证系统的安全性。那么怎样才能具有这样的创建复本的权限呢？需要具有两个基本的存取权限就可以在本服务器上创建源服务器的数据库复本，一是源服务器配置中允许本地服务器的系统管理员访问，二是允许本地服务器的系统管理员创建数据库复本，这两个权限由源数据库的系统管理员设置给目标数据库的系统管理员。结合本例，需要在包头信息中心的服务器上建立呼市信息中心的数据库复本，则首先在呼市信息中心的服务器上配置“当前服务器”文档。

A）在 Domino Administrator 中单击“当前服务器”文档。

B）单击“编辑服务器”

C）选择“安全”标签页，填写以下两项：

域输入

访问服务器本例为包头信息中心系统服务器名称及管理员的用户名称

创建数据库复本同样是包头信息中心系统管理员的用户名称

D保存后退出。

接下来就可以在包头信息中心的服务器上创建源数据库的复本了，这步动作比较简单，选择源数据库，从菜单中执行创建复本功能即可，这里不在详细描述。

同样的处理在东河的服务器上如法炮制一遍，则所有数据库复本成功建立完毕。

4、复制测试

完成以上三步，配置就全部完成，接下来就要测试一下配置是否完全成功以及配置是否生效。我们测试主要包括两个内容：一是测试连接是否成功，能否进行复制动作。二是测试设置的复制安排是否按照预定生效。

A）进行第一项测试的办法是在Domino的控制台上，使用Domino的系统命令，进行数据库的推、拉测试，检查复制是否能成功进行，命令格式如下：

拉入复制

语法：Pull servername [databasename]

描述：强制从指定服务器到本地服务器进行单向复制。通过在命令行中包括单个数据库名称，将其从特定服务器单向复制到本地服务器。发起复制的服务器从指定的服务器接受数据，但不能申请将自己的数据复制到其他服务器上。该命令重设在“Domino 目录”中预定的任何复制，而强制一台服务器与发起复制的服务器立即进行复制。如果可能，请输入服务器完整的层次结构名称。

推出复制

语法：Push servername [databasename]

描述：强制进行从本地服务器到指定服务器的单向复制。也可以通过在命令行中包括要复制的单个数据库名称，来将其从本地服务器单向复制到特定服务器。发起复制的服务器将数据发送到指定的服务器，但不申请获得数据。该命令可以重设在“Domino 目录”中预定的任何复制，而强制一台服务器立即与发起复制的服务器进行复制。如果可能的话，请指定服务器完整的层次结构名称。

B）第二项测试通过将连接文档的安排时间设置为两分钟进行一次，同时观察Domino的系统控制台，查看服务器的动作，以确保安排设定生效。正确的结果是从控制台上能看到系统报告复制过程。

按照以上实例说明进行，没有任何问题。

四、结束语

我们同样可以在客户端利用复制技术，例如在本地客户端建立邮件文件数据库的复本，以便与我们在外出或者脱机状态下还可以访问邮件文件。本地复本要求没有在服务器之间进行复制的要求那么高，本地复本的作用体现在通过本地复本，可以在没有通过网络连接服务器时对数据库进行操作。当设置 Notes 为远程工作站时，就可以通过调制解调器呼叫服务器并在本地复本和服务器数据库之间交换更新信息。

第四篇：网络存储技术优缺点与发展趋势

网络存储技术优缺点与发展趋势

随着不断加速的信息需求使得存储容量飞速增长，存储系统网络平台已经成为一个核心平台，同时各种应用对平台的要求也越来越高，不仅在存储容量上，还包括数据访问性能、数据传输性能、数据管理能力、存储扩展能力等等多个方面。可以说，存储网络平台的综合性能的优劣，将直接影响到整个系统的正常运行。因此，发展一种具有成本效益的和可管理的先进存储方式就成为必然。下面就当前的存储技术及发展趋势进行分析和探讨。信息量的飞速发展使得存储容量也飞速增长，发展一种具有成本效益和可管理和先进存储方式就成为必然。本文就几种传统的网络存储框架进行探讨，之后介绍了新的存储技术，并分析了网络存储体系结构的发展趋势。

随着不断加速的信息需求使得存储容量飞速增长，存储系统网络平台已经成为一个核心平台，同时各种应用对平台的要求也越来越高，不仅在存储容量上，还包括数据访问性能、数据传输性能、数据管理能力、存储扩展能力等等多个方面。可以说，存储网络平台的综合性能的优劣，将直接影响到整个系统的正常运行。因此，发展一种具有成本效益的和可管理的先进存储方式就成为必然。下面就当前的存储技术及发展趋势进行分析和探讨。

一、网络存储技术概述

所谓网络存储技术(Network Storage Technologies)，就是以互联网为载体实现数据的传输与存储，数据可以在远程的专用存储设备上，也可以是通过服务器来进行存储。网络存储技术是基于数据存储的一种通用网络术语。实际上，我们可以将存储技术分为三个阶段：①总线存储阶段；②存储网络阶段；③虚拟存储阶段。以存储网络为中心的存储是对数据存储新需求的回答。它采用面向网络的存储体系结构，使数据处理和数据存储分离；网络存储体系结构包括了网络和I/O的精华，将I/O能力扩展到网络上，特别是灵活的网络寻址能力，远距离数据传输能力，I/O高效的原性能；通过网络连接服务器和存储资源，消除了不同存储设备和服务器之间的连接障碍；提高了数据的共享性、可用性和可扩展性、管理性。

二、几种传统的网络存储架构

网络存储架构大致分为三种：直连附加存储、网络附加存储、存储区域网络。这几种网络存储方式特点各异，应用在不同的领域。下面我们来做简单的介绍并分析其中区别。

2.1 直连附加存储(DAS：Direct Attached Storage)

直接网络存储(DAS)是指将存储设备通过SCSI接口或光纤通道直接连接到服务器上的方式。这种连接方式主要应用于单机或两台主机的集群环境中，主要优点是存储容量扩展的实施简单，投入成本少，见效快。DAS主要应用于：

①服务器在地理分布上很分散，SAN或NAS在它们之间进行互连非常困难时；

②存储系统必须被直接连接到应用服务器时；

③包括许多数据库应用和应用服务器在内的应用时。

缺点：

①不能提供跨平台的文件共享功能；

②用户要备份数据和存储数据，都要占用服务器CPU的时间，降低了服务器的管理效能；

③由于各个主机之间的数据独立，数据需要逐一备份，使数据备份工作较为困难；

④随着服务器的增多，数据管理会越来越复杂；增加存储设备，扩展存储容量，需要对服务器进行重新配置，这样做容易中断单位的业务连接性，造成数据丢失。

2.2 网络附加存储(NAS：Network Attached Storage)

网络附加存储(NAS)是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。NAS中服务器与存储之间的通信使用TCP/IP协议，数据处理是“文件级”。NAS可附加大容量的存储内嵌操作系统，专门针对文件系统进行重新设计和优化以提供高效率的文件服务，降低了存储设备的成本，数据传输速率也很高。

NAS应用于电子出版、CAD、图像、教育、银行、政府、法律环境等那些对数据量有较大需求的应用中。多媒体、Internet下载以及在线数据的增长，特别是那些要求存储器能随着公司文件大小规模而增长的企业、小型公司、大型组织的部门网络，更需要这样一个简单的可扩展的方案。

缺点：

①NAS采用File I/O方式，因此当客户端数目或来自客户端的请求较多时，NAS服务器仍将成为系统的瓶颈；

②进行数据备份时需要占用LAN的带宽，造成资源浪费；

③NAS只能对单个存储(单个NAS内部)设备中的磁盘进行资源整合，目前还无法跨越不同的NAS设备，只能进行单独管理，不适合密集型大规模的数据传输。

2.3 存储区域网络(SAN：Storage Area Network)

SAN(Storage Area Network，存储区域网)，通常SAN由RAID阵列连接光纤通道(Fibre Channel)组成，SAN和服务器以及客户机的数据通信通过SCSI命令而非TCP/IP，数据处理是“块级”。

应用：

①数据共享由于存储设备的中心化，大量的文件服务器可以低成本的存取和共享信息，同时也不会使系统性能有明显下降；

②存储共享两个或多个服务器可以共享一个存储单元，这个存储单元在物理上可以被分成多个部分，而每个部分又连接在特定的服务器上；

③数据备份通过使用SAN，这些操作可以独立于原来的网络，从而能够提高操作的性能；

④灾难恢复传统方法，当灾难发生时，使用磁带实现数据恢复。通过使用SAN，可采用多种手段实现数据的自动备份，而且这种备份是热备份形式，也就是说，一旦数据出错，立即可以获得该数据的镜像内容。

三、新的网络存储技术IP—SAN

网络存储的发展产生了一种新技术IP—SANt。IP—SAN是以IP为基础的SAN存储方案，是IP存储技术应用的第三阶段，是完全的端到端的、基于IP的全球SAN存储。它充分利用了IP网络的技术成熟、性能稳定、传输距离远、安装实施简单、后期维护量少的特点，可为用户提供一个运行稳定、实施简单方便、价格低廉的大容量存储系统，是一种可共同使用SAN与NAS，并遵循各项标准的纯软件解决方案。IP—SAN可让用户同时使用GigabitEtherne SCSI与Fibre Channel，建立以IP为基础的网络存储基本架构，由于IP在局域网和广域网上的应用以及良好的技术支持，在IP网络中也可实现远距离的块级存储，以IP协议替代光纤通道协议，IP协议用于网络中实现用户和服务器连接，随着用于执行1P协议的计算机的速度的提高及G比特的以太网的出现，基于IP协议的存储网络实现方案成为SAN的更佳选择。

四、虚拟存储

所谓虚拟存储，就是把内存与外存有机的结合起来使用，从而得到一个容量很大的“内存”。以存储网络为中心的存储解决不了全部的数据存储问题，如存储资源共享、数据共享、数据融合等。不少先进存储系统的倡导者都提出，存储作为一种资源，应该像我们日常生活中的自来水和电力一样，随时可以方便的存取和使用，这就是存储公用设施模型，也是网络存储的发展目标。实现存储公用设施模型的关键就是在网络存储基础上实现统一虚拟存储系统。目前存储技术还处于存储网络阶段，虚拟存储才刚刚起步。

五、云存储

云存储是在云计算(Cloud computing)概念上延伸和发展出来的一个新的概念。云计算是是分布式处理(Distributed Computing)、并行处理(Parallel Computing)和网格计算(Grid Computing)的发展，是透过网络将庞大的计算处理程序自动分拆成无数个较小的子程序，再交由多部服务器所组成的庞大系统经计算分析之后将处理结果回传给用户。

云存储的概念与云计算类似，它是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。云存储的核心是应用软件与存储设备相结合，通过应用软件来实现存储设备向存储服务的转变。

云存储对使用者来讲，不是指某一个具体的设备，而是指一个由许许多多个存储设备和服务器所构成的集合体。用户使用云存储，并不是使用某一个存储设备，而是使用整个云存储系统带来的一种数据访问服务。所以严格来讲，云存储不是存储，而是一种服务。

六、结束语

数据的重要性越来越得到人们的广泛认同，未来网络的核心将是数据，网络化存储正是数据存储的一个发展方向。目前网络存储技术沿着三个主要的方向发展：NAS、SAN、IP—SAN。而SAN和NAS的融合将更有利于数据的存储和备份，因此，SAN和NAS的融合、统一虚拟存储技术是未来网络存储技术发展的两个趋势。

第五篇：数据库技术与应用课程设计

 数据库技术与应用课程设计

一、课程设计的教学目的

1、使学生掌握数据库的基本概念，结合实际的操作和设计，巩固课堂教学内容；

2、使学生掌握数据库系统的基本概念、原理和技术，将理论与实际相结合，应用现有的数据建模工具和数据库管理系统软件，规范、科学地完成一个小型数据库的设计与实现

3、把理论课与实验课所学内容做一综合，并在此基础上强化学生的实践意识、提高其实际动手能力。

一、课程设计的任务：

使用现行教流行的开发工具和SQL Server进行数据库应用的开发，主要完成：

1、创建所用的数据库，创建所需要的表并设置好整性约束。

2、开发出有相当完善功能并有一定规模的数据库应用系统，系统中要能实现对数据的插入、删除、修改、简单查询、复杂查询、数据的统计等。

三、数据库课程设计内容及要求

1、设计内容：

 选题：按自由组合原则，以1-2人一组，每一组从所给题目中任选一个合作完成，并且一个题目只能由一个组选作。

 系统的开发与实现：对所选课题进行调查研究，完成系统的功能分析、结构设计、数据库的概念要设计和逻辑结构设计、数据库的物理实现、用户界面设计等，最后采用程序开发工具（C#、Java、VC、VB、Delphi、ASP等）完成系统开发。

2、设计要求

（1）采取课内上机和业余上机相结合的方式进行，合理安排设计进度（可按以下建议的进度进行），在规定时间内完成系统的开发和设计报告的编写。

（2）提交比较详细的课程设计报告和设计作品。

A、课程设计报告至少2000字以上（原代码除外），报告所包含的内容及格式见《数据库原理——课程设计指导书》

B、所开的数据库应用系统应具有可运行、功能较完整、界面较美观、操作较方便等特点。

C、每位同学至少完成所选课题设计工作量的50% 

四、设计方法与设计过程

1、设计方法 1）学习研究课程设计指导书，确定设计题目

2）确定开发目标及初步方案；选择、准备及试用开发开发平台。

3）学习与搜集素材，借阅、购置必要的书籍与材料：根据自己承担的任务利用各种途径（图书馆、因特网、书店、同学亲友等）进行针对性的学习并收集相关素材，包括精选、购置必要的书籍。

2、设计步骤：

（1）需求分析：根据设计任务书的要求，查阅资料，对系统进行功能分析和数据分析。

（2）数据库概念结构设计：设计系统的E-R模型，描述实体的属性和实体之间的联系，消除不必要的冗余。

（3）数据库逻辑结构设计：实现E-R图向关系模型的转换，优化数据模型。（4）数据库的物理实现：创建数据库、表、视图等，并设计表的完整性约束。（4）应用程序开发 ：创建新的工程——连接数据库——编写程序代码 

五、SQLSERVER数据库课程设计时间 SQLSERVER数据库课程设计时间为一周，具体安排如下： 

六、课程设计交付成果说明(1)个人报告： 每个学生提交个人课程设计报告(A4打印稿，原代码除外至少2000字以上，不少于20页)。

（2）软件与电子文档：把完成的所有文档（设计文档、设计报告及程序）一并交由指导老师处。

 注：文档目录按照如下统一命名规则建立，“课题名/个人子目录名”，比如“图书管理系统/张三/张三_课程设计报告”。 考核方式与成绩评定标准

 考核方式：考察平时表现，注重设计结果演示和实习报告的书写  评定内容：设计结果和设计报告  教材及主要参考资料

[1]张莉 《SQL SEVER数据库原理及应用 》

[2]萨师煊 王珊著.《数据库系统概论》第三版.高等教育出版社

[3] 施伯乐 丁宝康 汪卫.《数据库系统教程》 高等教育出版社2003年第2版

[4]庄成三等.《数据库系统原理及其应用》.电子工业出版社  设计报告按照以下提纲书写 1)摘要。

2)需求分析。

3)数据库概念结构设计。

4)数据库逻辑结构设计。

5)数据流图及程序结构框图。

6)程序原代码及其说明。

7)总结。

 课题一：学生不及格学分管理系统开发（1人）

（1）基本信息管理：能够向数据库中添加、删除、修改不及格学生的科目、学分及成绩等记录。

（2）数据查询：能够按照查询条件（学期、学生姓名、班级、不及格科目）查询浏览查询结果。

（3）数据计算及统计：计算每个学生不及格科目，累计学分并进行降序排列。 提供数据：学分累计统计表

 课题二：图书出版管理系统开发（1-2人）

(1)所出版图书的信息管理：数据录入、修改和删除功能；

(2)所出版图书的查询与统计：可以按各种分类方式（如图书的出版信息、出售信息等）对出版图书信息进行查询与统计(3)系统维护：如数据的备份、用户的管理等。 课题三：产品库存管理系统开发（１-2人）

1、用户信息管理：至少三类以上的用户，不同的用户对产品的录入、修改和删除具有不同的权利。

2、产品信息管理：录入、修改和删除产品的基本信息，要求：对产品名称是否为空进行检验；部份用户可以修改与删除产品信息；修改时，要求先根据查询列出满足条件的产品信息，然后进行修改。删除时，要先确认再进行删除。

3、仓库信息管理：仓库基本信息的录入、修改和删除。

4、产品库存管理：产生存储表，对每种产品的库存信息进行管理，入库时，库存增加、出库时库存减少。

5、信息查询与统计：对产品的基本信息及库存信息进行单条件与组合条件的查询与统计。

 课题四：职工工资管理系统开发（１－2人）某单位员工分为管理员、财务员、技术员和销售员等。该单位下设经理室、财务科、技术科和销售科4个科室。工资由基本工资、福利补贴和奖励工资构成，失业保险和住房公积金在工资中扣除。每个员工的基本资料有姓名、性别、年龄、单位和职业（如经理、工程师等）。工资按月发放，1）职工的基本信息管理：录入、修改与删除职工信息。2）职工的基本工资管理：录入、修改与删除职工工资信息

3）职工的工资计算：计算每个人的实际发放工资。实际发放的工资金额为工资减去扣除。4）工资的查询：按职工所在的部门、职工名及职工编号等条件查询每个职工的工资 5）工资的统计：按科室、职业分类统计人数和工资金额。 课题五：**市地下水常规监测 信息管理系统开发（1-2人）

（1）基本信息管理：能够向数据库中添加、删除、修改地下水常规监测数据。（2）数据查询：能够按照条件（监测点、监测因子、监测时间）进行查询；能够选择监测因子查询所有该因子超标的监测点，指定一个监测点判断该监测点所有常规监测因子的状态（是否超标）

（3）数据统计：能够按照时间段等条件对监测数据进行统计。 课题六：商品销售管理系统开发（１－2人）(1)用户管理：用户的基本信息及权限的录入、修改和删除管理

(2)商品信息管理：商品基本信息录入、修改和删除，注意各类完整性约束的设计与检验。

(3)进货信息管理：进货信息的录入、修改和删除。

(4)销售信息管理：商品销售信息的录入、修改和删除管理。

（5）各类信息的查询：按简单条件、组合条件及模糊条件对各类信息进行查询。（6）各类信息的统计：按简单条件、组合条件及模糊条件对各类信息进行统计。 课题七：电子相册管理系统开发（1人）(1)照片基本信息的管理：照片的上传、显示与删除。（2）照片的浏览与查询：按不同条件实现对照片的浏览与查询(3)用户的管理：不同的用户对照片的上传与查询等权限不同。 课题八：人事管理系统开发（１－2人）（1）员工信息管理：员工的姓名、性别、工作岗位、所在部门、学历、婚姻状况、专业、毕业时间、学校、外语情况、职称等基本信息的录入、修改与删除。

（2）企业工作岗位信息和部门信息管理：企业中的工作岗位信息和部门信息的录入、修改与删除（如转出、辞职、辞退、退休）。

（3）职称信息的管理：所有职称的种类、专业等信息的录入、修改与删除。（4）职工的档案管理：对职工档案信息的录入、修改与删除。（4）信息的查询：对各类信息按不同的条件进行查询。（5）信息的统计：对各类信息按不同的条件进行统计  课题九：教职工签到管理系统开发（1人）

(1)教职工基本信息管理：教职工基本信息的增加、修改与删除；

(2)教职工签到管理：教职工输入编号后，签到，系统自动记录其签到的时间，并注明是否迟到。

（3）教职工签到情况的查询与统计：按不同的条件对工签到情况进行查询与统计

 课题十：通讯簿信息管理系统开发（1人）

(1)地址信息的管理：对新地址的姓名、性别、家庭住址、手机、住址电话、办公电话、电子信箱、个人简介、照片等基本信息的录入，对原有地址信息的修改与删除，在修改与删除时，应先查询出相关信息，再进行修改与删除；

(2)地址信息的查询与统计：可以按姓名等不同的条件对地址信息进行查询与统计；

（3）用户管理：录入、修改与删除用户信息以及对用户授权的管理。 课题十一：网上图书销网站设计与开发（１－2人）

(1)图书信息管理：可以在管理后台录入、修改与删除图书的基本信息； (2)图书内容简介管理：录入、修改与删除图书的内容简介；

（3）图书内容简介的查询：可以在前台按关键字查询图书的内容简介 （4）用户注册管理：前台提供用户注册界面，后台可以对注册的用户进行查询与删除，但不能修改用户的注册信息。

(5)购物车管理：前台用户可以将感兴趣的图书放入购物车，也可以删除与查询购物车内的图书；

(6)各类信息的查询：学生自己设计按不同条件对各类信息进行查询与统计。

（7）各类信息需要用数据库存储。 课题十二：客房管理信息系统开发（１－2人）

（1）用户管理：录入、修改与删除用户信息以及对用户授权的管理。(2)客房基本信息的管理：添加、修改、删除客房的基本信息；

（3）客户住宿登记信息的管理：添加、修改、删除客户住宿登记的基本信息；(4)客户预定管理：对预定客房的基本信息进行管理（5）客户退房处理：对退房信息进行管理；

(6)各类信息的查询与统计：按不同的条件对各类信息进行查询与统计。 课题十三：高校科研管理系统开发（１－2人）(1)科研人员管理：科研人员基本信息的录入、修改与删除。(2)科研项目管理；科研项目基本信息的录入、修改与删除。

(3)获奖情况管理：对获奖的科研科研成果、科研项目及相关的科研人员的信息进行管理；

(4)科研成果管理：对科研论文、学术著作等科研成果的基本信息进行录入、修改与删除管理。

(5)学术期刊管理：对各种学术期刊的基本信息进行录入、修改与删除管理。(6)各类信息的查询与统计：按不同的条件对各类信息进行查询与统计。 课题十四：旅游管理系统开发（１－2人）

(1)景点管理：对各个景点基本信息的录入、修改与删除。(2)导游管理：对每个导游的姓名、专业、所在景点等基本信息的录入、修改与删除。

(3)游客管理：对各个游客基本信息的录入、修改与删除。(4)用户管理：录入、修改与删除用户信息以及对用户授权的管理。(5)各类信息的查询：按不同的条件对各类信息进行查询。（6）各类信息的统计：按不同的条件对各类信息进行统计。 课题十五：民航订票管理系统开发（１－2人）（1）航班信息管理：每个航班基本信息的录入、修改与删除。

（2）航班坐位信息管理：每个航班坐位信息的录入、修改与删除。

（3）机票预定管理：输入旅客基本信息，系统为旅客安排航班，打印取票通知和帐单；（4）退订机票管理：对退订机票信息进行判断、录入、修改与删除。

（5）查询信息：能够查询每个航班的基本信息、预定情况、旅客的基本信息等。（6）统计信息：计算每个航班的满座率，统计旅客的乘坐次数数、乘坐总金额等。

 课题十六：图书借阅管理系统开发（1-2人）（1）读者信息管理：对借阅者的借书证号、姓名、性别、出生日期、身份证号、联系电话、办证日期、借阅范围（书库）、所在单位、职业等基本信息的录入、修改与删除。

（2）图书基本信息管理：对每种图书的书名、书号（ISBN）、作者（译者）、出版社、定价和内容简介等基本信息的录入、修改与删除。

（3)借阅管理：借阅者的个人资料和所借图书的书名、书号数据等基本信息的录入、修改与删除。凭借书证借书，每次最多能借8本书。借书期限最长为60天。输入借书证号后，能根据借书证号判断该读者可以借书的书库，借书是否超出最大允许借书册数，书库中是否还有该书可借。

（4）还书管理：对过期未还图书进行罚款，对归还的图书能从借书登记表中取消，对丢失的图书进行登记。

（5)对所有购进图书的分类查询和分类统计，能够按书名、作者等分类查询现有图书的数量。

（6)能根据书号、书名、作者、出版单位、内容提要关键字、分类号、索书号、每册图书馆藏注册号等进行查询。

 课题课题十七：类QQ留言系统开发（1人）

1、QQ号基本信息的管理：能够向数据库中添加、删除QQ号记录，能够修改记录中的字段值。

2、能够按照条件（好友呢称、QQ号）留言或浏览。

3、能够按好友呢称、QQ号等条件对QQ号进行查询 与统计  课题十八：中小学智能排课系统开发（１-2人）

 能根据教师要求(如某天不得排课)、课程约束(如体育不能排在上午第一节课)、班级约束(如某班星期五下午最后一节课不排课)、校级约束(如全校所有班级星期一下午第一节课都为班会)等信息自动为班级和教师生成课程表，要求主课尽量排在上午和下午一、二节课，副课尽量排在上午和下午的最后一节课，如体育课排在上午第一节课是不太合适的。对于软件不能安排的少数课程，教务工作者能够在自动排出的课程表上进行手工调课。 具体要求：

(1)系统可以进行两节连课处理，如作文课可以连课上；(2)排出的课程表中不允许有教师冲突的情况，比如，一个教师同时给两个班级上课是不允许的；

(3)要求课程表中的课程要有所变化，比如一个班级的所有数学课总是排在上午第一节课是不好的课程表。

(4)每周上课天数为5天，每天上课节数可以是7节或是8节；(5)每个年级所开课程是一样的；(6)一个教师可以教授多门课程；

(7)系统可以为每个班级和每位教师打印课程表；(8)在课表生效后，教师可以要求调课；

(9)教师数量是动态的，所开课程的数量也是动态的。

 课题十九：学生学籍管理信息系统开发（1人）

(1)学生档案的管理，即录入、修改、查询、输出学生档案信息，这些信息包括学生基本情况、学生简历情况、学生奖励情况、学生处分情况、学生家庭信息、学生体检情况。

(2)学生学籍管理，能够录入、修改、查询、输出学生学籍信息，这些信息包括学生奖贷学金情况、学生注册、学生异动情况、学生军训情况、学生毕业情况。

(3)学生成绩管理，能够录入修改、查询、输出学生入校成绩，各学期、各门课程的成绩信息，并支持按年级、班级等条件的统计、查询、报表输出。

 课题二十：网上订货发货系统开发（1-2人）

1）合同管理：合同的合同编号，客户的名称，地址，签定时间，帐号，总金额及产品清单等基本信息的录入、修改、删除和查询。一个合同可签订多种产品，合同签订必须为现有的库存产品，但产品库存量不够时，可允许先签订合同；

2）客户管理：客户网上注册、登录、修改个人资料等。

3）发货管理：根据合同签订的情况发货，不得超出合同签订的产品品种，数量及库存量；每个合同的发货可分次完成，并保留发货的历史记录。

4）库存管理：可完成产品入库、出库（合同发货）信息的录入、修改与删除。5）查询信息：各类基本信息的分类查询 6）统计信息：各类基本信息的分类统计。

 课题二十一：超市管理系统开发（１－2人）1）超市员工信息管理：超市员工的姓名、家庭住址、学历、婚姻状况信息等基本的录入、修改和删除； 2）超市货物信息管理：超市货物的的名称，编号，价格，生产厂家，库存量等基本信息的录入、修改和删除；

3）销售情况管理：超市货物销售信息的录入、修改和删除； 4）用户管理：用户基本信息的的录入、修改和删除； 5）查询信息：各类基本信息的分类查询

6）统计信息：各类基本信息的分类统计。

 课题二十二：教师网上成绩录入系统开发(１－2人)

1）教师信息的管理：教师的基本信息、所教课程、授课时间、教师密码等信息的录入、修改和删除；

2）学生信息的管理：学生基本信息的录入、修改和删除；

3）课程信息的管理：课程基本信息的录入、修改和删除；

4）选课信息的管理：生所选课程基本信息的录入、修改和删除；

5）成绩管理：成绩的录入和修改

6）信息的查询与统计：能按不同条件对各类信息进行查询，能按多个条件对成绩信息、选课信息等进行统计；

 课题二十三：网上考试系统开发(１－2人)1）考生信息管理：考生基本信息的录入、修改和删除。

2）试题库管理：试题库（试题及答案）基本信息的录入、修改和删除。

3）试卷生成：根据规则从试题库抽出试题形成试卷

4）试卷提交：学生做完题目以后，能够对自己的答案进行提交，提交以后，信息不能再修改；

5）试卷评分：对试卷进行自动评分，并记录试卷分数。学生将所有题目全部提交以后，能够查看标准答案与评分标准。

6）查询与统计信息：能对试卷的难易度、成绩等各类基本信息进行分类查询与统计。

 课题二十四：网上选课系统开发(１－2人)（1）学生信息管理：学生基本信息的录入、修改和删除。

（2）可选课程信息管理：课程的课程号、课程名、可选专业及开课学期学分等基本信息的录入、修改和删除。

（3）学生选课：学生登录后，根据学生的专业及开课学期生成可选的课程表，让学生完成选课，并自动生成选课信息表。（4）选课信息表的查询与修改：所选课的课程号、课程名、学号、选课时间、所修学期等基本信息在一定的时间段内可删除。（5）查询信息：各类基本信息的分类查询

（6）统计信息：各类基本信息的分类统计。

 课题二十五：学生党员管理系统开发（1人）

（1）学生党员信息的管理；能够增加、修改和删除学生党员的基本信息；（2）查询党员的基本信息：能够按照查询条件（班级、年级、专业、入党时间）查询党员的数量；也能够实现多个条件的组合查询

（3）统计党员的基本信息：统计按照查询条件（班级、年级、专业、入党时间）查询党员的数量；

 课题二十六：学生综合评定积分管理系统开发（1人）

（1）学生综合成绩的管理：能够按照学年记录增加、修改和删除学生各项分值（德育素质分各项、体育素质分各项、智育素质分各项），并能够进行自动运算求出学生该学年的综合积分。

（2）成绩查询：能够按照查询条件（学年、专业、班级）对各项信息进行查询。（3）能够按照设定条件进行综合积分排序（学年、专业、班级）和对成绩的统计

注：提供数据：系各班综合评定表；学生学籍信息统计表；  课题二十七：毕业论文管理系统开发（1人）

（1）毕业论文基本信息管理：能够向数据库中添加、修改、删除论文记录。（2）数据查询：能够按照查询条件（指导教师、选题性质、题目类型、成绩、专业班级、年级、学生姓名、难度、指导教师职称）进行论文的查询并能浏览查询结果。

（3）数据统计：能够按照设定条件进行相关数据的统计（成绩百分率（优秀、良好、中等、及格、不及格），可以以专业来统计也可以以班级来统计）。

 课题二十八：学生宿舍查询系统开发（1-2人）

（1）学生宿舍信息管理：能够向数据库中添加、删除和修改宿舍记录。（2）宿舍信息查询：能够按照查询条件（学生姓名、学号、宿舍、电话、班级）进行查询并能浏览查询结果。

（3）宿舍信息统计：能够按照条件（学生人数、专业、是否住满或是否为空等）进行统计并能浏览统计结果。

 注：提供的数据有学生宿舍信息汇总表、学生学籍信息统计表  课题二十九：考试监考管理系统开发（1人）（1）基本信息管理：能够向数据库中添加、删除、修改监考安排相关的信息。（2）数据查询：能够按照条件（教师姓名、监考校区）进行查询；

（3）数据统计：按照教师姓名统计教师每一学期监考的次数和监考费，往返新老两个校区的监考费为13元/次，否则为10元/次；  课题三十：气象信息管理系统开发（1人）

（1）基本信息管理：能够向数据库中添加、删除、修改气象记录。

（2）数据查询：能够按照查询条件（月份、地名、气温类别）进行查询并能浏览查询结果

（3数据统计：能够按照统计条件（月份、地名、气温类别）进行统计并能浏览统计结果。