第一篇：從Google Spanner漫談分布式存儲(chǔ)與數(shù)據(jù)庫技術(shù)

從Google Spanner漫談分布式存儲(chǔ)與數(shù)據(jù)庫技術(shù)

文/曹偉

Spanner 的設(shè)計(jì)反映了 Google 多年來在分布式存儲(chǔ)系統(tǒng)領(lǐng)域上經(jīng)驗(yàn)的積累和沉淀，它采用了 Megastore 的數(shù)據(jù)模型，Chubby 的數(shù)據(jù)復(fù)制和一致性算法，而在數(shù)據(jù)的可擴(kuò)展性上使用了 BigTable 中的技術(shù)。新穎之處在于，它使用高精度和可觀測誤差的本地時(shí)鐘來判斷分布式系統(tǒng)中事件的先后順序。Spanner 代表了分布式數(shù)據(jù)庫領(lǐng)域的新趨勢——NewSQL。

Spanner 是 Google 最近公開的新一代分布式數(shù)據(jù)庫，它既具有 NoSQL 系統(tǒng)的可擴(kuò)展性，也具有關(guān)系數(shù)據(jù)庫的功能。例如，它支持類似 SQL 的查詢語言、支持表連接、支持事務(wù)（包括分布式事務(wù)）。Spanner 可以將一份數(shù)據(jù)復(fù)制到全球范圍的多個(gè)數(shù)據(jù)中心，并保證數(shù)據(jù)的一致性。一套 Spanner 集群可以擴(kuò)展到上百個(gè)數(shù)據(jù)中心、百萬臺(tái)服務(wù)器和上T條數(shù)據(jù)庫記錄的規(guī)模。目前，Google 廣告業(yè)務(wù)的后臺(tái)（F1）已從 MySQL 分庫分表方案遷移到了 Spanner 上。

數(shù)據(jù)模型

傳統(tǒng)的 RDBMS（例如 MySQL）采用關(guān)系模型，有豐富的功能，支持 SQL 查詢語句。而 NoSQL 數(shù)據(jù)庫多是在 key-value 存儲(chǔ)之上增加有限的功能，如列索引、范圍查詢等，但具有良好的可擴(kuò)展性。Spanner 繼承了 Megastore 的設(shè)計(jì)，數(shù)據(jù)模型介于 RDBMS 和 NoSQL 之間，提供樹形、層次化的數(shù)據(jù)庫 schema，一方面支持類 SQL 的查詢語言，提供表連接等關(guān)系數(shù)據(jù)庫的特性，功能上類似于 RDBMS；另一方面整個(gè)數(shù)據(jù)庫中的所有記錄都存儲(chǔ)在同一個(gè) key-value 大表中，實(shí)現(xiàn)上類似于 BigTable，具有 NoSQL 系統(tǒng)的可擴(kuò)展性。

在 Spanner 中，應(yīng)用可以在一個(gè)數(shù)據(jù)庫里創(chuàng)建多個(gè)表，同時(shí)需要指定這些表之間的層次關(guān)系。例如，圖 1 中創(chuàng)建的兩個(gè)表——用戶表（Users）和相冊(cè)表（Albums），并且指定用戶表是相冊(cè)表的父節(jié)點(diǎn)。父節(jié)點(diǎn)和子節(jié)點(diǎn)間存在著一對(duì)多的關(guān)系，用戶表中的一條記錄（一個(gè)用戶）對(duì)應(yīng)著相冊(cè)表中的多條記錄（多個(gè)相冊(cè)）。此外，要求子節(jié)點(diǎn)的主鍵必須以父節(jié)點(diǎn)的主鍵作為前綴。例如，用戶表的主鍵（用戶 ID）就是相冊(cè)表主鍵（用戶 ID+ 相冊(cè) ID）的前綴。

圖 1 schema 示例，表之間的層次關(guān)系，記錄排序后交錯(cuò)的存儲(chǔ)

顯然所有表的主鍵都將根節(jié)點(diǎn)的主鍵作為前綴，Spanner 將根節(jié)點(diǎn)表中的一條記錄，和以其主鍵作為前綴的其他表中的所有記錄的集合稱作一個(gè) Directory。例如，一個(gè)用戶的記錄及該用戶所有相冊(cè)的記錄組成了一個(gè) Directory。Directory 是 Spanner 中對(duì)數(shù)據(jù)進(jìn)行分區(qū)、復(fù)制和遷移的基本單位，應(yīng)用可以指定一個(gè) Directory 有多少個(gè)副本，分別存放在哪些機(jī)房中，例如把用戶的 Directory 存放在這個(gè)用戶所在地區(qū)附近的幾個(gè)機(jī)房中。

這樣的數(shù)據(jù)模型具有以下好處。

? 一個(gè) Directory 中所有記錄的主鍵都具有相同前綴。在存儲(chǔ)到底層 key-value 大表時(shí)，會(huì)被分配到相鄰的位置。如果數(shù)據(jù)量不是非常大，會(huì)位于同一個(gè)節(jié)點(diǎn)上，這不僅提高了數(shù)據(jù)訪問的局部性，也保證了在一個(gè) Directory 中發(fā)生的事務(wù)都是單機(jī)的。

? Directory 還實(shí)現(xiàn)了從細(xì)粒度上對(duì)數(shù)據(jù)進(jìn)行分區(qū)。整個(gè)數(shù)據(jù)庫被劃分為百萬個(gè)甚至更多個(gè) Directory，每個(gè) Directory 可以定義自己的復(fù)制策略。這種 Directory-based 的數(shù)據(jù)分區(qū)方式比 MySQL 分庫分表時(shí) Table-based 的粒度要細(xì)，而比 Yahoo!的 PNUTS 系統(tǒng)中 Row-based 的粒度要粗。

? Directory 提供了高效的表連接運(yùn)算方式。在一個(gè) Directory 中，多張表上的記錄按主鍵排序，交錯(cuò)（interleaved）地存儲(chǔ)在一起，因此進(jìn)行表連接運(yùn)算時(shí)無需排序即可在表間直接進(jìn)行歸并。

復(fù)制和一致性

Spanner 使用 Paxos 協(xié)議在多個(gè)副本間同步 redo 日志，從而保證數(shù)據(jù)在多個(gè)副本上是一致的。Google 的工程師鐘情于 Paxos 協(xié)議，Chubby、Megastore 和 Spanner 等一系列產(chǎn)品都是在 Paxos 協(xié)議的基礎(chǔ)上實(shí)現(xiàn)一致性的。

Paxos 的基本協(xié)議很簡單。協(xié)議中有三個(gè)角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分別是讀者和寫者，Acceptor 相當(dāng)于存儲(chǔ)節(jié)點(diǎn)。整個(gè)協(xié)議描述的是，當(dāng)系統(tǒng)中有多個(gè) Proposer 和 Acceptor 時(shí)，每次 Proposer 寫一個(gè)變量就會(huì)啟動(dòng)一輪決議過程（Paxos instance），如圖 2 所示。決議過程可以保證即使多個(gè) Proposer 同時(shí)寫，結(jié)果也不會(huì)在 Acceptor 節(jié)點(diǎn)上不一致。確切地說，一旦某個(gè) Proposer 提交的值被大多數(shù) Acceptor 接受，那么這個(gè)值就被選中，在整輪決議的過程中該變量就不會(huì)再被修改為其他值。如果另一個(gè) Proposer 要寫入其他值，必須啟動(dòng)下一輪決議過程，而決議過程之間是串行（serializable）的。

圖 2 Paxos 協(xié)議正常執(zhí)行流程

一輪決議過程分為兩個(gè)階段，即 prepare 階段和 accept 階段。

? 第一階段A：Proposer 向所有 Acceptor 節(jié)點(diǎn)廣播 prepare 消息，消息中只包含一個(gè)序號(hào)——N。Proposer 需要保證這個(gè)序號(hào)在這輪決議過程中是全局唯一的（這很容易做到，假如系統(tǒng)中有兩個(gè) Proposer，那么一個(gè) Proposer 使用1，3，5，7，9，??，另一個(gè) Proposer 則使用0，2，4，6，8，??）。

?

第一階段B：Acceptor 接收到 prepare 消息后，如果N是到目前為止見過的最大序號(hào)，就返回一個(gè) promise 消息，承諾不會(huì)接受序號(hào)小于N的請(qǐng)求；如果已接受過其他 Proposer 提交的值，則會(huì)將這個(gè)值連同提交這個(gè)值的請(qǐng)求的序號(hào)一同返回。? 第二階段A：當(dāng) Proposer 從大多數(shù) Acceptor 節(jié)點(diǎn)收到了 promise 消息后，就可以選擇接下來要向 Acceptor 提交的值了。一般情況下，當(dāng)然選原本打算寫入的值，但如果從收到的 promise 消息中發(fā)現(xiàn)已經(jīng)有其他值被 Acceptor 接受了，那么為了避免造成數(shù)據(jù)不一致的風(fēng)險(xiǎn)，這時(shí) Proposer 就必須“大義滅親”，放棄自己打算寫入的值，從其他 Proposer 提交的序號(hào)中選擇一個(gè)最大的值。接下來 Proposer 向所有的 Acceptor 節(jié)點(diǎn)發(fā)送 accept 包，其中包含在第一階段中挑選的序號(hào)N和剛才選擇的值V。

?

第二階段B：Acceptor 收到 accept 包之后，如果N的大小不違反對(duì)其他

Proposer 的承諾，就接受這個(gè)請(qǐng)求，記錄下值V和序號(hào)N，返回一個(gè) ack 消息。反之，則返回一個(gè) reject 消息。

如果 Proposer 從大多數(shù) Acceptor 節(jié)點(diǎn)收到了 ack 消息，說明寫操作成功。而如果在寫操作過程中失敗，Proposer 可以增大序號(hào)，重新執(zhí)行第一階段。

基本的 Paxos 協(xié)議可以保證值一旦被選出后就一定不會(huì)改變，但不能保證一定會(huì)選出值來。換句話說，這個(gè)投票算法不一定收斂。有兩個(gè)方法可以加速收斂的過程：一個(gè)是在出現(xiàn)沖突后通過隨機(jī)延遲把機(jī)會(huì)讓給其他 Proposer，另一個(gè)是盡量讓系統(tǒng)中只有一個(gè) Proposer 去提交。在 Chubby 和 Spanner 系統(tǒng)中這兩種方法都用上了，先用隨機(jī)延遲的方法通過一輪 Paxos 協(xié)議，在多個(gè) Proposer 中選舉出一個(gè) leader 節(jié)點(diǎn)。接下來所有的寫操作都通過這個(gè) leader 節(jié)點(diǎn)，而 leader 節(jié)點(diǎn)一般還是比較“長壽”的，在廣域網(wǎng)環(huán)境下平均“任期”可以達(dá)到一天以上。而 Megastore 系統(tǒng)中沒有很好地解決這個(gè)問題，所有的 Proposer 都可以發(fā)起寫操作，這是 Megastore 寫入性能不高的原因之一。

基本的 Paxos 協(xié)議還存在性能上的問題，一輪決議過程通常需要進(jìn)行兩個(gè)回合通信，而一次跨機(jī)房通信的代價(jià)為幾十到一百毫秒不等，因此兩個(gè)回合的通信就有點(diǎn)開銷過高了。不過幸運(yùn)的是，絕大多數(shù)情況下，Paxos 協(xié)議可以優(yōu)化到僅需一個(gè)回合通信。決議過程的第一階段是不需要指定值的，因此可以把 prepare/promise 的過程捎帶在上一輪決議中完成，或者更進(jìn)一步，在執(zhí)行一輪決議的過程中隱式地涵蓋接下來一輪或者幾輪決議的第一階段。這樣，當(dāng)一輪決議完成之后，其他決議的第一階段也已經(jīng)完成了。如此看來，只要 leader 不發(fā)生更替，Paxos 協(xié)議就可以在一個(gè)回合內(nèi)完成。為了支持實(shí)際的業(yè)務(wù)，Paxos 協(xié)議還需要支持并發(fā)，多輪決議過程可以并發(fā)執(zhí)行，而代價(jià)是故障恢復(fù)會(huì)更加復(fù)雜。

因?yàn)?leader 節(jié)點(diǎn)上有最新的數(shù)據(jù)，而在其他節(jié)點(diǎn)上為了獲取最新的數(shù)據(jù)來執(zhí)行 Paxos 協(xié)議的第一階段，需要一個(gè)回合的通信代價(jià)。因此，Chubby 中的讀寫操作，以及 Spanner 中的讀寫事務(wù)都僅在 leader 節(jié)點(diǎn)上執(zhí)行。而為了提高讀操作的性能，減輕 leader 節(jié)點(diǎn)的負(fù)載，Spanner 還提供了只讀事務(wù)和本地讀。只讀事務(wù)只在 leader 節(jié)點(diǎn)上獲取時(shí)間戳信息，再用這個(gè)時(shí)間戳在其他節(jié)點(diǎn)上執(zhí)行讀操作；而本地讀則讀取節(jié)點(diǎn)上最新版本的數(shù)據(jù)。

與 Chubby、Spanner 這種讀寫以 leader 節(jié)點(diǎn)為中心的設(shè)計(jì)相比，Megastore 體現(xiàn)了一定的“去中心化”設(shè)計(jì)。每個(gè)客戶端都可以發(fā)起 Paxos 寫操作，而讀操作則盡可能在本地執(zhí)行。如果客戶端發(fā)現(xiàn)本地?cái)?shù)據(jù)不是最新的，會(huì)啟動(dòng) catchup 流程更新數(shù)據(jù)，再執(zhí)行本地讀操作返回給客戶端。

最后，對(duì)比下其他系統(tǒng)中 replication 的實(shí)現(xiàn)。在 BigTable 系統(tǒng)中每個(gè) tablet 服務(wù)器是沒有副本的，完全依賴底層 GFS 把數(shù)據(jù)存到多臺(tái)機(jī)器上。數(shù)據(jù)的讀寫都通過單個(gè) tablet 服務(wù)器，在 tablet 服務(wù)器出現(xiàn)故障的時(shí)需要 master 服務(wù)器將 tablet 指派到其他 tablet 服務(wù)器上才能恢復(fù)可用。Dynamo 系統(tǒng)則貫徹了“去中心化”的思想，將數(shù)據(jù)保存在多個(gè)副本上，每個(gè)副本都可以寫入（update everywhere）。而不同副本同時(shí)寫入的數(shù)據(jù)可能會(huì)存在不一致，則需要使用版本向量（version vector）記錄不同的值和時(shí)間戳，由應(yīng)用去解釋或合并不一致的數(shù)據(jù)。盡管 Dynamo 系統(tǒng)還提供了 NWR 的方式來支持有一致性保證的讀寫操作，但總的來說 Dynamo 為了高可用性犧牲了一致性。ZooKeeper、MongoDB 與 Chubby、Spanner 類似，通過 leader 選舉協(xié)議從多個(gè)副本中選擇一個(gè) leader，所有寫操作都在經(jīng)過 leader 節(jié)點(diǎn)序列化后，同步到其他副本上。ZooKeeper 則是在寫入大多數(shù)節(jié)點(diǎn)后返回，而 MongoDB 主要采用異步的主從復(fù)制方式。

分布式事務(wù)

Spanner 系統(tǒng)中的分布式事務(wù)通過兩階段提交協(xié)議（2PC）實(shí)現(xiàn)。2PC 是一類特殊的一致性協(xié)議，假設(shè)一個(gè)分布式事務(wù)涉及了多個(gè)數(shù)據(jù)節(jié)點(diǎn)，2PC 可以保證在這些節(jié)點(diǎn)上的操作要么全部提交，要么全部失敗，從而保證了整個(gè)分布式事務(wù)的原子性（ACID 里的A）。協(xié)議中包含兩個(gè)角色：協(xié)調(diào)者（coordinator）和參與者（participant/cohort）。協(xié)調(diào)者是分布式事務(wù)的發(fā)起者，而參與者是參與了事務(wù)的數(shù)據(jù)節(jié)點(diǎn)。在協(xié)議最基本的形式中，系統(tǒng)中有一個(gè)協(xié)調(diào)者和多個(gè)參與者。

顧名思義，2PC 也包含兩個(gè)階段，即投票階段和提交階段（如圖 3 所示）。

圖 3 兩階段提交協(xié)議 ? 在第一階段，協(xié)調(diào)者向所有的參與者發(fā)送投票請(qǐng)求，每個(gè)參與者決定是否要提交事務(wù)。如果打算提交的話需要寫好 redo、undo 等日志，并向協(xié)調(diào)者回復(fù) yes 或 no。

? 在第二階段，協(xié)調(diào)者收到所有參與者的回復(fù)，如果都是 yes，那么決定提交這個(gè)事務(wù)，寫好日志后向所有參與者廣播提交事務(wù)的通知。反之，則中止事務(wù)并且通知所有參與者。參與者收到提交/中止事務(wù)的命令后，執(zhí)行相應(yīng)操作，如果提交的話還需要寫日志。

協(xié)議過程包括兩回合的通信，在協(xié)調(diào)者和參與者端需要多次寫日志，而且整個(gè)過程中所有參與者都占有讀鎖、寫鎖，可見 2PC 開銷不菲。

2PC 最令人詬病之處還不在于性能，而是在有些故障條件下，會(huì)造成所有參與者占有讀鎖、寫鎖堵塞在第二階段，需要人工干預(yù)才能繼續(xù)，存在嚴(yán)重的可用性隱患。假設(shè)故障發(fā)生在第二階段，協(xié)調(diào)者在做出決定后，通知完一個(gè)參與者就宕機(jī)了，更糟糕的是被通知的這位參與者在執(zhí)行完“上級(jí)指示”之后也宕機(jī)了，這時(shí)對(duì)其他參與者來說，就必須堵塞在那里等待結(jié)果。

Spanner 利用基于 Paxos 協(xié)議的復(fù)制技術(shù)，改善了 2PC 的可用性問題。2PC 協(xié)議過程中的協(xié)調(diào)者和參與者生成的日志都會(huì)利用 Paxos 協(xié)議復(fù)制到所有副本中，這樣無論是協(xié)調(diào)者或參與者宕機(jī)，都會(huì)有其他副本代替它們，完成 2PC 過程而不至于堵塞。在 Paxos 協(xié)議上實(shí)現(xiàn) 2PC 這一思路很巧妙，Paxos 協(xié)議保證了大多數(shù)節(jié)點(diǎn)在線情況下的可用性，而 2PC 保證了分布式協(xié)議的一致性。

事件的順序

傳統(tǒng)上，在設(shè)計(jì)一個(gè)分布式系統(tǒng)時(shí)，都會(huì)假設(shè)每個(gè)節(jié)點(diǎn)的運(yùn)行速度和時(shí)鐘的快慢各不相同的情況，并且在節(jié)點(diǎn)之間進(jìn)行同步的唯一方法就是異步通信。系統(tǒng)中的每個(gè)節(jié)點(diǎn)都扮演著觀察者的角色，并從其他節(jié)點(diǎn)接收事件發(fā)生的通知。判斷系統(tǒng)中兩個(gè)事件的先后順序主要依靠分析它們的因果關(guān)系，包括 Lamport 時(shí)鐘、向量時(shí)鐘等算法，而這一切都存在通信開銷。

因此，Spanner 提出了一種新的思路，在不進(jìn)行通信的情況下，利用高精度和可觀測誤差的本地時(shí)鐘（TrueTime API）給事件打上時(shí)間戳，并且以此比較分布式系統(tǒng)中兩個(gè)事件的先后順序。利用這個(gè)方法，Spanner 實(shí)現(xiàn)了事務(wù)之間的外部一致性（external consistency）（如圖 4 所示），也就是說，一個(gè)事務(wù)結(jié)束后另一個(gè)事務(wù)才開始，Spanner 可以保證第一個(gè)事務(wù)的時(shí)間戳比第二個(gè)事務(wù)的時(shí)間戳要早，從而兩個(gè)事務(wù)被串行化后也一定能保持正確的順序。

圖 4 事務(wù)外部一致性的實(shí)現(xiàn)

TrueTime API 是一個(gè)提供本地時(shí)間的接口，但與 Linux 上 gettimeofday 接口不一樣的是，它除了可以返回一個(gè)時(shí)間戳t，還會(huì)給出一個(gè)誤差ε。例如，返回的時(shí)間戳是 1 分 30 秒 350 毫秒，而誤差是 5 毫秒，那么真實(shí)的時(shí)間在 1 分 30 秒 345 毫秒到 355 毫秒之間。真實(shí)的系統(tǒng)中ε平均下來是 4 毫秒。

利用 TrueTime API，Spanner 可以保證給出的事務(wù)標(biāo)記的時(shí)間戳介于事務(wù)開始的真實(shí)時(shí)間和事務(wù)結(jié)束的真實(shí)時(shí)間之間。假如事務(wù)開始時(shí) TrueTime API 返回的時(shí)間是{t1, ε1}，此時(shí)真實(shí)時(shí)間在 t1-ε1到 t1+ε1之間；事務(wù)結(jié)束時(shí) TrueTime API 返回的時(shí)間是{t2, ε2}，此時(shí)真實(shí)時(shí)間在 t2-ε2到 t2+ε2之間。Spanner 會(huì)在 t1+ε1和 t2-ε2之間選擇一個(gè)時(shí)間點(diǎn)作為事務(wù)的時(shí)間戳，但這需要保證 t1+ε1小于 t2-ε2，為了保證這點(diǎn)，Spanner 會(huì)在事務(wù)執(zhí)行過程中等待，直到 t2-ε2大于 t1+ε1時(shí)才提交事務(wù)。由此可以推導(dǎo)出，Spanner 中一個(gè)事務(wù)至少需要2ε的時(shí)間（平均 8 毫秒）才能完成。

由此可見，這種新方法雖然避免了通信開銷，卻引入了等待時(shí)間。為了保證外部一致性，寫延遲是不可避免的，這也印證了 CAP 定理所揭示的法則，一致性與延遲之間是需要權(quán)衡的。

最后介紹一下 TrueTime API 的實(shí)現(xiàn)。TrueTime API 的實(shí)現(xiàn)大體上類似于網(wǎng)絡(luò)時(shí)間協(xié)議（NTP），但只有兩個(gè)層次。第一層次，服務(wù)器是擁有高精度計(jì)時(shí)設(shè)備的，每個(gè)機(jī)房若干臺(tái)，大部分機(jī)器都裝備了 GPS 接收器，剩下少數(shù)機(jī)器是為 GPS 系統(tǒng)全部失效的情況而準(zhǔn)備的，叫做“末日”服務(wù)器，裝備了原子鐘。所有的 Spanner 服務(wù)器都屬于第二層，定期向多個(gè)第一層的時(shí)間服務(wù)器獲取時(shí)間來校正本地時(shí)鐘，先減去通信時(shí)間，再去除異常值，最后求交集。

NewSQL

六年前，BigTable 展示了一個(gè)簡潔、優(yōu)美、具有高可擴(kuò)展性的分布式數(shù)據(jù)庫系統(tǒng)，引起了 NoSQL 浪潮。然而 Spanner 的設(shè)計(jì)者們指出了 BigTable 在應(yīng)用中遇到的一些阻力。

? 缺少類似 SQL 的界面，缺少關(guān)系數(shù)據(jù)庫擁有的豐富的功能。? 只支持單行事務(wù)，缺少跨行事務(wù)。

?

需要在跨數(shù)據(jù)中心的多個(gè)副本間保證一致性。

這些來自應(yīng)用開發(fā)者的需求催生了 Spanner，一個(gè)既擁有 key-value 系統(tǒng)的高可擴(kuò)展性，也擁有關(guān)系數(shù)據(jù)庫的豐富功能（包括事務(wù)、一致性等特性）的系統(tǒng)。這類兼顧可擴(kuò)展性和關(guān)系數(shù)據(jù)庫功能的產(chǎn)品被稱為“NewSQL”，Spanner 的公開會(huì)不會(huì)開啟 NewSQL 的時(shí)代呢？我們拭目以待。

總結(jié)

最后從 CAP 定理的角度來分析下 Spanner。

CAP 定理是指在網(wǎng)絡(luò)可能出現(xiàn)分區(qū)故障的情況下，一致性和可用性不可得兼。形式化地說就是，P => 非(A與P)，可以更進(jìn)一步地總結(jié)為，一致性和延遲之間必須進(jìn)行權(quán)衡。Paxos 協(xié)議在C和A之間選擇了嚴(yán)格的一致性，而A則降級(jí)為大多數(shù)一致性（majority available）。

Spanner 還通過在事務(wù)中增加延遲的方法實(shí)現(xiàn)了外部一致性，每個(gè)事務(wù)需要至少兩倍的時(shí)鐘誤差才能完成。如果時(shí)鐘出現(xiàn)故障造成誤差增長，那么完成事務(wù)所需的時(shí)間也就隨之增長。在這里，時(shí)鐘故障也應(yīng)當(dāng)認(rèn)為是P的一種形式。在發(fā)生時(shí)鐘故障（P）的情況下，為了保證一致性（C），而必須增加延遲（A），這一點(diǎn)充分印證了 CAP 定理。

從 Spanner 系統(tǒng)中，我們可以學(xué)習(xí)到一些經(jīng)驗(yàn)。

? MegaStore、Spanner 和 F1 系統(tǒng)所選擇的樹形、層次化的數(shù)據(jù)庫 schema 是很精妙的，它能支持高效的表連接，這既提供了類似關(guān)系模型的范式，也提供了一個(gè)合適的粒度進(jìn)行數(shù)據(jù)分區(qū)，具有好的可擴(kuò)展性，H-Store 也采用了這樣的 schema。

? 跨數(shù)據(jù)中心的多個(gè)副本間保持一致是可行的，Paxos 協(xié)議的性能可以優(yōu)化到一個(gè)可接受的范圍。

? 在 Paxos 協(xié)議的基礎(chǔ)之上實(shí)現(xiàn)的兩階段提交的可用性得到了提高。? 在一個(gè)分布式系統(tǒng)中，本地時(shí)鐘的作用可以比我們之前想象的大很多。

作者曹偉，淘寶核心系統(tǒng)數(shù)據(jù)庫組技術(shù)專家，從事高性能服務(wù)器、IM、P2P、微博等各類型分布式系統(tǒng)、海量存儲(chǔ)產(chǎn)品的開發(fā)，關(guān)注系統(tǒng)高可用性和一致性及分布式事務(wù)領(lǐng)域。

第二篇：Google Megastore分布式存儲(chǔ)技術(shù)全揭秘

Google Megastore分布式存儲(chǔ)技術(shù)全揭秘

導(dǎo)讀：本文根據(jù)Google最新Megastore論文翻譯而來，原作者為Google團(tuán)隊(duì)，團(tuán)隊(duì)人員包括：Jason Baker，Chris Bond，James C.Corbett，JJ Furman，Andrey Khorlin，James Larson，Jean-Michel Léon，Yawei Li，Alexander Lloyd，Vadim Yushprakh。翻譯者為國內(nèi)知名IT人士。

在上個(gè)月舉行的創(chuàng)新數(shù)據(jù)系統(tǒng)研討會(huì)上(CIDR)，Google公開了其Megastore分布式存儲(chǔ)技術(shù)的白皮書。

Megastore是谷歌一個(gè)內(nèi)部的存儲(chǔ)系統(tǒng)，它的底層數(shù)據(jù)存儲(chǔ)依賴Bigtable，也就是基于NoSql實(shí)現(xiàn)的，但是和傳統(tǒng)的NoSql不同的是，它實(shí)現(xiàn)了類似RDBMS的數(shù)據(jù)模型(便捷性)，同時(shí)提供數(shù)據(jù)的強(qiáng)一致性解決方案(同一個(gè)datacenter，基于MVCC的事務(wù)實(shí)現(xiàn))，并且將數(shù)據(jù)進(jìn)行細(xì)顆粒度的分區(qū)(這里的分區(qū)是指在同一個(gè)datacenter，所有datacenter都有相同的分區(qū)數(shù)據(jù))，然后將數(shù)據(jù)更新在機(jī)房間進(jìn)行同步復(fù)制(這個(gè)保證所有datacenter中的數(shù)據(jù)一致)。Megastore的數(shù)據(jù)復(fù)制是通過paxos進(jìn)行同步復(fù)制的，也就是如果更新一個(gè)數(shù)據(jù)，所有機(jī)房都會(huì)進(jìn)行同步更新，因?yàn)槭褂胮axos進(jìn)行復(fù)制，所以不同機(jī)房針對(duì)同一條數(shù)據(jù)的更新復(fù)制到所有機(jī)房的更新順序都是一致的，同步復(fù)制保證數(shù)據(jù)的實(shí)時(shí)可見性，采用paxos算法則保證了所有機(jī)房更新的一致性，所以個(gè)人認(rèn)為megastore的更新可能會(huì)比較慢，而所有讀都是實(shí)時(shí)讀(對(duì)于不同機(jī)房是一致的)，因?yàn)椴渴鹩卸鄠€(gè)機(jī)房，并且數(shù)據(jù)總是最新。

為了達(dá)到高可用性，megastore實(shí)現(xiàn)了一個(gè)同步的，容錯(cuò)的，適合長距離連接的日志同步器 為了達(dá)到高可擴(kuò)展性，megastore將數(shù)據(jù)分區(qū)成一個(gè)個(gè)小的數(shù)據(jù)庫，每一個(gè)數(shù)據(jù)庫都有它們自己的日志，這些日志存儲(chǔ)在NoSql中 Megastore將數(shù)據(jù)分區(qū)為一個(gè)Entity Groups的集合，這里的Entity Groups相當(dāng)于一個(gè)按id切分的分庫，這個(gè)Entity Groups里面有多個(gè)Entity Group(相當(dāng)于分庫里面的表)，而一個(gè)Entity Group有多個(gè)Entity(相當(dāng)于表中的記錄)

在同一個(gè)Entity Group中(相當(dāng)于單庫)的多個(gè)Entity的更新事務(wù)采用single-phase ACID事務(wù)，而跨Entity Group(相當(dāng)于跨庫)的Entity更新事務(wù)采用two-phase ACID事務(wù)(2段提交)，但更多使用Megastore提供的高效異步消息實(shí)現(xiàn)。需要說明的一點(diǎn)是，這些事務(wù)都是在同一個(gè)機(jī)房的，機(jī)房之間的數(shù)據(jù)交互都是通過數(shù)據(jù)復(fù)制來實(shí)現(xiàn)的。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫使用join來滿足用戶的需求，對(duì)于Megastore來說，這種模型(也就是完全依賴join的模型)是不合適的。原因包括

1.高負(fù)載交互性型應(yīng)用能夠從可預(yù)期的性能提升得到的好處多于使用一種代價(jià)高昂的查詢語言所帶來的好處。2.Megastore目標(biāo)應(yīng)用是讀遠(yuǎn)遠(yuǎn)多于寫的，所以更好的方案是將讀操作所需要做的工作轉(zhuǎn)移到寫操作上面(比如通過具體值代替外鍵以消除join)3.因?yàn)閙egastore底層存儲(chǔ)是采用BigTable，而類似BigTable的key-value存儲(chǔ)對(duì)于存取級(jí)聯(lián)數(shù)據(jù)是直接的

所以基于以上幾個(gè)原因，Megastore設(shè)計(jì)了一種數(shù)據(jù)模型和模式語言來提供基于物理地點(diǎn)的細(xì)顆粒度控制，級(jí)聯(lián)布局，以及申明式的不正規(guī)數(shù)據(jù)存儲(chǔ)來幫助消除大部分joins。查詢時(shí)只要指定特定表和索引即可。

當(dāng)然可能有時(shí)候不得不使用到j(luò)oin，Megastore提供了一種合并連接算法實(shí)現(xiàn)，具體算法這里我還是沒弄清楚，原文是[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的應(yīng)用通過并行查詢實(shí)現(xiàn)了outer joins。通常先進(jìn)行一個(gè)初始的查詢，然后利用這個(gè)查詢結(jié)果進(jìn)行并行索引查詢，這個(gè)過程我理解的是，初始查詢查出一條數(shù)據(jù)，就馬上根據(jù)這個(gè)結(jié)果進(jìn)行并行查詢，這個(gè)時(shí)候初始查詢繼續(xù)取出下一條數(shù)據(jù)，再根據(jù)這個(gè)結(jié)果并行查詢(可能前面那個(gè)外鍵查詢還在繼續(xù)，使用不同的線程)。這種方法在初始查詢數(shù)據(jù)量較小并且外鍵查詢使用并行方式的情況下，是一種有效的并且具有sql風(fēng)格的joins。Megastore的數(shù)據(jù)結(jié)構(gòu)介于傳統(tǒng)的RDBMS和NoSql之間的，前者主要體現(xiàn)在他的schema表示上，而后者體現(xiàn)在具體的數(shù)據(jù)存儲(chǔ)上(BigTable)。和RDBMS一樣，Megastore的數(shù)據(jù)模型是定義schema中并且是強(qiáng)類型的。每一個(gè)schema有一個(gè)表集合，每個(gè)表包含一個(gè)實(shí)體集合(相當(dāng)于record)，每個(gè)實(shí)體有一系列的屬性(相當(dāng)于列屬性)，屬性是命名的，并且指定類型，這些類型包括字符串，各種數(shù)字類型，或者google的protocol buffer。這些屬性可以被設(shè)置成必需的，可選的，或者可重復(fù)的(一個(gè)屬性上可以具有多個(gè)值)。一個(gè)或者多個(gè)屬性可以組成一個(gè)主鍵。

在上圖中，User和Photo共享了一個(gè)公共屬性u(píng)ser_id，IN TABLE User這個(gè)標(biāo)記直接將Photo和User這兩張表組織到了同一個(gè)BigTable中，并且鍵的順序(PRIMARY KEY(user_id,photo_id)？是這個(gè)還是schema中定義的順序？)保證Photo的實(shí)體存儲(chǔ)在對(duì)應(yīng)的User實(shí)體鄰接位置上。這個(gè)機(jī)制可以遞歸的應(yīng)用，加速任意深度的join查詢速度。這樣，用戶能夠通過操作鍵的順序強(qiáng)行改變數(shù)據(jù)級(jí)聯(lián)的布局。其他標(biāo)簽請(qǐng)參考原文。Megastore支持事務(wù)和并發(fā)控制。一個(gè)事務(wù)寫操作會(huì)首先寫入對(duì)應(yīng)Entity Group的日志中，然后才會(huì)更新具體數(shù)據(jù)。BigTable具有一項(xiàng)在相同row/column中存儲(chǔ)多個(gè)版本帶有不同時(shí)間戳的數(shù)據(jù)。正是因?yàn)橛羞@個(gè)特性，Megastore實(shí)現(xiàn)了多版本并發(fā)控制(MVCC，這個(gè)包括oracle，innodb都是使用這種方式實(shí)現(xiàn)ACID，當(dāng)然具體方式會(huì)有所不同)：當(dāng)一個(gè)事務(wù)的多個(gè)更新實(shí)施時(shí)，寫入的值會(huì)帶有這個(gè)事務(wù)的時(shí)間戳。讀操作會(huì)使用最后一個(gè)完全生效事務(wù)的時(shí)間戳以避免看到不完整的數(shù)據(jù).讀寫操作不相互阻塞，并且讀操作在寫事務(wù)進(jìn)行中會(huì)被隔離(？)。

Megastore 提供了current，snapshot，和inconsistent讀，current和snapshot級(jí)別通常是讀取單個(gè)entity group。當(dāng)開始一個(gè)current讀操作時(shí)，事務(wù)系統(tǒng)會(huì)首先確認(rèn)所有之前提交的寫已經(jīng)生效了；然后系統(tǒng)從最后一個(gè)成功提交的事務(wù)時(shí)間戳位置讀取數(shù)據(jù)。對(duì)于snapshot讀取，系統(tǒng)拿到己經(jīng)知道的完整提交的事務(wù)時(shí)間戳并且從那個(gè)位置直接讀取數(shù)據(jù)，和current讀取不同的是，這個(gè)時(shí)候可能提交的事務(wù)更新數(shù)據(jù)還沒有完全生效(提交和生效是不同的)。Megastore提供的第三種讀就是inconsistent讀，這種讀無視日志狀態(tài)并且直接讀取最后一個(gè)值。這種方式的讀對(duì)于那些對(duì)減少延遲有強(qiáng)烈需求，并且能夠容忍數(shù)據(jù)過期或者不完整的讀操作是非常有用的。

一個(gè)寫事務(wù)通常開始于一個(gè)current讀操作以便確定下一個(gè)可用的日志位置。提交操作將數(shù)據(jù)變更聚集到日志，并且分配一個(gè)比之前任何一個(gè)都高的時(shí)間戳，并且使用Paxos將這個(gè)log entry加入到日志中。這個(gè)協(xié)議使用了樂觀并發(fā)：即使有可能有多個(gè)寫操作同時(shí)試圖寫同一個(gè)日志位置，但只會(huì)有1個(gè)成功。所有失敗的寫都會(huì)觀察到成功的寫操作，然后中止，并且重試它們的操作。咨詢式的鎖定能夠減少爭用所帶來的影響。通過特定的前端服務(wù)器分批寫入似乎能夠完全避免競爭(這幾句有些不能理解)[ 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.]。完整事務(wù)生命周期包括以下步驟：

1.讀：獲取時(shí)間戳和最后一個(gè)提交事務(wù)的日志位置

2.應(yīng)用邏輯：從BigTable讀取并且聚集寫操作到一個(gè)日志Entry 3.提交：使用Paxos將日志Entry加到日志中 4.生效：將數(shù)據(jù)更新到BigTable的實(shí)體和索引中 5.清理：刪除不再需要的數(shù)據(jù)

寫操作能夠在提交之后的任何點(diǎn)返回，但是最好還是等到最近的副本(replica)生效(再返回)。Megastore提供的消息隊(duì)列提供了在不同Entity Group之間的事務(wù)消息。它們能被用作跨Entity Group的操作，在一個(gè)事務(wù)中分批執(zhí)行多個(gè)更新，或者延緩工作(？)。一個(gè)在單個(gè)Entity Group上的事務(wù)能夠原子性地發(fā)送或者收到多個(gè)信息除了更新它自己的實(shí)體。每個(gè)消息都有一個(gè)發(fā)送和接收的Entity Group；如果這兩個(gè)Entity Group是不同的，那么傳輸將會(huì)是異步的。

消息隊(duì)列提供了一種將會(huì)影響到多個(gè)Entity Group的操作的途徑，舉個(gè)例子，日歷應(yīng)用中，每一個(gè)日歷有一個(gè)獨(dú)立的Entity Group，并且我們現(xiàn)在需要發(fā)送一個(gè)邀請(qǐng)到多個(gè)其他人的日歷中，一個(gè)事務(wù)能夠原子地發(fā)送邀請(qǐng)消息到多個(gè)獨(dú)立日歷中。每個(gè)日歷收到消息都會(huì)把邀請(qǐng)加入到它自己的事務(wù)中，并且這個(gè)事務(wù)會(huì)更新被邀請(qǐng)人狀態(tài)然后刪除這個(gè)消息。Megastore大規(guī)模使用了這種模式：聲明一個(gè)隊(duì)列后會(huì)自動(dòng)在每一個(gè)Entity Group上創(chuàng)建一個(gè)收件箱。Megastore支持使用二段提交進(jìn)行跨Entity Group的原子更新操作。因?yàn)檫@些事務(wù)有比較高的延遲并且增加了競爭的風(fēng)險(xiǎn)，一般不鼓勵(lì)使用。

接下來內(nèi)容具體來介紹下Megastore最核心的同步復(fù)制模式：一個(gè)低延遲的Paxos實(shí)現(xiàn)。Megastore的復(fù)制系統(tǒng)向外提供了一個(gè)單一的，一致的數(shù)據(jù)視圖，讀和寫能夠從任何副本(repli ca)開始，并且無論從哪個(gè)副本的客戶端開始，都能保證ACID語義。每個(gè)Entity Group復(fù)制結(jié)束標(biāo)志是將這個(gè)Entity Group事務(wù)日志同步地復(fù)制到一組副本中。寫操作通常需要一個(gè)數(shù)據(jù)中心內(nèi)部的網(wǎng)絡(luò)交互，并且會(huì)跑檢查健康狀況的讀操作。current級(jí)別的讀操作會(huì)有以下保證：

1.一個(gè)讀總是能夠看到最后一個(gè)被確認(rèn)的寫。(可見性)2.在一個(gè)寫被確認(rèn)后，所有將來的讀都能夠觀察到這個(gè)寫的結(jié)果。(持久性，一個(gè)寫可能在確認(rèn)之前就被觀察到)數(shù)據(jù)庫典型使用Paxos一般是用來做事務(wù)日志的復(fù)制，日志中每個(gè)位置都由一個(gè)Paxos實(shí)例來負(fù)責(zé)。新的值將會(huì)被寫入到之前最后一個(gè)被選中的位置之后。

Megastore在事先Paxos過程中，首先設(shè)定了一個(gè)需求，就是current reads可能在任何副本中進(jìn)行，并且不需要任何副本之間的RPC交互。因?yàn)閷懖僮饕话銜?huì)在所有副本上成功，所以允許在任何地方進(jìn)行本地讀取是現(xiàn)實(shí)的。這些本地讀取能夠很好地被利用，所有區(qū)域的低延遲，細(xì)顆粒度的讀取failover，還有簡單的編程體驗(yàn)。

Megastore設(shè)計(jì)實(shí)現(xiàn)了一個(gè)叫做Coordinator(協(xié)調(diào)者)的服務(wù)，這個(gè)服務(wù)分布在每個(gè)副本的數(shù)據(jù)中心里面。一個(gè)Coordinator服務(wù)器跟蹤一個(gè)Entity Groups集合，這個(gè)集合中的Entity Groups需要具備的條件就是它們的副本已經(jīng)觀察到了所有的Paxos寫。在這個(gè)集合中的Entity Groups，它們的副本能夠進(jìn)行本地讀取(local read)。

寫操作算法有責(zé)任保持Coordinator狀態(tài)是保守的，如果一個(gè)寫在一個(gè)副本上失敗了，那么這次操作就不能認(rèn)為是提交的，直到這個(gè)entity group的key從這個(gè)副本的coordinator中去除。(這里不明白)為了達(dá)到快速的單次交互的寫操作，Megastore采用了一種Master-Slave方式的優(yōu)化，如果一次寫成功了，那么會(huì)順帶下一次寫的保證(也就是下一次寫就不需要prepare去申請(qǐng)一個(gè)log position)，下一次寫的時(shí)候，跳過prepare過程，直接進(jìn)入accept階段。Megastore沒有使用專用的Masters，但是使用Leaders。

Megastore為每一個(gè)日志位置運(yùn)行一個(gè)Paxos算法實(shí)例。[ The leader for each log position is a distinguished replica chosen alongside the preceding log position's consensus value.] Leader仲裁在0號(hào)提議中使用哪一個(gè)值。第一個(gè)寫入者向Leader提交一個(gè)值會(huì)贏得一個(gè)向所有副本請(qǐng)求接收這個(gè)值做為0號(hào)提議最終值的機(jī)會(huì)。所有其他寫入者必需退回到Paxos的第二階段。

因?yàn)橐粋€(gè)寫入在提交值到其他副本之前必需和Leader交互，所以必需盡量減少寫入者和Leader之間的延遲。Megastore設(shè)計(jì)了它們自己的選取下一個(gè)寫入Leader的規(guī)則，以同一地區(qū)多數(shù)應(yīng)用提交的寫操作來決定。這個(gè)產(chǎn)生了一個(gè)簡單但是有效的原則：使用最近的副本。(這里我理解的是哪個(gè)位置提交的寫多，那么使用離這個(gè)位置最近的副本做為Leader)Megastore的副本中除了有日志有Entity數(shù)據(jù)和索引數(shù)據(jù)的副本外，還有兩種角色，其中一種叫做觀察者(Witnesses)，它們只寫日志，并且不會(huì)讓日志生效，也沒有數(shù)據(jù)，但是當(dāng)副本不足以組成一個(gè)quorum的時(shí)候，它們就可以加入進(jìn)來。另外一種叫只讀副本(Read-Only)，它剛剛和觀察者相反，它們只有數(shù)據(jù)的鏡像，在這些副本上只能讀取到最近過去某一個(gè)時(shí)間點(diǎn)的一致性數(shù)據(jù)。如果讀操作能夠容忍這些過期數(shù)據(jù)，只讀副本能夠在廣闊的地理空間上進(jìn)行數(shù)據(jù)傳輸并且不會(huì)加劇寫的延遲。

上圖顯示了Megastore的關(guān)鍵組件，包括兩個(gè)完整的副本和一個(gè)觀察者。應(yīng)用連接到客戶端庫，這個(gè)庫實(shí)現(xiàn)了Paxos和其他一些算法：選擇一個(gè)副本進(jìn)行讀，延遲副本的追趕，等等。

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.客戶端，網(wǎng)絡(luò)，或者BigTable失敗可能讓一個(gè)寫操作停止在一個(gè)中間狀態(tài)。復(fù)制的服務(wù)器會(huì)定期掃描未完成的寫入并且通過Paxos提議沒有操作的值來讓寫入完成。

接下來介紹下Megastore的數(shù)據(jù)結(jié)構(gòu)和算法，每一個(gè)副本存有更新和日志Entries的元數(shù)據(jù)。為了保證一個(gè)副本能夠參與到一個(gè)寫入的投票中即使是它正從一個(gè)之前的宕機(jī)中恢復(fù)數(shù)據(jù)，Megastore允許這個(gè)副本接收不符合順序的提議。Megastore將日志以獨(dú)立的Cells存儲(chǔ)在BigTable中。

當(dāng)日志的前綴不完整時(shí)(這個(gè)前綴可能就是一個(gè)日志是否真正寫入的標(biāo)記，分為2段，第一段是在寫入日志之前先寫入的幾個(gè)字節(jié)，然后寫入日志，第二段是在寫入日志之后寫入的幾個(gè)字節(jié)，只有這個(gè)日志前綴是完整的，這個(gè)日志才是有效的)，日志將會(huì)留下holes。下圖表示了一個(gè)單獨(dú)Megastore Entity Group的日志副本典型場景。0-99的日志位置已經(jīng)被清除了，100的日志位置是部分被清除，因?yàn)槊總€(gè)副本都會(huì)被通知到其他副本已經(jīng)不需要這個(gè)日志了。101日志位置被所有的副本接受了(accepted)，102日志位置被Y所獲得，103日志位置被A和C副本接受，B副本留下了一個(gè)hole，104日志位置因?yàn)楦北続和B的不一致，復(fù)本C的沒有響應(yīng)而沒有一致結(jié)果。

在一個(gè)current讀的準(zhǔn)備階段(寫之前也一樣)，必需有一個(gè)副本要是最新的：所有之前更新必需提交到那個(gè)副本的日志并且在該副本上生效。我們叫這個(gè)過程為catchup。省略一些截止超時(shí)的管理，一個(gè)current讀算法步驟如下：

1.本地查詢：查詢本地副本的Coordinator，判定當(dāng)前副本的Entity Group是最新的 2.查找位置：確定最高的可能已提交的日志位置，然后選擇一個(gè)己經(jīng)將這個(gè)日志位置生效的副本

a.(Local read)如果步驟1發(fā)現(xiàn)本地副本是最新的，那么從本地副本中讀取最高的被接受(accepted)的日志位置和時(shí)間戳。

b.(Majority read)如果本地副本不是最新的(或者步驟1或步驟2a超時(shí))，那么從一個(gè)多數(shù)派副本中發(fā)現(xiàn)最大的日志位置，然后選取一個(gè)讀取。我們選取一個(gè)最可靠的或者最新的副本，不一定總是是本地副本

3.追趕：當(dāng)一個(gè)副本選中之后，按照下面的步驟追趕到已知的日志位置: a.對(duì)于被選中的不知道共識(shí)值的副本中的每一個(gè)日志位置，從另外一個(gè)副本中讀取值。對(duì)于任何一個(gè)沒有已知已提交的值的日志位置，發(fā)起一個(gè)沒有操作的寫操作。Paxos將會(huì)驅(qū)動(dòng)多數(shù)副本在一個(gè)值上打成共識(shí)-----可能是none-op的寫操作或者是之前提議的寫操作 b.順序地將所有沒有生效的日志位置生效成共識(shí)的值，并將副本的狀態(tài)變?yōu)榈椒植际焦沧R(shí)狀態(tài)(應(yīng)該是Coordinator的狀態(tài)更新)如果失敗，在另外一個(gè)副本上重試。4.驗(yàn)證：如果本地副本被選中并且之前沒有最新，發(fā)送一個(gè)驗(yàn)證消息到coordinator斷定(entity group,replica)能夠反饋(reflects)所有提交的寫操作。不要等待回應(yīng)----如果請(qǐng)求失敗，下一個(gè)讀操作會(huì)重試。

5.查詢數(shù)據(jù)：從選中的副本中使用日志位置所有的時(shí)間戳讀取數(shù)據(jù)。如果選中的副本不可用，選取另外一個(gè)副本重新開始執(zhí)行追趕，然后從它那里讀取。一個(gè)大的讀取結(jié)果有可能從多個(gè)副本中透明地讀取并且組裝返回

注意在實(shí)際使用中 1和2a通常是并行執(zhí)行的。

在完整的讀操作算法執(zhí)行后，Megastore發(fā)現(xiàn)了下一個(gè)沒有使用的日志位置，最后一個(gè)寫操作的時(shí)間戳，還有下一個(gè)leader副本。在提交時(shí)刻，所有更新的狀態(tài)都變?yōu)榇虬?packaged)和提議(proposed)，并且包含一個(gè)時(shí)間戳和下一個(gè)leader 候選人，做為下一個(gè)日志位置的共識(shí)值。如果這個(gè)值贏得了分布式共識(shí)，那么這個(gè)值將會(huì)在所有完整的副本中生效。否則整個(gè)事務(wù)將會(huì)終止并且必需重新從讀階段開始。

就像上面所描述的，Coordinators跟蹤Entity Groups在它們的副本中是否最新。如果一個(gè)寫操作沒有被一個(gè)副本接受，我們必需將這個(gè)Entity Group的鍵從這個(gè)副本的Coordinator中移除。這個(gè)步驟叫做invalidation(失效)。在一個(gè)寫操作被認(rèn)為提交的并且準(zhǔn)備生效，所有副本必需已經(jīng)接受或者讓這個(gè)Entity Group在它們coordinator上失效。寫算法的步驟如下：

1.接受Leader：請(qǐng)求Leader接受值做為0號(hào)提議的值。如果成功。跳到第三步

2.準(zhǔn)備：在所有副本上執(zhí)行Paxos Prepare階段，使用一個(gè)關(guān)于當(dāng)前l(fā)og位置更高的提議號(hào)。將值替換成擁有最高提議號(hào)的那個(gè)值。[Replace the value being written withthe highest-numbered proposal discovered, if any] 3.接受：請(qǐng)求余下的副本接受這個(gè)值。如果多數(shù)副本失敗，轉(zhuǎn)到第二步。4.失效：將沒有接受值的副本coordinator失效掉。錯(cuò)誤處理將在接下來描述

5.生效：將更新在盡可能多的副本上生效。如果選擇的值不同于原始提議的，返回沖突錯(cuò)誤[？]

Coordinator進(jìn)程在每一個(gè)數(shù)據(jù)中心運(yùn)行并且只保持其本地副本的狀態(tài)。在上述的寫入算法中，每一個(gè)完整的副本必需接受或者讓其coordinator失效，所以這個(gè)可能會(huì)出現(xiàn)任何單個(gè)副本失效就會(huì)引起不可用。在實(shí)際使用中這個(gè)不是一個(gè)尋常的問題。Coordinator是一個(gè)簡單的進(jìn)程，沒有其他額外的依賴并且沒有持久存儲(chǔ)，所以它表現(xiàn)得比一個(gè)BigTable服務(wù)器更高的穩(wěn)定性。然而，網(wǎng)絡(luò)和主機(jī)失敗仍然能夠讓coordinator不可用。

Megastore使用了Chubby鎖服務(wù)：Coordinators在啟動(dòng)的時(shí)候從遠(yuǎn)程數(shù)據(jù)中心獲取指定的Chubby locks。為了處理請(qǐng)求，一個(gè)Coordinator必需持有其多數(shù)locks。一旦因?yàn)殄礄C(jī)或者網(wǎng)絡(luò)問題導(dǎo)致它丟失了大部分鎖，它就會(huì)恢復(fù)到一個(gè)默認(rèn)保守狀態(tài)----認(rèn)為所有在它所能看見的Entity Groups都是失效的。隨后(該Coordinator對(duì)應(yīng)的)副本中的讀操作必需從多數(shù)其他副本中得到日志位置直到Coordinator重新獲取到鎖并且Coordinator的Entries重新驗(yàn)證的。

寫入者通過測試一個(gè)Coordinator是否丟失了它的鎖從而讓其在Coordinator不可用過程中得到保護(hù)：在這個(gè)場景中，一個(gè)寫入者知道在恢復(fù)之前Coordinator會(huì)認(rèn)為自己是失效的。在一個(gè)數(shù)據(jù)中心活著的Coordinator突然不可用時(shí)，這個(gè)算法需要面對(duì)一個(gè)短暫(幾十秒)的寫停頓風(fēng)險(xiǎn)---所有的寫入者必需等待Coordinator的Chubby locks過期(相當(dāng)于等待一個(gè)master failover后重新啟動(dòng))，不同于master failover，寫入和讀取都能夠在coordinator狀態(tài)重建前繼續(xù)平滑進(jìn)行。除了可用性問題，對(duì)于Coordinator的讀寫協(xié)議必需滿足一系列的競爭條件。失效的信息總是安全的，但是生效的信息必需小心處理。在coordinator中較早的寫操作生效和較晚的寫操作失效之間的競爭通過帶有日志位置而被保護(hù)起來。標(biāo)有較高位置的失效操作總是勝過標(biāo)有較低位置的生效操作。一個(gè)在位置n的失效操作和一個(gè)在位置m

總體來說，使用Coordinator從而能夠在任何數(shù)據(jù)中心進(jìn)行快速的本地讀取對(duì)于可用性的影響并不是完全沒有的。但是實(shí)際上，以下因素能夠減輕使用Coordinator所帶來的問題。1.Coordinators是比任何的BigTable 服務(wù)器更加簡單進(jìn)程，機(jī)會(huì)沒有依賴，所以可用性更高。

2.Coordinators簡單，均勻的工作負(fù)載讓它們能夠低成本地進(jìn)行預(yù)防措施。3.Coordinators輕量的網(wǎng)絡(luò)傳輸允許使用高可用連接進(jìn)行服務(wù)質(zhì)量監(jiān)控。

4.管理員能夠在維護(hù)期或者非安全期集中地讓一批Coordinators失效。對(duì)于默寫信號(hào)的監(jiān)測是自動(dòng)的。

5.一個(gè)Chubby qunrum能夠監(jiān)測到大多數(shù)網(wǎng)絡(luò)問題和節(jié)點(diǎn)不可用?？偨Y(jié)

文章總體介紹了下google megastore的實(shí)現(xiàn)思路，其主要解決的問題就是如何在復(fù)雜的環(huán)境下(網(wǎng)絡(luò)問題,節(jié)點(diǎn)失效等等)保證數(shù)據(jù)存取服務(wù)的可用性。對(duì)于多機(jī)房，多節(jié)點(diǎn)，以及ACID事務(wù)支持，實(shí)時(shí)非實(shí)時(shí)讀取，錯(cuò)誤處理等等關(guān)鍵問題上給出了具體方案。

第三篇：分布式OA系統(tǒng)的數(shù)據(jù)庫同步復(fù)制技術(shù)

分布式OA系統(tǒng)的數(shù)據(jù)庫同步復(fù)制技術(shù)

一、背景概述

隨著政府上網(wǎng)、電子政務(wù)的不斷普及和深入，IBM公司的Lotus Domino系統(tǒng)在國內(nèi)得到廣泛的應(yīng)用。其中不乏大型的、跨地域的企事業(yè)單位或集團(tuán)公司應(yīng)用案例。這些案例一般采用分布式系統(tǒng)結(jié)構(gòu)，即分布在全國各地的分支機(jī)構(gòu)分別設(shè)有獨(dú)立的數(shù)據(jù)庫服務(wù)器，各地?cái)?shù)據(jù)庫服務(wù)器采用數(shù)據(jù)庫同步復(fù)制的方式更新本地?cái)?shù)據(jù)庫復(fù)本內(nèi)容。從而使得各地終端用戶及時(shí)、快捷、可靠地訪問到最新公告、新聞等。

本文結(jié)合呼和浩特鐵路局客運(yùn)公司辦公自動(dòng)化系統(tǒng)案例討論基于IBM公司的Lotus Domino技術(shù)構(gòu)建的分布式OA系統(tǒng)中數(shù)據(jù)庫之間的同步復(fù)制技術(shù)。

二、幾個(gè)概念

IBM公司的Lotus產(chǎn)品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server為后臺(tái)數(shù)據(jù)庫平臺(tái)，Lotus Notes為客戶端，Lotus Domino Administrator為系統(tǒng)管理平臺(tái)，Lotus Domino Designer設(shè)計(jì)開發(fā)工具。先介紹幾個(gè)Domino中和同步復(fù)制有關(guān)的概念。

1、復(fù)制

Notes允許在多個(gè)服務(wù)器或工作站上保存數(shù)據(jù)庫的多個(gè)拷貝，這些拷貝稱做“復(fù)本”。它們使各個(gè)地方的不同網(wǎng)絡(luò)上的用戶共享相同的信息。復(fù)本與文件的拷貝不同之處在于在復(fù)制時(shí)源文件與其復(fù)本具有相同的復(fù)本標(biāo)識(shí)符。

復(fù)制是在復(fù)本之間共享更改信息的過程。復(fù)制時(shí)，Notes通過把更改信息從一個(gè)復(fù)本拷貝到另一個(gè)復(fù)本來更新復(fù)本。最終，Notes 使所有復(fù)本保持一致?？梢赃x擇在復(fù)本拷貝之間進(jìn)行復(fù)制，這時(shí)兩個(gè)復(fù)本都發(fā)送并接收更新信息，或者選擇僅從一個(gè)復(fù)本復(fù)制到另一個(gè)復(fù)本。

也可以定期安排復(fù)制，或者根據(jù)需要手動(dòng)進(jìn)行復(fù)制。復(fù)制可以在兩臺(tái)服務(wù)器之間或者在服務(wù)器和工作站之間進(jìn)行。如果設(shè)定為定期進(jìn)行完整復(fù)制，那么 Notes會(huì)根據(jù)時(shí)間使所有復(fù)本保持同步。

2、復(fù)本標(biāo)識(shí)符

復(fù)本與源文件或數(shù)據(jù)庫有相同的復(fù)本標(biāo)識(shí)符。這是數(shù)據(jù)庫的復(fù)本與拷貝的區(qū)別所在，因?yàn)橛泄餐臉?biāo)識(shí)符才能使復(fù)本與源數(shù)據(jù)庫之間可以復(fù)制更改信息。如果數(shù)據(jù)庫的兩個(gè)拷貝具有不同的復(fù)本標(biāo)識(shí)符，則不能在它們之間進(jìn)行復(fù)制。

3、復(fù)制沖突和保存沖突

在復(fù)制之間，如果有兩個(gè)或多個(gè)用戶對(duì)相同文檔的不同復(fù)本進(jìn)行了編輯，就會(huì)導(dǎo)致復(fù)制沖突。而保存沖突則是在兩個(gè)或多個(gè)用戶同時(shí)編輯服務(wù)器上同一個(gè)數(shù)據(jù)庫的同一個(gè)文檔時(shí)發(fā)生。當(dāng)發(fā)生復(fù)制沖突或保存沖突時(shí)，Notes 將在視圖頁面左邊把發(fā)生沖突的文檔標(biāo)注出來。

Notes對(duì)復(fù)制沖突的處理是這樣的，在兩個(gè)或多個(gè)用戶編輯并保存同一個(gè)文檔之后，下次進(jìn)行復(fù)制時(shí)，Notes 將編輯和保存最頻繁的文檔指定為主文檔，而將其他文檔顯示為主文檔的答復(fù)文檔，并在視圖頁面左邊用一個(gè)菱形符號(hào)標(biāo)注出來。如果用戶在一個(gè)復(fù)本中編輯并保存了某文檔，然后另一個(gè)用戶將該文檔刪除，則認(rèn)為該文檔是被刪除的。然而，如果文檔被編輯和保存了多次，或者在該文檔被刪除之后又被另一個(gè)用戶編輯和保存過，則把編輯過的文檔作為主文檔。

Note對(duì)保存沖突的處理如下，當(dāng)多個(gè)用戶同時(shí)打開相同的文檔進(jìn)行編輯時(shí)，Notes指定最先保存的文檔為主文檔。當(dāng)另一個(gè)用戶試圖保存同一文檔時(shí)，Notes 就會(huì)提示該用戶把它作為“保存沖突”文檔來保存。如果用戶這樣做了，那么 Notes 將它顯示為主文檔的答復(fù)文檔，并在視圖頁面左邊用一個(gè)菱形符號(hào)標(biāo)注出來。

根據(jù)筆者的經(jīng)驗(yàn)，在實(shí)際開發(fā)過程中，我們應(yīng)該通過設(shè)計(jì)控制保存沖突，避免文檔產(chǎn)生“保存沖突”的答復(fù)文檔。對(duì)于復(fù)制沖突可以設(shè)置數(shù)據(jù)庫合并復(fù)制沖突，這樣如果產(chǎn)生增量改動(dòng)，服務(wù)器在復(fù)制過程中會(huì)自動(dòng)合并沖突。需要說明的是，Notes在進(jìn)行復(fù)制時(shí)，并不是傳統(tǒng)意義上的完全拷貝，而是一系列的規(guī)則進(jìn)行增量的合并。

4、復(fù)制類型

Domino中支持四種不同的復(fù)制方式

拉入推出：是一個(gè)雙向過程。此過程進(jìn)行時(shí)，呼叫服務(wù)器從響應(yīng)服務(wù)器拉入更新，然后向響應(yīng)服務(wù)器推出自己的更新。使用“拉入推出”時(shí)，呼叫服務(wù)器上的 Replicator 任務(wù)執(zhí)行所有的工作。拉入推出是系統(tǒng)缺省的復(fù)制方式。

分別拉入：是兩個(gè)服務(wù)器交換更新的雙向過程。使用“分別拉入”時(shí)，兩個(gè)復(fù)制器（一個(gè)在呼叫服務(wù)器上，另一個(gè)在響應(yīng)服務(wù)器上）共同進(jìn)行復(fù)制工作。

只推出：是呼叫服務(wù)器向響應(yīng)服務(wù)器推出更新的單向過程。單向復(fù)制總是比雙向復(fù)制耗時(shí)少。只拉入：是呼叫服務(wù)器從響應(yīng)服務(wù)器拉入更新的單向過程。單向復(fù)制總是比雙向復(fù)制耗時(shí)少。

三、案例

筆者曾經(jīng)參與呼和浩特鐵路局客運(yùn)公司辦公自動(dòng)化系統(tǒng)的設(shè)計(jì)、開發(fā)和實(shí)施工作。呼和浩特鐵路局客運(yùn)公司包括三個(gè)信息中心，分別在呼和浩特市、包頭市和東河區(qū)三個(gè)地方，三地之間通過64K的DDN專線連接。因?yàn)閹挼南拗?，用戶遠(yuǎn)程訪問速度成為本系統(tǒng)的瓶頸，經(jīng)過再三論證，我們決定構(gòu)建分布式數(shù)據(jù)庫存儲(chǔ)架構(gòu)，采用后臺(tái)數(shù)據(jù)庫實(shí)時(shí)同步復(fù)制技術(shù)使三個(gè)異地服務(wù)器內(nèi)容一致，將遠(yuǎn)程訪問轉(zhuǎn)化為本地訪問，從而提高終端用戶訪問速度。

詳細(xì)步驟如下。

1、安裝服務(wù)器

在三地信息中心分別安裝Domino服務(wù)器，服務(wù)器的詳細(xì)配置并不復(fù)雜，讀者可以參閱相關(guān)資料，一般情況下按照安裝配置向?qū)牟骄涂梢钥旖菖渲猛戤?。注意三臺(tái)Domino服務(wù)器不要同名，其簡單拓?fù)浣Y(jié)構(gòu)如下：

圖中呼市處于相對(duì)中心的位置，所以呼市和包頭之間，呼市和東河之間分別建立了互推復(fù)制機(jī)制，為了降低網(wǎng)絡(luò)負(fù)擔(dān)和流通環(huán)節(jié)，沒有建立包頭和東河之間的復(fù)制，各地直接通過與呼市同步來保持三地?cái)?shù)據(jù)的一致。一般而言，如果各分支機(jī)構(gòu)處于平等位置，互相之間的數(shù)據(jù)流量相當(dāng)，也可以兩兩之間建立復(fù)制機(jī)制。

2、建立服務(wù)器之間的連接

對(duì)于兩個(gè)服務(wù)器之間進(jìn)行的復(fù)制，應(yīng)創(chuàng)建一個(gè)“連接”文檔來指定進(jìn)行信息交換的方式和時(shí)間。“連接”文檔存儲(chǔ)在“Domino 目錄”中。一次僅使用一個(gè)“連接”文檔來處理每對(duì)服務(wù)器之間的所有復(fù)制。創(chuàng)建不必要的“連接”文檔會(huì)增加網(wǎng)絡(luò)傳輸量和阻塞。

缺省情況下，郵件路由和復(fù)制都已被啟用，但是可以更改此設(shè)置并使用單獨(dú)的“連接”文檔來安排每項(xiàng)任務(wù)。這樣，就可以分別控制復(fù)制和郵件路由的特定時(shí)間、時(shí)間范圍或重復(fù)間隔，并根據(jù)需要增加或減小這些設(shè)置。

怎么保證服務(wù)器之間的連接能順利的連通？實(shí)際上對(duì)于物理連接形式Domino并不關(guān)心，也就是說物理上無論通過什么連接方式，專線、光纖、X.25、電話撥號(hào)等，只要TCP/IP通，簡單說只要能Ping通，就能夠保證服務(wù)器之間順利連接。

下面給出了建立服務(wù)器之間連接的操作步驟和主要參數(shù)的設(shè)置說明：

A）在 Domino Administrator 中單擊“配置”附簽。

B）在“使用目錄”域中選擇連接服務(wù)器的“Domino 目錄”。

C）單擊“服務(wù)器”，然后單擊“連接”。

D）單擊“添加連接”。

F）關(guān)鍵域配置描述：

域輸入

源服務(wù)器連接服務(wù)器的名稱

使用以下端口連接服務(wù)器或源服務(wù)器使用的網(wǎng)絡(luò)端口（或協(xié)議）名稱

使用優(yōu)先級(jí)選擇一個(gè)：“一般”（缺?。暗汀?/p>

目標(biāo)服務(wù)器響應(yīng)服務(wù)器的名稱

可選網(wǎng)絡(luò)地址與所選協(xié)議相適應(yīng)的目標(biāo)服務(wù)器的地址。對(duì)于 TCP/IP，應(yīng)使用完全有效的網(wǎng)絡(luò)域名稱（首選）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

對(duì) TCP/IP 或其他需要特定網(wǎng)絡(luò)地址的協(xié)議，建議填寫此域。

復(fù)制類型缺省情況下，Domino 的復(fù)制方向?yàn)椤袄胪瞥觥?。但根?jù)實(shí)際情況，為了平衡服務(wù)器之間的負(fù)載，充分發(fā)揮每個(gè)服務(wù)器的性能，我們可以設(shè)定雙方互推或者互拉，本例中我們采用服務(wù)器雙方互推的方式，即每個(gè)服務(wù)器上的連接復(fù)制類型都是由源服務(wù)器向目標(biāo)服務(wù)器推出。

復(fù)制文件/目錄如果為空，則服務(wù)器將DATA目錄下的所有存在復(fù)本的數(shù)據(jù)庫全部進(jìn)行復(fù)制，否則填寫哪個(gè)庫系統(tǒng)就復(fù)制哪個(gè)庫。

安排在安排中可以設(shè)置連接時(shí)間、重復(fù)間隔、每周復(fù)制日期等參數(shù)?？筛鶕?jù)實(shí)際情況設(shè)定，本例設(shè)置為每日8：00到晚上10：00連接，連接期間每一小時(shí)進(jìn)行同步復(fù)制或服務(wù)器依據(jù)增量自動(dòng)復(fù)制，非連接時(shí)間服務(wù)器處理其他性能調(diào)優(yōu)動(dòng)作，如更新數(shù)據(jù)庫索引等。

H）保存文檔。

3、建立數(shù)據(jù)庫復(fù)本

連接建立成功以后，保證服務(wù)器之間可以進(jìn)行通訊了，下一步就是對(duì)要進(jìn)行同步的數(shù)據(jù)庫建立復(fù)本，當(dāng)建立了復(fù)本以后，通過連接設(shè)定就能保證異地各個(gè)復(fù)本之間的數(shù)據(jù)完全一致。

這里需要說明的是，我們?cè)诘谝慌_(tái)服務(wù)器上建立了一套數(shù)據(jù)庫系統(tǒng)，對(duì)于需要同步復(fù)制的所有數(shù)據(jù)庫，在其他服務(wù)器上只需要產(chǎn)生他們的復(fù)本，而不能再在每臺(tái)服務(wù)器上分別創(chuàng)建相同的數(shù)據(jù)庫。在本例中我們?cè)诤羰锌瓦\(yùn)公司信息中心安裝配置好第一臺(tái)服務(wù)器后，在包頭信息中心和東河信息中心的Domino服務(wù)器上則通過呼市信息中心服務(wù)器建立各自本地所有需要的數(shù)據(jù)庫復(fù)本。

如果要在本地Domino服務(wù)器上創(chuàng)建源Domino服務(wù)器的復(fù)本數(shù)據(jù)庫，需要本地服務(wù)器的系統(tǒng)管理員具有對(duì)源服務(wù)器訪問和創(chuàng)建復(fù)本的權(quán)限，因?yàn)镈omino對(duì)權(quán)限控制很嚴(yán)格，尤其是多域用戶之間的訪問，其目的就是為了充分保證系統(tǒng)的安全性。那么怎樣才能具有這樣的創(chuàng)建復(fù)本的權(quán)限呢？需要具有兩個(gè)基本的存取權(quán)限就可以在本服務(wù)器上創(chuàng)建源服務(wù)器的數(shù)據(jù)庫復(fù)本，一是源服務(wù)器配置中允許本地服務(wù)器的系統(tǒng)管理員訪問，二是允許本地服務(wù)器的系統(tǒng)管理員創(chuàng)建數(shù)據(jù)庫復(fù)本，這兩個(gè)權(quán)限由源數(shù)據(jù)庫的系統(tǒng)管理員設(shè)置給目標(biāo)數(shù)據(jù)庫的系統(tǒng)管理員。結(jié)合本例，需要在包頭信息中心的服務(wù)器上建立呼市信息中心的數(shù)據(jù)庫復(fù)本，則首先在呼市信息中心的服務(wù)器上配置“當(dāng)前服務(wù)器”文檔。

A）在 Domino Administrator 中單擊“當(dāng)前服務(wù)器”文檔。

B）單擊“編輯服務(wù)器”

C）選擇“安全”標(biāo)簽頁，填寫以下兩項(xiàng)：

域輸入

訪問服務(wù)器本例為包頭信息中心系統(tǒng)服務(wù)器名稱及管理員的用戶名稱

創(chuàng)建數(shù)據(jù)庫復(fù)本同樣是包頭信息中心系統(tǒng)管理員的用戶名稱

D保存后退出。

接下來就可以在包頭信息中心的服務(wù)器上創(chuàng)建源數(shù)據(jù)庫的復(fù)本了，這步動(dòng)作比較簡單，選擇源數(shù)據(jù)庫，從菜單中執(zhí)行創(chuàng)建復(fù)本功能即可，這里不在詳細(xì)描述。

同樣的處理在東河的服務(wù)器上如法炮制一遍，則所有數(shù)據(jù)庫復(fù)本成功建立完畢。

4、復(fù)制測試

完成以上三步，配置就全部完成，接下來就要測試一下配置是否完全成功以及配置是否生效。我們測試主要包括兩個(gè)內(nèi)容：一是測試連接是否成功，能否進(jìn)行復(fù)制動(dòng)作。二是測試設(shè)置的復(fù)制安排是否按照預(yù)定生效。

A）進(jìn)行第一項(xiàng)測試的辦法是在Domino的控制臺(tái)上，使用Domino的系統(tǒng)命令，進(jìn)行數(shù)據(jù)庫的推、拉測試，檢查復(fù)制是否能成功進(jìn)行，命令格式如下：

拉入復(fù)制

語法：Pull servername [databasename]

描述：強(qiáng)制從指定服務(wù)器到本地服務(wù)器進(jìn)行單向復(fù)制。通過在命令行中包括單個(gè)數(shù)據(jù)庫名稱，將其從特定服務(wù)器單向復(fù)制到本地服務(wù)器。發(fā)起復(fù)制的服務(wù)器從指定的服務(wù)器接受數(shù)據(jù)，但不能申請(qǐng)將自己的數(shù)據(jù)復(fù)制到其他服務(wù)器上。該命令重設(shè)在“Domino 目錄”中預(yù)定的任何復(fù)制，而強(qiáng)制一臺(tái)服務(wù)器與發(fā)起復(fù)制的服務(wù)器立即進(jìn)行復(fù)制。如果可能，請(qǐng)輸入服務(wù)器完整的層次結(jié)構(gòu)名稱。

推出復(fù)制

語法：Push servername [databasename]

描述：強(qiáng)制進(jìn)行從本地服務(wù)器到指定服務(wù)器的單向復(fù)制。也可以通過在命令行中包括要復(fù)制的單個(gè)數(shù)據(jù)庫名稱，來將其從本地服務(wù)器單向復(fù)制到特定服務(wù)器。發(fā)起復(fù)制的服務(wù)器將數(shù)據(jù)發(fā)送到指定的服務(wù)器，但不申請(qǐng)獲得數(shù)據(jù)。該命令可以重設(shè)在“Domino 目錄”中預(yù)定的任何復(fù)制，而強(qiáng)制一臺(tái)服務(wù)器立即與發(fā)起復(fù)制的服務(wù)器進(jìn)行復(fù)制。如果可能的話，請(qǐng)指定服務(wù)器完整的層次結(jié)構(gòu)名稱。

B）第二項(xiàng)測試通過將連接文檔的安排時(shí)間設(shè)置為兩分鐘進(jìn)行一次，同時(shí)觀察Domino的系統(tǒng)控制臺(tái)，查看服務(wù)器的動(dòng)作，以確保安排設(shè)定生效。正確的結(jié)果是從控制臺(tái)上能看到系統(tǒng)報(bào)告復(fù)制過程。

按照以上實(shí)例說明進(jìn)行，沒有任何問題。

四、結(jié)束語

我們同樣可以在客戶端利用復(fù)制技術(shù)，例如在本地客戶端建立郵件文件數(shù)據(jù)庫的復(fù)本，以便與我們?cè)谕獬龌蛘呙摍C(jī)狀態(tài)下還可以訪問郵件文件。本地復(fù)本要求沒有在服務(wù)器之間進(jìn)行復(fù)制的要求那么高，本地復(fù)本的作用體現(xiàn)在通過本地復(fù)本，可以在沒有通過網(wǎng)絡(luò)連接服務(wù)器時(shí)對(duì)數(shù)據(jù)庫進(jìn)行操作。當(dāng)設(shè)置 Notes 為遠(yuǎn)程工作站時(shí)，就可以通過調(diào)制解調(diào)器呼叫服務(wù)器并在本地復(fù)本和服務(wù)器數(shù)據(jù)庫之間交換更新信息。

第四篇：網(wǎng)絡(luò)存儲(chǔ)技術(shù)優(yōu)缺點(diǎn)與發(fā)展趨勢

網(wǎng)絡(luò)存儲(chǔ)技術(shù)優(yōu)缺點(diǎn)與發(fā)展趨勢

隨著不斷加速的信息需求使得存儲(chǔ)容量飛速增長，存儲(chǔ)系統(tǒng)網(wǎng)絡(luò)平臺(tái)已經(jīng)成為一個(gè)核心平臺(tái)，同時(shí)各種應(yīng)用對(duì)平臺(tái)的要求也越來越高，不僅在存儲(chǔ)容量上，還包括數(shù)據(jù)訪問性能、數(shù)據(jù)傳輸性能、數(shù)據(jù)管理能力、存儲(chǔ)擴(kuò)展能力等等多個(gè)方面?？梢哉f，存儲(chǔ)網(wǎng)絡(luò)平臺(tái)的綜合性能的優(yōu)劣，將直接影響到整個(gè)系統(tǒng)的正常運(yùn)行。因此，發(fā)展一種具有成本效益的和可管理的先進(jìn)存儲(chǔ)方式就成為必然。下面就當(dāng)前的存儲(chǔ)技術(shù)及發(fā)展趨勢進(jìn)行分析和探討。信息量的飛速發(fā)展使得存儲(chǔ)容量也飛速增長，發(fā)展一種具有成本效益和可管理和先進(jìn)存儲(chǔ)方式就成為必然。本文就幾種傳統(tǒng)的網(wǎng)絡(luò)存儲(chǔ)框架進(jìn)行探討，之后介紹了新的存儲(chǔ)技術(shù)，并分析了網(wǎng)絡(luò)存儲(chǔ)體系結(jié)構(gòu)的發(fā)展趨勢。

隨著不斷加速的信息需求使得存儲(chǔ)容量飛速增長，存儲(chǔ)系統(tǒng)網(wǎng)絡(luò)平臺(tái)已經(jīng)成為一個(gè)核心平臺(tái)，同時(shí)各種應(yīng)用對(duì)平臺(tái)的要求也越來越高，不僅在存儲(chǔ)容量上，還包括數(shù)據(jù)訪問性能、數(shù)據(jù)傳輸性能、數(shù)據(jù)管理能力、存儲(chǔ)擴(kuò)展能力等等多個(gè)方面。可以說，存儲(chǔ)網(wǎng)絡(luò)平臺(tái)的綜合性能的優(yōu)劣，將直接影響到整個(gè)系統(tǒng)的正常運(yùn)行。因此，發(fā)展一種具有成本效益的和可管理的先進(jìn)存儲(chǔ)方式就成為必然。下面就當(dāng)前的存儲(chǔ)技術(shù)及發(fā)展趨勢進(jìn)行分析和探討。

一、網(wǎng)絡(luò)存儲(chǔ)技術(shù)概述

所謂網(wǎng)絡(luò)存儲(chǔ)技術(shù)(Network Storage Technologies)，就是以互聯(lián)網(wǎng)為載體實(shí)現(xiàn)數(shù)據(jù)的傳輸與存儲(chǔ)，數(shù)據(jù)可以在遠(yuǎn)程的專用存儲(chǔ)設(shè)備上，也可以是通過服務(wù)器來進(jìn)行存儲(chǔ)。網(wǎng)絡(luò)存儲(chǔ)技術(shù)是基于數(shù)據(jù)存儲(chǔ)的一種通用網(wǎng)絡(luò)術(shù)語。實(shí)際上，我們可以將存儲(chǔ)技術(shù)分為三個(gè)階段：①總線存儲(chǔ)階段；②存儲(chǔ)網(wǎng)絡(luò)階段；③虛擬存儲(chǔ)階段。以存儲(chǔ)網(wǎng)絡(luò)為中心的存儲(chǔ)是對(duì)數(shù)據(jù)存儲(chǔ)新需求的回答。它采用面向網(wǎng)絡(luò)的存儲(chǔ)體系結(jié)構(gòu)，使數(shù)據(jù)處理和數(shù)據(jù)存儲(chǔ)分離；網(wǎng)絡(luò)存儲(chǔ)體系結(jié)構(gòu)包括了網(wǎng)絡(luò)和I/O的精華，將I/O能力擴(kuò)展到網(wǎng)絡(luò)上，特別是靈活的網(wǎng)絡(luò)尋址能力，遠(yuǎn)距離數(shù)據(jù)傳輸能力，I/O高效的原性能；通過網(wǎng)絡(luò)連接服務(wù)器和存儲(chǔ)資源，消除了不同存儲(chǔ)設(shè)備和服務(wù)器之間的連接障礙；提高了數(shù)據(jù)的共享性、可用性和可擴(kuò)展性、管理性。

二、幾種傳統(tǒng)的網(wǎng)絡(luò)存儲(chǔ)架構(gòu)

網(wǎng)絡(luò)存儲(chǔ)架構(gòu)大致分為三種：直連附加存儲(chǔ)、網(wǎng)絡(luò)附加存儲(chǔ)、存儲(chǔ)區(qū)域網(wǎng)絡(luò)。這幾種網(wǎng)絡(luò)存儲(chǔ)方式特點(diǎn)各異，應(yīng)用在不同的領(lǐng)域。下面我們來做簡單的介紹并分析其中區(qū)別。

2.1 直連附加存儲(chǔ)(DAS：Direct Attached Storage)

直接網(wǎng)絡(luò)存儲(chǔ)(DAS)是指將存儲(chǔ)設(shè)備通過SCSI接口或光纖通道直接連接到服務(wù)器上的方式。這種連接方式主要應(yīng)用于單機(jī)或兩臺(tái)主機(jī)的集群環(huán)境中，主要優(yōu)點(diǎn)是存儲(chǔ)容量擴(kuò)展的實(shí)施簡單，投入成本少，見效快。DAS主要應(yīng)用于：

①服務(wù)器在地理分布上很分散，SAN或NAS在它們之間進(jìn)行互連非常困難時(shí)；

②存儲(chǔ)系統(tǒng)必須被直接連接到應(yīng)用服務(wù)器時(shí)；

③包括許多數(shù)據(jù)庫應(yīng)用和應(yīng)用服務(wù)器在內(nèi)的應(yīng)用時(shí)。

缺點(diǎn)：

①不能提供跨平臺(tái)的文件共享功能；

②用戶要備份數(shù)據(jù)和存儲(chǔ)數(shù)據(jù)，都要占用服務(wù)器CPU的時(shí)間，降低了服務(wù)器的管理效能；

③由于各個(gè)主機(jī)之間的數(shù)據(jù)獨(dú)立，數(shù)據(jù)需要逐一備份，使數(shù)據(jù)備份工作較為困難；

④隨著服務(wù)器的增多，數(shù)據(jù)管理會(huì)越來越復(fù)雜；增加存儲(chǔ)設(shè)備，擴(kuò)展存儲(chǔ)容量，需要對(duì)服務(wù)器進(jìn)行重新配置，這樣做容易中斷單位的業(yè)務(wù)連接性，造成數(shù)據(jù)丟失。

2.2 網(wǎng)絡(luò)附加存儲(chǔ)(NAS：Network Attached Storage)

網(wǎng)絡(luò)附加存儲(chǔ)(NAS)是一種將分布、獨(dú)立的數(shù)據(jù)整合為大型、集中化管理的數(shù)據(jù)中心，以便于對(duì)不同主機(jī)和應(yīng)用服務(wù)器進(jìn)行訪問的技術(shù)。NAS中服務(wù)器與存儲(chǔ)之間的通信使用TCP/IP協(xié)議，數(shù)據(jù)處理是“文件級(jí)”。NAS可附加大容量的存儲(chǔ)內(nèi)嵌操作系統(tǒng)，專門針對(duì)文件系統(tǒng)進(jìn)行重新設(shè)計(jì)和優(yōu)化以提供高效率的文件服務(wù)，降低了存儲(chǔ)設(shè)備的成本，數(shù)據(jù)傳輸速率也很高。

NAS應(yīng)用于電子出版、CAD、圖像、教育、銀行、政府、法律環(huán)境等那些對(duì)數(shù)據(jù)量有較大需求的應(yīng)用中。多媒體、Internet下載以及在線數(shù)據(jù)的增長，特別是那些要求存儲(chǔ)器能隨著公司文件大小規(guī)模而增長的企業(yè)、小型公司、大型組織的部門網(wǎng)絡(luò)，更需要這樣一個(gè)簡單的可擴(kuò)展的方案。

缺點(diǎn)：

①NAS采用File I/O方式，因此當(dāng)客戶端數(shù)目或來自客戶端的請(qǐng)求較多時(shí)，NAS服務(wù)器仍將成為系統(tǒng)的瓶頸；

②進(jìn)行數(shù)據(jù)備份時(shí)需要占用LAN的帶寬，造成資源浪費(fèi)；

③NAS只能對(duì)單個(gè)存儲(chǔ)(單個(gè)NAS內(nèi)部)設(shè)備中的磁盤進(jìn)行資源整合，目前還無法跨越不同的NAS設(shè)備，只能進(jìn)行單獨(dú)管理，不適合密集型大規(guī)模的數(shù)據(jù)傳輸。

2.3 存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN：Storage Area Network)

SAN(Storage Area Network，存儲(chǔ)區(qū)域網(wǎng))，通常SAN由RAID陣列連接光纖通道(Fibre Channel)組成，SAN和服務(wù)器以及客戶機(jī)的數(shù)據(jù)通信通過SCSI命令而非TCP/IP，數(shù)據(jù)處理是“塊級(jí)”。

應(yīng)用：

①數(shù)據(jù)共享由于存儲(chǔ)設(shè)備的中心化，大量的文件服務(wù)器可以低成本的存取和共享信息，同時(shí)也不會(huì)使系統(tǒng)性能有明顯下降；

②存儲(chǔ)共享兩個(gè)或多個(gè)服務(wù)器可以共享一個(gè)存儲(chǔ)單元，這個(gè)存儲(chǔ)單元在物理上可以被分成多個(gè)部分，而每個(gè)部分又連接在特定的服務(wù)器上；

③數(shù)據(jù)備份通過使用SAN，這些操作可以獨(dú)立于原來的網(wǎng)絡(luò)，從而能夠提高操作的性能；

④災(zāi)難恢復(fù)傳統(tǒng)方法，當(dāng)災(zāi)難發(fā)生時(shí)，使用磁帶實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。通過使用SAN，可采用多種手段實(shí)現(xiàn)數(shù)據(jù)的自動(dòng)備份，而且這種備份是熱備份形式，也就是說，一旦數(shù)據(jù)出錯(cuò)，立即可以獲得該數(shù)據(jù)的鏡像內(nèi)容。

三、新的網(wǎng)絡(luò)存儲(chǔ)技術(shù)IP—SAN

網(wǎng)絡(luò)存儲(chǔ)的發(fā)展產(chǎn)生了一種新技術(shù)IP—SANt。IP—SAN是以IP為基礎(chǔ)的SAN存儲(chǔ)方案，是IP存儲(chǔ)技術(shù)應(yīng)用的第三階段，是完全的端到端的、基于IP的全球SAN存儲(chǔ)。它充分利用了IP網(wǎng)絡(luò)的技術(shù)成熟、性能穩(wěn)定、傳輸距離遠(yuǎn)、安裝實(shí)施簡單、后期維護(hù)量少的特點(diǎn)，可為用戶提供一個(gè)運(yùn)行穩(wěn)定、實(shí)施簡單方便、價(jià)格低廉的大容量存儲(chǔ)系統(tǒng)，是一種可共同使用SAN與NAS，并遵循各項(xiàng)標(biāo)準(zhǔn)的純軟件解決方案。IP—SAN可讓用戶同時(shí)使用GigabitEtherne SCSI與Fibre Channel，建立以IP為基礎(chǔ)的網(wǎng)絡(luò)存儲(chǔ)基本架構(gòu)，由于IP在局域網(wǎng)和廣域網(wǎng)上的應(yīng)用以及良好的技術(shù)支持，在IP網(wǎng)絡(luò)中也可實(shí)現(xiàn)遠(yuǎn)距離的塊級(jí)存儲(chǔ)，以IP協(xié)議替代光纖通道協(xié)議，IP協(xié)議用于網(wǎng)絡(luò)中實(shí)現(xiàn)用戶和服務(wù)器連接，隨著用于執(zhí)行1P協(xié)議的計(jì)算機(jī)的速度的提高及G比特的以太網(wǎng)的出現(xiàn)，基于IP協(xié)議的存儲(chǔ)網(wǎng)絡(luò)實(shí)現(xiàn)方案成為SAN的更佳選擇。

四、虛擬存儲(chǔ)

所謂虛擬存儲(chǔ)，就是把內(nèi)存與外存有機(jī)的結(jié)合起來使用，從而得到一個(gè)容量很大的“內(nèi)存”。以存儲(chǔ)網(wǎng)絡(luò)為中心的存儲(chǔ)解決不了全部的數(shù)據(jù)存儲(chǔ)問題，如存儲(chǔ)資源共享、數(shù)據(jù)共享、數(shù)據(jù)融合等。不少先進(jìn)存儲(chǔ)系統(tǒng)的倡導(dǎo)者都提出，存儲(chǔ)作為一種資源，應(yīng)該像我們?nèi)粘Ｉ钪械淖詠硭碗娏σ粯樱S時(shí)可以方便的存取和使用，這就是存儲(chǔ)公用設(shè)施模型，也是網(wǎng)絡(luò)存儲(chǔ)的發(fā)展目標(biāo)。實(shí)現(xiàn)存儲(chǔ)公用設(shè)施模型的關(guān)鍵就是在網(wǎng)絡(luò)存儲(chǔ)基礎(chǔ)上實(shí)現(xiàn)統(tǒng)一虛擬存儲(chǔ)系統(tǒng)。目前存儲(chǔ)技術(shù)還處于存儲(chǔ)網(wǎng)絡(luò)階段，虛擬存儲(chǔ)才剛剛起步。

五、云存儲(chǔ)

云存儲(chǔ)是在云計(jì)算(Cloud computing)概念上延伸和發(fā)展出來的一個(gè)新的概念。云計(jì)算是是分布式處理(Distributed Computing)、并行處理(Parallel Computing)和網(wǎng)格計(jì)算(Grid Computing)的發(fā)展，是透過網(wǎng)絡(luò)將龐大的計(jì)算處理程序自動(dòng)分拆成無數(shù)個(gè)較小的子程序，再交由多部服務(wù)器所組成的龐大系統(tǒng)經(jīng)計(jì)算分析之后將處理結(jié)果回傳給用戶。

云存儲(chǔ)的概念與云計(jì)算類似，它是指通過集群應(yīng)用、網(wǎng)格技術(shù)或分布式文件系統(tǒng)等功能，將網(wǎng)絡(luò)中大量各種不同類型的存儲(chǔ)設(shè)備通過應(yīng)用軟件集合起來協(xié)同工作，共同對(duì)外提供數(shù)據(jù)存儲(chǔ)和業(yè)務(wù)訪問功能的一個(gè)系統(tǒng)。云存儲(chǔ)的核心是應(yīng)用軟件與存儲(chǔ)設(shè)備相結(jié)合，通過應(yīng)用軟件來實(shí)現(xiàn)存儲(chǔ)設(shè)備向存儲(chǔ)服務(wù)的轉(zhuǎn)變。

云存儲(chǔ)對(duì)使用者來講，不是指某一個(gè)具體的設(shè)備，而是指一個(gè)由許許多多個(gè)存儲(chǔ)設(shè)備和服務(wù)器所構(gòu)成的集合體。用戶使用云存儲(chǔ)，并不是使用某一個(gè)存儲(chǔ)設(shè)備，而是使用整個(gè)云存儲(chǔ)系統(tǒng)帶來的一種數(shù)據(jù)訪問服務(wù)。所以嚴(yán)格來講，云存儲(chǔ)不是存儲(chǔ)，而是一種服務(wù)。

六、結(jié)束語

數(shù)據(jù)的重要性越來越得到人們的廣泛認(rèn)同，未來網(wǎng)絡(luò)的核心將是數(shù)據(jù)，網(wǎng)絡(luò)化存儲(chǔ)正是數(shù)據(jù)存儲(chǔ)的一個(gè)發(fā)展方向。目前網(wǎng)絡(luò)存儲(chǔ)技術(shù)沿著三個(gè)主要的方向發(fā)展：NAS、SAN、IP—SAN。而SAN和NAS的融合將更有利于數(shù)據(jù)的存儲(chǔ)和備份，因此，SAN和NAS的融合、統(tǒng)一虛擬存儲(chǔ)技術(shù)是未來網(wǎng)絡(luò)存儲(chǔ)技術(shù)發(fā)展的兩個(gè)趨勢。

第五篇：數(shù)據(jù)庫技術(shù)與應(yīng)用課程設(shè)計(jì)

? 數(shù)據(jù)庫技術(shù)與應(yīng)用課程設(shè)計(jì)

一、課程設(shè)計(jì)的教學(xué)目的

1、使學(xué)生掌握數(shù)據(jù)庫的基本概念，結(jié)合實(shí)際的操作和設(shè)計(jì)，鞏固課堂教學(xué)內(nèi)容；

2、使學(xué)生掌握數(shù)據(jù)庫系統(tǒng)的基本概念、原理和技術(shù)，將理論與實(shí)際相結(jié)合，應(yīng)用現(xiàn)有的數(shù)據(jù)建模工具和數(shù)據(jù)庫管理系統(tǒng)軟件，規(guī)范、科學(xué)地完成一個(gè)小型數(shù)據(jù)庫的設(shè)計(jì)與實(shí)現(xiàn)

3、把理論課與實(shí)驗(yàn)課所學(xué)內(nèi)容做一綜合，并在此基礎(chǔ)上強(qiáng)化學(xué)生的實(shí)踐意識(shí)、提高其實(shí)際動(dòng)手能力。

一、課程設(shè)計(jì)的任務(wù)：

使用現(xiàn)行教流行的開發(fā)工具和SQL Server進(jìn)行數(shù)據(jù)庫應(yīng)用的開發(fā)，主要完成：

1、創(chuàng)建所用的數(shù)據(jù)庫，創(chuàng)建所需要的表并設(shè)置好整性約束。

2、開發(fā)出有相當(dāng)完善功能并有一定規(guī)模的數(shù)據(jù)庫應(yīng)用系統(tǒng)，系統(tǒng)中要能實(shí)現(xiàn)對(duì)數(shù)據(jù)的插入、刪除、修改、簡單查詢、復(fù)雜查詢、數(shù)據(jù)的統(tǒng)計(jì)等。?

三、數(shù)據(jù)庫課程設(shè)計(jì)內(nèi)容及要求

1、設(shè)計(jì)內(nèi)容：

? 選題：按自由組合原則，以1-2人一組，每一組從所給題目中任選一個(gè)合作完成，并且一個(gè)題目只能由一個(gè)組選作。

? 系統(tǒng)的開發(fā)與實(shí)現(xiàn)：對(duì)所選課題進(jìn)行調(diào)查研究，完成系統(tǒng)的功能分析、結(jié)構(gòu)設(shè)計(jì)、數(shù)據(jù)庫的概念要設(shè)計(jì)和邏輯結(jié)構(gòu)設(shè)計(jì)、數(shù)據(jù)庫的物理實(shí)現(xiàn)、用戶界面設(shè)計(jì)等，最后采用程序開發(fā)工具（C#、Java、VC、VB、Delphi、ASP等）完成系統(tǒng)開發(fā)。

2、設(shè)計(jì)要求

（1）采取課內(nèi)上機(jī)和業(yè)余上機(jī)相結(jié)合的方式進(jìn)行，合理安排設(shè)計(jì)進(jìn)度（可按以下建議的進(jìn)度進(jìn)行），在規(guī)定時(shí)間內(nèi)完成系統(tǒng)的開發(fā)和設(shè)計(jì)報(bào)告的編寫。

（2）提交比較詳細(xì)的課程設(shè)計(jì)報(bào)告和設(shè)計(jì)作品。

A、課程設(shè)計(jì)報(bào)告至少2000字以上（原代碼除外），報(bào)告所包含的內(nèi)容及格式見《數(shù)據(jù)庫原理——課程設(shè)計(jì)指導(dǎo)書》

B、所開的數(shù)據(jù)庫應(yīng)用系統(tǒng)應(yīng)具有可運(yùn)行、功能較完整、界面較美觀、操作較方便等特點(diǎn)。

C、每位同學(xué)至少完成所選課題設(shè)計(jì)工作量的50% ?

四、設(shè)計(jì)方法與設(shè)計(jì)過程

1、設(shè)計(jì)方法 1）學(xué)習(xí)研究課程設(shè)計(jì)指導(dǎo)書，確定設(shè)計(jì)題目

2）確定開發(fā)目標(biāo)及初步方案；選擇、準(zhǔn)備及試用開發(fā)開發(fā)平臺(tái)。

3）學(xué)習(xí)與搜集素材，借閱、購置必要的書籍與材料：根據(jù)自己承擔(dān)的任務(wù)利用各種途徑（圖書館、因特網(wǎng)、書店、同學(xué)親友等）進(jìn)行針對(duì)性的學(xué)習(xí)并收集相關(guān)素材，包括精選、購置必要的書籍。

2、設(shè)計(jì)步驟：

（1）需求分析：根據(jù)設(shè)計(jì)任務(wù)書的要求，查閱資料，對(duì)系統(tǒng)進(jìn)行功能分析和數(shù)據(jù)分析。

（2）數(shù)據(jù)庫概念結(jié)構(gòu)設(shè)計(jì)：設(shè)計(jì)系統(tǒng)的E-R模型，描述實(shí)體的屬性和實(shí)體之間的聯(lián)系，消除不必要的冗余。

（3）數(shù)據(jù)庫邏輯結(jié)構(gòu)設(shè)計(jì)：實(shí)現(xiàn)E-R圖向關(guān)系模型的轉(zhuǎn)換，優(yōu)化數(shù)據(jù)模型。（4）數(shù)據(jù)庫的物理實(shí)現(xiàn)：創(chuàng)建數(shù)據(jù)庫、表、視圖等，并設(shè)計(jì)表的完整性約束。（4）應(yīng)用程序開發(fā) ：創(chuàng)建新的工程——連接數(shù)據(jù)庫——編寫程序代碼 ?

五、SQLSERVER數(shù)據(jù)庫課程設(shè)計(jì)時(shí)間 SQLSERVER數(shù)據(jù)庫課程設(shè)計(jì)時(shí)間為一周，具體安排如下： ?

六、課程設(shè)計(jì)交付成果說明(1)個(gè)人報(bào)告： 每個(gè)學(xué)生提交個(gè)人課程設(shè)計(jì)報(bào)告(A4打印稿，原代碼除外至少2000字以上，不少于20頁)。

（2）軟件與電子文檔：把完成的所有文檔（設(shè)計(jì)文檔、設(shè)計(jì)報(bào)告及程序）一并交由指導(dǎo)老師處。

? 注：文檔目錄按照如下統(tǒng)一命名規(guī)則建立，“課題名/個(gè)人子目錄名”，比如“圖書管理系統(tǒng)/張三/張三_課程設(shè)計(jì)報(bào)告”。? 考核方式與成績?cè)u(píng)定標(biāo)準(zhǔn)

? 考核方式：考察平時(shí)表現(xiàn)，注重設(shè)計(jì)結(jié)果演示和實(shí)習(xí)報(bào)告的書寫 ? 評(píng)定內(nèi)容：設(shè)計(jì)結(jié)果和設(shè)計(jì)報(bào)告 ? 教材及主要參考資料

[1]張莉 《SQL SEVER數(shù)據(jù)庫原理及應(yīng)用 》

[2]薩師煊 王珊著.《數(shù)據(jù)庫系統(tǒng)概論》第三版.高等教育出版社

[3] 施伯樂 丁寶康 汪衛(wèi).《數(shù)據(jù)庫系統(tǒng)教程》 高等教育出版社2003年第2版

[4]莊成三等.《數(shù)據(jù)庫系統(tǒng)原理及其應(yīng)用》.電子工業(yè)出版社 ? 設(shè)計(jì)報(bào)告按照以下提綱書寫 1)摘要。

2)需求分析。

3)數(shù)據(jù)庫概念結(jié)構(gòu)設(shè)計(jì)。

4)數(shù)據(jù)庫邏輯結(jié)構(gòu)設(shè)計(jì)。

5)數(shù)據(jù)流圖及程序結(jié)構(gòu)框圖。

6)程序原代碼及其說明。

7)總結(jié)。

? 課題一：學(xué)生不及格學(xué)分管理系統(tǒng)開發(fā)（1人）

（1）基本信息管理：能夠向數(shù)據(jù)庫中添加、刪除、修改不及格學(xué)生的科目、學(xué)分及成績等記錄。

（2）數(shù)據(jù)查詢：能夠按照查詢條件（學(xué)期、學(xué)生姓名、班級(jí)、不及格科目）查詢?yōu)g覽查詢結(jié)果。

（3）數(shù)據(jù)計(jì)算及統(tǒng)計(jì)：計(jì)算每個(gè)學(xué)生不及格科目，累計(jì)學(xué)分并進(jìn)行降序排列。? 提供數(shù)據(jù)：學(xué)分累計(jì)統(tǒng)計(jì)表

? 課題二：圖書出版管理系統(tǒng)開發(fā)（1-2人）

(1)所出版圖書的信息管理：數(shù)據(jù)錄入、修改和刪除功能；

(2)所出版圖書的查詢與統(tǒng)計(jì)：可以按各種分類方式（如圖書的出版信息、出售信息等）對(duì)出版圖書信息進(jìn)行查詢與統(tǒng)計(jì)(3)系統(tǒng)維護(hù)：如數(shù)據(jù)的備份、用戶的管理等。? 課題三：產(chǎn)品庫存管理系統(tǒng)開發(fā)（１-2人）

1、用戶信息管理：至少三類以上的用戶，不同的用戶對(duì)產(chǎn)品的錄入、修改和刪除具有不同的權(quán)利。

2、產(chǎn)品信息管理：錄入、修改和刪除產(chǎn)品的基本信息，要求：對(duì)產(chǎn)品名稱是否為空進(jìn)行檢驗(yàn)；部份用戶可以修改與刪除產(chǎn)品信息；修改時(shí)，要求先根據(jù)查詢列出滿足條件的產(chǎn)品信息，然后進(jìn)行修改。刪除時(shí)，要先確認(rèn)再進(jìn)行刪除。

3、倉庫信息管理：倉庫基本信息的錄入、修改和刪除。

4、產(chǎn)品庫存管理：產(chǎn)生存儲(chǔ)表，對(duì)每種產(chǎn)品的庫存信息進(jìn)行管理，入庫時(shí)，庫存增加、出庫時(shí)庫存減少。

5、信息查詢與統(tǒng)計(jì)：對(duì)產(chǎn)品的基本信息及庫存信息進(jìn)行單條件與組合條件的查詢與統(tǒng)計(jì)。

? 課題四：職工工資管理系統(tǒng)開發(fā)（１－2人）某單位員工分為管理員、財(cái)務(wù)員、技術(shù)員和銷售員等。該單位下設(shè)經(jīng)理室、財(cái)務(wù)科、技術(shù)科和銷售科4個(gè)科室。工資由基本工資、福利補(bǔ)貼和獎(jiǎng)勵(lì)工資構(gòu)成，失業(yè)保險(xiǎn)和住房公積金在工資中扣除。每個(gè)員工的基本資料有姓名、性別、年齡、單位和職業(yè)（如經(jīng)理、工程師等）。工資按月發(fā)放，1）職工的基本信息管理：錄入、修改與刪除職工信息。2）職工的基本工資管理：錄入、修改與刪除職工工資信息

3）職工的工資計(jì)算：計(jì)算每個(gè)人的實(shí)際發(fā)放工資。實(shí)際發(fā)放的工資金額為工資減去扣除。4）工資的查詢：按職工所在的部門、職工名及職工編號(hào)等條件查詢每個(gè)職工的工資 5）工資的統(tǒng)計(jì)：按科室、職業(yè)分類統(tǒng)計(jì)人數(shù)和工資金額。? 課題五：**市地下水常規(guī)監(jiān)測 信息管理系統(tǒng)開發(fā)（1-2人）

（1）基本信息管理：能夠向數(shù)據(jù)庫中添加、刪除、修改地下水常規(guī)監(jiān)測數(shù)據(jù)。（2）數(shù)據(jù)查詢：能夠按照條件（監(jiān)測點(diǎn)、監(jiān)測因子、監(jiān)測時(shí)間）進(jìn)行查詢；能夠選擇監(jiān)測因子查詢所有該因子超標(biāo)的監(jiān)測點(diǎn)，指定一個(gè)監(jiān)測點(diǎn)判斷該監(jiān)測點(diǎn)所有常規(guī)監(jiān)測因子的狀態(tài)（是否超標(biāo)）

（3）數(shù)據(jù)統(tǒng)計(jì)：能夠按照時(shí)間段等條件對(duì)監(jiān)測數(shù)據(jù)進(jìn)行統(tǒng)計(jì)。? 課題六：商品銷售管理系統(tǒng)開發(fā)（１－2人）(1)用戶管理：用戶的基本信息及權(quán)限的錄入、修改和刪除管理

(2)商品信息管理：商品基本信息錄入、修改和刪除，注意各類完整性約束的設(shè)計(jì)與檢驗(yàn)。

(3)進(jìn)貨信息管理：進(jìn)貨信息的錄入、修改和刪除。

(4)銷售信息管理：商品銷售信息的錄入、修改和刪除管理。

（5）各類信息的查詢：按簡單條件、組合條件及模糊條件對(duì)各類信息進(jìn)行查詢。（6）各類信息的統(tǒng)計(jì)：按簡單條件、組合條件及模糊條件對(duì)各類信息進(jìn)行統(tǒng)計(jì)。? 課題七：電子相冊(cè)管理系統(tǒng)開發(fā)（1人）(1)照片基本信息的管理：照片的上傳、顯示與刪除。（2）照片的瀏覽與查詢：按不同條件實(shí)現(xiàn)對(duì)照片的瀏覽與查詢(3)用戶的管理：不同的用戶對(duì)照片的上傳與查詢等權(quán)限不同。? 課題八：人事管理系統(tǒng)開發(fā)（１－2人）（1）員工信息管理：員工的姓名、性別、工作崗位、所在部門、學(xué)歷、婚姻狀況、專業(yè)、畢業(yè)時(shí)間、學(xué)校、外語情況、職稱等基本信息的錄入、修改與刪除。

（2）企業(yè)工作崗位信息和部門信息管理：企業(yè)中的工作崗位信息和部門信息的錄入、修改與刪除（如轉(zhuǎn)出、辭職、辭退、退休）。

（3）職稱信息的管理：所有職稱的種類、專業(yè)等信息的錄入、修改與刪除。（4）職工的檔案管理：對(duì)職工檔案信息的錄入、修改與刪除。（4）信息的查詢：對(duì)各類信息按不同的條件進(jìn)行查詢。（5）信息的統(tǒng)計(jì)：對(duì)各類信息按不同的條件進(jìn)行統(tǒng)計(jì) ? 課題九：教職工簽到管理系統(tǒng)開發(fā)（1人）

(1)教職工基本信息管理：教職工基本信息的增加、修改與刪除；

(2)教職工簽到管理：教職工輸入編號(hào)后，簽到，系統(tǒng)自動(dòng)記錄其簽到的時(shí)間，并注明是否遲到。

（3）教職工簽到情況的查詢與統(tǒng)計(jì)：按不同的條件對(duì)工簽到情況進(jìn)行查詢與統(tǒng)計(jì)

? 課題十：通訊簿信息管理系統(tǒng)開發(fā)（1人）

(1)地址信息的管理：對(duì)新地址的姓名、性別、家庭住址、手機(jī)、住址電話、辦公電話、電子信箱、個(gè)人簡介、照片等基本信息的錄入，對(duì)原有地址信息的修改與刪除，在修改與刪除時(shí)，應(yīng)先查詢出相關(guān)信息，再進(jìn)行修改與刪除；

(2)地址信息的查詢與統(tǒng)計(jì)：可以按姓名等不同的條件對(duì)地址信息進(jìn)行查詢與統(tǒng)計(jì)；

（3）用戶管理：錄入、修改與刪除用戶信息以及對(duì)用戶授權(quán)的管理。? 課題十一：網(wǎng)上圖書銷網(wǎng)站設(shè)計(jì)與開發(fā)（１－2人）

?(1)圖書信息管理：可以在管理后臺(tái)錄入、修改與刪除圖書的基本信息； ?(2)圖書內(nèi)容簡介管理：錄入、修改與刪除圖書的內(nèi)容簡介；

?（3）圖書內(nèi)容簡介的查詢：可以在前臺(tái)按關(guān)鍵字查詢圖書的內(nèi)容簡介 ?（4）用戶注冊(cè)管理：前臺(tái)提供用戶注冊(cè)界面，后臺(tái)可以對(duì)注冊(cè)的用戶進(jìn)行查詢與刪除，但不能修改用戶的注冊(cè)信息。

?(5)購物車管理：前臺(tái)用戶可以將感興趣的圖書放入購物車，也可以刪除與查詢購物車內(nèi)的圖書；

?(6)各類信息的查詢：學(xué)生自己設(shè)計(jì)按不同條件對(duì)各類信息進(jìn)行查詢與統(tǒng)計(jì)。

?（7）各類信息需要用數(shù)據(jù)庫存儲(chǔ)。? 課題十二：客房管理信息系統(tǒng)開發(fā)（１－2人）

（1）用戶管理：錄入、修改與刪除用戶信息以及對(duì)用戶授權(quán)的管理。(2)客房基本信息的管理：添加、修改、刪除客房的基本信息；

（3）客戶住宿登記信息的管理：添加、修改、刪除客戶住宿登記的基本信息；(4)客戶預(yù)定管理：對(duì)預(yù)定客房的基本信息進(jìn)行管理（5）客戶退房處理：對(duì)退房信息進(jìn)行管理；

(6)各類信息的查詢與統(tǒng)計(jì)：按不同的條件對(duì)各類信息進(jìn)行查詢與統(tǒng)計(jì)。? 課題十三：高校科研管理系統(tǒng)開發(fā)（１－2人）(1)科研人員管理：科研人員基本信息的錄入、修改與刪除。(2)科研項(xiàng)目管理；科研項(xiàng)目基本信息的錄入、修改與刪除。

(3)獲獎(jiǎng)情況管理：對(duì)獲獎(jiǎng)的科研科研成果、科研項(xiàng)目及相關(guān)的科研人員的信息進(jìn)行管理；

(4)科研成果管理：對(duì)科研論文、學(xué)術(shù)著作等科研成果的基本信息進(jìn)行錄入、修改與刪除管理。

(5)學(xué)術(shù)期刊管理：對(duì)各種學(xué)術(shù)期刊的基本信息進(jìn)行錄入、修改與刪除管理。(6)各類信息的查詢與統(tǒng)計(jì)：按不同的條件對(duì)各類信息進(jìn)行查詢與統(tǒng)計(jì)。? 課題十四：旅游管理系統(tǒng)開發(fā)（１－2人）

(1)景點(diǎn)管理：對(duì)各個(gè)景點(diǎn)基本信息的錄入、修改與刪除。(2)導(dǎo)游管理：對(duì)每個(gè)導(dǎo)游的姓名、專業(yè)、所在景點(diǎn)等基本信息的錄入、修改與刪除。

(3)游客管理：對(duì)各個(gè)游客基本信息的錄入、修改與刪除。(4)用戶管理：錄入、修改與刪除用戶信息以及對(duì)用戶授權(quán)的管理。(5)各類信息的查詢：按不同的條件對(duì)各類信息進(jìn)行查詢。（6）各類信息的統(tǒng)計(jì)：按不同的條件對(duì)各類信息進(jìn)行統(tǒng)計(jì)。? 課題十五：民航訂票管理系統(tǒng)開發(fā)（１－2人）（1）航班信息管理：每個(gè)航班基本信息的錄入、修改與刪除。

（2）航班坐位信息管理：每個(gè)航班坐位信息的錄入、修改與刪除。

（3）機(jī)票預(yù)定管理：輸入旅客基本信息，系統(tǒng)為旅客安排航班，打印取票通知和帳單；（4）退訂機(jī)票管理：對(duì)退訂機(jī)票信息進(jìn)行判斷、錄入、修改與刪除。

（5）查詢信息：能夠查詢每個(gè)航班的基本信息、預(yù)定情況、旅客的基本信息等。（6）統(tǒng)計(jì)信息：計(jì)算每個(gè)航班的滿座率，統(tǒng)計(jì)旅客的乘坐次數(shù)數(shù)、乘坐總金額等。

? 課題十六：圖書借閱管理系統(tǒng)開發(fā)（1-2人）（1）讀者信息管理：對(duì)借閱者的借書證號(hào)、姓名、性別、出生日期、身份證號(hào)、聯(lián)系電話、辦證日期、借閱范圍（書庫）、所在單位、職業(yè)等基本信息的錄入、修改與刪除。

（2）圖書基本信息管理：對(duì)每種圖書的書名、書號(hào)（ISBN）、作者（譯者）、出版社、定價(jià)和內(nèi)容簡介等基本信息的錄入、修改與刪除。

（3)借閱管理：借閱者的個(gè)人資料和所借圖書的書名、書號(hào)數(shù)據(jù)等基本信息的錄入、修改與刪除。憑借書證借書，每次最多能借8本書。借書期限最長為60天。輸入借書證號(hào)后，能根據(jù)借書證號(hào)判斷該讀者可以借書的書庫，借書是否超出最大允許借書冊(cè)數(shù)，書庫中是否還有該書可借。

（4）還書管理：對(duì)過期未還圖書進(jìn)行罰款，對(duì)歸還的圖書能從借書登記表中取消，對(duì)丟失的圖書進(jìn)行登記。

（5)對(duì)所有購進(jìn)圖書的分類查詢和分類統(tǒng)計(jì)，能夠按書名、作者等分類查詢現(xiàn)有圖書的數(shù)量。

（6)能根據(jù)書號(hào)、書名、作者、出版單位、內(nèi)容提要關(guān)鍵字、分類號(hào)、索書號(hào)、每冊(cè)圖書館藏注冊(cè)號(hào)等進(jìn)行查詢。

? 課題課題十七：類QQ留言系統(tǒng)開發(fā)（1人）

1、QQ號(hào)基本信息的管理：能夠向數(shù)據(jù)庫中添加、刪除QQ號(hào)記錄，能夠修改記錄中的字段值。

2、能夠按照條件（好友呢稱、QQ號(hào)）留言或?yàn)g覽。

3、能夠按好友呢稱、QQ號(hào)等條件對(duì)QQ號(hào)進(jìn)行查詢 與統(tǒng)計(jì) ? 課題十八：中小學(xué)智能排課系統(tǒng)開發(fā)（１-2人）

? 能根據(jù)教師要求(如某天不得排課)、課程約束(如體育不能排在上午第一節(jié)課)、班級(jí)約束(如某班星期五下午最后一節(jié)課不排課)、校級(jí)約束(如全校所有班級(jí)星期一下午第一節(jié)課都為班會(huì))等信息自動(dòng)為班級(jí)和教師生成課程表，要求主課盡量排在上午和下午一、二節(jié)課，副課盡量排在上午和下午的最后一節(jié)課，如體育課排在上午第一節(jié)課是不太合適的。對(duì)于軟件不能安排的少數(shù)課程，教務(wù)工作者能夠在自動(dòng)排出的課程表上進(jìn)行手工調(diào)課。? 具體要求：

(1)系統(tǒng)可以進(jìn)行兩節(jié)連課處理，如作文課可以連課上；(2)排出的課程表中不允許有教師沖突的情況，比如，一個(gè)教師同時(shí)給兩個(gè)班級(jí)上課是不允許的；

(3)要求課程表中的課程要有所變化，比如一個(gè)班級(jí)的所有數(shù)學(xué)課總是排在上午第一節(jié)課是不好的課程表。

(4)每周上課天數(shù)為5天，每天上課節(jié)數(shù)可以是7節(jié)或是8節(jié)；(5)每個(gè)年級(jí)所開課程是一樣的；(6)一個(gè)教師可以教授多門課程；

(7)系統(tǒng)可以為每個(gè)班級(jí)和每位教師打印課程表；(8)在課表生效后，教師可以要求調(diào)課；

(9)教師數(shù)量是動(dòng)態(tài)的，所開課程的數(shù)量也是動(dòng)態(tài)的。

? 課題十九：學(xué)生學(xué)籍管理信息系統(tǒng)開發(fā)（1人）

(1)學(xué)生檔案的管理，即錄入、修改、查詢、輸出學(xué)生檔案信息，這些信息包括學(xué)生基本情況、學(xué)生簡歷情況、學(xué)生獎(jiǎng)勵(lì)情況、學(xué)生處分情況、學(xué)生家庭信息、學(xué)生體檢情況。

(2)學(xué)生學(xué)籍管理，能夠錄入、修改、查詢、輸出學(xué)生學(xué)籍信息，這些信息包括學(xué)生獎(jiǎng)貸學(xué)金情況、學(xué)生注冊(cè)、學(xué)生異動(dòng)情況、學(xué)生軍訓(xùn)情況、學(xué)生畢業(yè)情況。

(3)學(xué)生成績管理，能夠錄入修改、查詢、輸出學(xué)生入校成績，各學(xué)期、各門課程的成績信息，并支持按年級(jí)、班級(jí)等條件的統(tǒng)計(jì)、查詢、報(bào)表輸出。

? 課題二十：網(wǎng)上訂貨發(fā)貨系統(tǒng)開發(fā)（1-2人）

1）合同管理：合同的合同編號(hào)，客戶的名稱，地址，簽定時(shí)間，帳號(hào)，總金額及產(chǎn)品清單等基本信息的錄入、修改、刪除和查詢。一個(gè)合同可簽訂多種產(chǎn)品，合同簽訂必須為現(xiàn)有的庫存產(chǎn)品，但產(chǎn)品庫存量不夠時(shí)，可允許先簽訂合同；

2）客戶管理：客戶網(wǎng)上注冊(cè)、登錄、修改個(gè)人資料等。

3）發(fā)貨管理：根據(jù)合同簽訂的情況發(fā)貨，不得超出合同簽訂的產(chǎn)品品種，數(shù)量及庫存量；每個(gè)合同的發(fā)貨可分次完成，并保留發(fā)貨的歷史記錄。

4）庫存管理：可完成產(chǎn)品入庫、出庫（合同發(fā)貨）信息的錄入、修改與刪除。5）查詢信息：各類基本信息的分類查詢 6）統(tǒng)計(jì)信息：各類基本信息的分類統(tǒng)計(jì)。

? 課題二十一：超市管理系統(tǒng)開發(fā)（１－2人）1）超市員工信息管理：超市員工的姓名、家庭住址、學(xué)歷、婚姻狀況信息等基本的錄入、修改和刪除； 2）超市貨物信息管理：超市貨物的的名稱，編號(hào)，價(jià)格，生產(chǎn)廠家，庫存量等基本信息的錄入、修改和刪除；

3）銷售情況管理：超市貨物銷售信息的錄入、修改和刪除； 4）用戶管理：用戶基本信息的的錄入、修改和刪除； 5）查詢信息：各類基本信息的分類查詢

6）統(tǒng)計(jì)信息：各類基本信息的分類統(tǒng)計(jì)。

? 課題二十二：教師網(wǎng)上成績錄入系統(tǒng)開發(fā)(１－2人)

1）教師信息的管理：教師的基本信息、所教課程、授課時(shí)間、教師密碼等信息的錄入、修改和刪除；

2）學(xué)生信息的管理：學(xué)生基本信息的錄入、修改和刪除；

3）課程信息的管理：課程基本信息的錄入、修改和刪除；

4）選課信息的管理：生所選課程基本信息的錄入、修改和刪除；

5）成績管理：成績的錄入和修改

6）信息的查詢與統(tǒng)計(jì)：能按不同條件對(duì)各類信息進(jìn)行查詢，能按多個(gè)條件對(duì)成績信息、選課信息等進(jìn)行統(tǒng)計(jì)；

? 課題二十三：網(wǎng)上考試系統(tǒng)開發(fā)(１－2人)1）考生信息管理：考生基本信息的錄入、修改和刪除。

2）試題庫管理：試題庫（試題及答案）基本信息的錄入、修改和刪除。

3）試卷生成：根據(jù)規(guī)則從試題庫抽出試題形成試卷

4）試卷提交：學(xué)生做完題目以后，能夠?qū)ψ约旱拇鸢高M(jìn)行提交，提交以后，信息不能再修改；

5）試卷評(píng)分：對(duì)試卷進(jìn)行自動(dòng)評(píng)分，并記錄試卷分?jǐn)?shù)。學(xué)生將所有題目全部提交以后，能夠查看標(biāo)準(zhǔn)答案與評(píng)分標(biāo)準(zhǔn)。

6）查詢與統(tǒng)計(jì)信息：能對(duì)試卷的難易度、成績等各類基本信息進(jìn)行分類查詢與統(tǒng)計(jì)。

? 課題二十四：網(wǎng)上選課系統(tǒng)開發(fā)(１－2人)（1）學(xué)生信息管理：學(xué)生基本信息的錄入、修改和刪除。

（2）可選課程信息管理：課程的課程號(hào)、課程名、可選專業(yè)及開課學(xué)期學(xué)分等基本信息的錄入、修改和刪除。

（3）學(xué)生選課：學(xué)生登錄后，根據(jù)學(xué)生的專業(yè)及開課學(xué)期生成可選的課程表，讓學(xué)生完成選課，并自動(dòng)生成選課信息表。（4）選課信息表的查詢與修改：所選課的課程號(hào)、課程名、學(xué)號(hào)、選課時(shí)間、所修學(xué)期等基本信息在一定的時(shí)間段內(nèi)可刪除。（5）查詢信息：各類基本信息的分類查詢

（6）統(tǒng)計(jì)信息：各類基本信息的分類統(tǒng)計(jì)。

? 課題二十五：學(xué)生黨員管理系統(tǒng)開發(fā)（1人）

（1）學(xué)生黨員信息的管理；能夠增加、修改和刪除學(xué)生黨員的基本信息；（2）查詢黨員的基本信息：能夠按照查詢條件（班級(jí)、年級(jí)、專業(yè)、入黨時(shí)間）查詢黨員的數(shù)量；也能夠?qū)崿F(xiàn)多個(gè)條件的組合查詢

（3）統(tǒng)計(jì)黨員的基本信息：統(tǒng)計(jì)按照查詢條件（班級(jí)、年級(jí)、專業(yè)、入黨時(shí)間）查詢黨員的數(shù)量；

? 課題二十六：學(xué)生綜合評(píng)定積分管理系統(tǒng)開發(fā)（1人）

（1）學(xué)生綜合成績的管理：能夠按照學(xué)年記錄增加、修改和刪除學(xué)生各項(xiàng)分值（德育素質(zhì)分各項(xiàng)、體育素質(zhì)分各項(xiàng)、智育素質(zhì)分各項(xiàng)），并能夠進(jìn)行自動(dòng)運(yùn)算求出學(xué)生該學(xué)年的綜合積分。

（2）成績查詢：能夠按照查詢條件（學(xué)年、專業(yè)、班級(jí)）對(duì)各項(xiàng)信息進(jìn)行查詢。（3）能夠按照設(shè)定條件進(jìn)行綜合積分排序（學(xué)年、專業(yè)、班級(jí)）和對(duì)成績的統(tǒng)計(jì)

注：提供數(shù)據(jù)：系各班綜合評(píng)定表；學(xué)生學(xué)籍信息統(tǒng)計(jì)表； ? 課題二十七：畢業(yè)論文管理系統(tǒng)開發(fā)（1人）

（1）畢業(yè)論文基本信息管理：能夠向數(shù)據(jù)庫中添加、修改、刪除論文記錄。?（2）數(shù)據(jù)查詢：能夠按照查詢條件（指導(dǎo)教師、選題性質(zhì)、題目類型、成績、專業(yè)班級(jí)、年級(jí)、學(xué)生姓名、難度、指導(dǎo)教師職稱）進(jìn)行論文的查詢并能瀏覽查詢結(jié)果。

?（3）數(shù)據(jù)統(tǒng)計(jì)：能夠按照設(shè)定條件進(jìn)行相關(guān)數(shù)據(jù)的統(tǒng)計(jì)（成績百分率（優(yōu)秀、良好、中等、及格、不及格），可以以專業(yè)來統(tǒng)計(jì)也可以以班級(jí)來統(tǒng)計(jì)）。

? 課題二十八：學(xué)生宿舍查詢系統(tǒng)開發(fā)（1-2人）

（1）學(xué)生宿舍信息管理：能夠向數(shù)據(jù)庫中添加、刪除和修改宿舍記錄。（2）宿舍信息查詢：能夠按照查詢條件（學(xué)生姓名、學(xué)號(hào)、宿舍、電話、班級(jí)）進(jìn)行查詢并能瀏覽查詢結(jié)果。

（3）宿舍信息統(tǒng)計(jì)：能夠按照條件（學(xué)生人數(shù)、專業(yè)、是否住滿或是否為空等）進(jìn)行統(tǒng)計(jì)并能瀏覽統(tǒng)計(jì)結(jié)果。

? 注：提供的數(shù)據(jù)有學(xué)生宿舍信息匯總表、學(xué)生學(xué)籍信息統(tǒng)計(jì)表 ? 課題二十九：考試監(jiān)考管理系統(tǒng)開發(fā)（1人）（1）基本信息管理：能夠向數(shù)據(jù)庫中添加、刪除、修改監(jiān)考安排相關(guān)的信息。（2）數(shù)據(jù)查詢：能夠按照條件（教師姓名、監(jiān)考校區(qū)）進(jìn)行查詢；

（3）數(shù)據(jù)統(tǒng)計(jì)：按照教師姓名統(tǒng)計(jì)教師每一學(xué)期監(jiān)考的次數(shù)和監(jiān)考費(fèi)，往返新老兩個(gè)校區(qū)的監(jiān)考費(fèi)為13元/次，否則為10元/次； ? 課題三十：氣象信息管理系統(tǒng)開發(fā)（1人）

（1）基本信息管理：能夠向數(shù)據(jù)庫中添加、刪除、修改氣象記錄。

（2）數(shù)據(jù)查詢：能夠按照查詢條件（月份、地名、氣溫類別）進(jìn)行查詢并能瀏覽查詢結(jié)果

（3數(shù)據(jù)統(tǒng)計(jì)：能夠按照統(tǒng)計(jì)條件（月份、地名、氣溫類別）進(jìn)行統(tǒng)計(jì)并能瀏覽統(tǒng)計(jì)結(jié)果。