數據存儲設計方案
㈠ 數據倉庫與ODS的區別，數據倉庫和ODS並存方案
一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。先大概列一下互聯網行業數據倉庫、數據平台的用途：
整合公司所有業務數據，建立統一的數據中心；
提供各種報表，有給高層的，有給各個業務的；
為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；
為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；
分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發數據產品，直接或間接為公司盈利；
建設開放數據平台，開放公司數據；
。。。。。。
上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：
邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
我們從下往上看：
數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。
數據源的種類比較多：
網站日誌：
作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；
業務資料庫：
業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。
當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。
來自於Ftp/Http的數據源：
有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數據源：
比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；
數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；
當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
實時計算部分，後面單獨說。
數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
數據應用
業務產品
業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；
報表
同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
即席查詢
即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；
這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；
比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。
其它數據介面
這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。
實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。
我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。
做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。
任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；
這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。
前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。
總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。
㈡ 誰知道資料庫優化設計方案有哪些
本文首先討論了基於第三範式的資料庫表的基本設計，著重論述了建立主鍵和索引的策略和方案，然後從資料庫表的擴展設計和庫表對象的放置等角度概述了資料庫管理系統的優化方案。
關鍵詞： 優化（Optimizing） 第三範式（3NF） 冗餘數據（Rendant Data） 索引（Index） 數據分割（Data Partitioning） 對象放置（Object Placement）
1 引言
資料庫優化的目標無非是避免磁碟I/O瓶頸、減少CPU利用率和減少資源競爭。為了便於讀者閱讀和理解，筆者參閱了Sybase、Informix和Oracle等大型資料庫系統參考資料，基於多年的工程實踐經驗，從基本表設計、擴展設計和資料庫表對象放置等角度進行討論，著重討論了如何避免磁碟I/O瓶頸和減少資源競爭，相信讀者會一目瞭然。
2 基於第三範式的基本表設計
在基於表驅動的信息管理系統（MIS）中，基本表的設計規范是第三範式（3NF）。第三範式的基本特徵是非主鍵屬性只依賴於主鍵屬性。基於第三範式的資料庫表設計具有很多優點：一是消除了冗餘數據，節省了磁碟存儲空間；二是有良好的數據完整性限制，即基於主外鍵的參照完整限制和基於主鍵的實體完整性限制，這使得數據容易維護，也容易移植和更新；三是數據的可逆性好，在做連接（Join）查詢或者合並表時不遺漏、也不重復；四是因消除了冗餘數據（冗餘列），在查詢（Select）時每個數據頁存的數據行就多，這樣就有效地減少了邏輯I/O，每個Cash存的頁面就多，也減少物理I/O；五是對大多數事務(Transaction)而言，運行性能好；六是物理設計(Physical Design)的機動性較大，能滿足日益增長的用戶需求。
在基本表設計中，表的主鍵、外鍵、索引設計佔有非常重要的地位，但系統設計人員往往只注重於滿足用戶要求，而沒有從系統優化的高度來認識和重視它們。實際上，它們與系統的運行性能密切相關。現在從系統資料庫優化角度討論這些基本概念及其重要意義：
（1）主鍵(Primary Key)：主鍵被用於復雜的SQL語句時，頻繁地在數據訪問中被用到。一個表只有一個主鍵。主鍵應該有固定值（不能為Null或預設值，要有相對穩定性），不含代碼信息，易訪問。把常用（眾所周知）的列作為主鍵才有意義。短主鍵最佳（小於25bytes），主鍵的長短影響索引的大小，索引的大小影響索引頁的大小，從而影響磁碟I/O。主鍵分為自然主鍵和人為主鍵。自然主鍵由實體的屬性構成，自然主鍵可以是復合性的，在形成復合主鍵時，主鍵列不能太多，復合主鍵使得Join*作復雜化、也增加了外鍵表的大小。人為主鍵是，在沒有合適的自然屬性鍵、或自然屬性復雜或靈敏度高時，人為形成的。人為主鍵一般是整型值（滿足最小化要求），沒有實際意義，也略微增加了表的大小；但減少了把它作為外鍵的表的大小。
（2）外鍵（Foreign Key）：外鍵的作用是建立關系型資料庫中表之間的關系（參照完整性），主鍵只能從獨立的實體遷移到非獨立的實體，成為後者的一個屬性，被稱為外鍵。
（3）索引(Index)：利用索引優化系統性能是顯而易見的，對所有常用於查詢中的Where子句的列和所有用於排序的列創建索引，可以避免整表掃描或訪問，在不改變表的物理結構的情況下，直接訪問特定的數據列，這樣減少數據存取時間；利用索引可以優化或排除耗時的分類*作；把數據分散到不同的頁面上，就分散了插入的數據；主鍵自動建立了唯一索引，因此唯一索引也能確保數據的唯一性（即實體完整性）；索引碼越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代價：有空間開銷，建立它也要花費時間，在進行Insert、Delete和Update*作時，也有維護代價。索引有兩種：聚族索引和非聚族索引。一個表只能有一個聚族索引，可有多個非聚族索引。使用聚族索引查詢數據要比使用非聚族索引快。在建索引前，應利用資料庫系統函數估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的數據頁按物理有序儲存，佔用空間小。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢或高度重復的列（連續磁碟掃描）；被用於連接Join*作的列；被用於Order by和Group by子句的列。聚族索引不利於插入*作，另外沒有必要用主鍵建聚族索引。
② 非聚族索引（Nonclustered Index）：與聚族索引相比，佔用空間大，而且效率低。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢（在沒有聚族索引時）、主鍵或外鍵列、點（指針類）或小范圍（返回的結果域小於整表數據的20%）查詢；被用於連接Join*作的列、主鍵列（范圍查詢）；被用於Order by和Group by子句的列；需要被覆蓋的列。對只讀表建多個非聚族索引有利。索引也有其弊端，一是創建索引要耗費時間，二是索引要佔有大量磁碟空間，三是增加了維護代價（在修改帶索引的數據列時索引會減緩修改速度）。那麼，在哪種情況下不建索引呢？對於小表（數據小於5頁）、小到中表（不直接訪問單行數據或結果集不用排序）、單值域（返回值密集）、索引列值太長（大於20bitys）、容易變化的列、高度重復的列、Null值列，對沒有被用於Where子語句和Join查詢的列都不能建索引。另外，對主要用於數據錄入的，盡可能少建索引。當然，也要防止建立無效索引，當Where語句中多於5個條件時，維護索引的開銷大於索引的效益，這時，建立臨時表存儲有關數據更有效。
批量導入數據時的注意事項：在實際應用中，大批量的計算（如電信話單計費）用C語言程序做，這種基於主外鍵關系數據計算而得的批量數據（文本文件），可利用系統的自身功能函數（如Sybase的BCP命令）快速批量導入，在導入資料庫表時，可先刪除相應庫表的索引，這有利於加快導入速度，減少導入時間。在導入後再重建索引以便優化查詢。
（4）鎖：鎖是並行處理的重要機制，能保持數據並發的一致性，即按事務進行處理；系統利用鎖，保證數據完整性。因此，我們避免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務的長短；要避免批量數據同時執行，尤其是耗時並用到相同的數據表。鎖的徵用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在等待。若用戶數增加，則Server的性能下降，出現「假死」現象。如何避免死鎖呢？從頁級鎖到行級鎖，減少了鎖徵用；給小表增加無效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響，可選擇合適的聚族索引把數據分配到不同的頁面；創建冗餘表；保持事務簡短；同一批處理應該沒有網路交互。
（5）查詢優化規則：在訪問資料庫表的數據(Access Data)時，要盡可能避免排序（Sort）、連接(Join)和相關子查詢*作。經驗告訴我們，在優化查詢時，必須做到：
① 盡可能少的行；
② 避免排序或為盡可能少的行排序，若要做大量數據排序，最好將相關數據放在臨時表中*作；用簡單的鍵（列）排序，如整型或短字元串排序；
③ 避免表內的相關子查詢；
④ 避免在Where子句中使用復雜的表達式或非起始的子字元串、用長字元串連接；
⑤ 在Where子句中多使用「與」（And）連接，少使用「或」(Or)連接；
⑥ 利用臨時資料庫。在查詢多表、有多個連接、查詢復雜、數據要過濾時，可以建臨時表（索引）以減少I/O。但缺點是增加了空間開銷。
除非每個列都有索引支持，否則在有連接的查詢時分別找出兩個動態索引，放在工作表中重新排序。
3 基本表擴展設計
基於第三範式設計的庫表雖然有其優越性（見本文第一部分），然而在實際應用中有時不利於系統運行性能的優化：如需要部分數據時而要掃描整表，許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程從多表獲取數據時引發大量的連接*作，當數據來源於多表時的連接*作；這都消耗了磁碟I/O和CPU時間。
尤其在遇到下列情形時，我們要對基本表進行擴展設計：許多過程要頻繁訪問一個表、子集數據訪問、重復計算和冗餘數據，有時用戶要求一些過程優先或低的響應時間。
如何避免這些不利因素呢？根據訪問的頻繁程度對相關表進行分割處理、存儲冗餘數據、存儲衍生列、合並相關表處理，這些都是克服這些不利因素和優化系統運行的有效途徑。
3.1 分割表或儲存冗餘數據
分割表分為水平分割表和垂直分割表兩種。分割表增加了維護數據完整性的代價。
水平分割表：一種是當多個過程頻繁訪問數據表的不同行時，水平分割表，並消除新表中的冗餘數據列；若個別過程要訪問整個數據，則要用連接*作，這也無妨分割表；典型案例是電信話單按月分割存放。另一種是當主要過程要重復訪問部分行時，最好將被重復訪問的這些行單獨形成子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但在分割表以後，增加了維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。
垂直分割表（不破壞第三範式），一種是當多個過程頻繁訪問表的不同列時，可將表垂直分成幾個表，減少磁碟I/O（每行的數據列少，每頁存的數據行就多，相應佔用的頁就少），更新時不必考慮鎖，沒有冗餘數據。缺點是要在插入或刪除數據時要考慮數據的完整性，用存儲過程維護。另一種是當主要過程反復訪問部分列時，最好將這部分被頻繁訪問的列數據單獨存為一個子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但這增加了重疊列的維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。垂直分割表可以達到最大化利用Cache的目的。
總之，為主要過程分割表的方法適用於：各個過程需要表的不聯結的子集，各個過程需要表的子集，訪問頻率高的主要過程不需要整表。在主要的、頻繁訪問的主表需要表的子集而其它主要頻繁訪問的過程需要整表時則產生冗餘子集表。
注意，在分割表以後，要考慮重新建立索引。
3.2 存儲衍生數據
對一些要做大量重復性計算的過程而言，若重復計算過程得到的結果相同（源列數據穩定，因此計算結果也不變），或計算牽扯多行數據需額外的磁碟I/O開銷，或計算復雜需要大量的CPU時間，就考慮存儲計算結果（冗餘儲存）。現予以分類說明：
若在一行內重復計算，就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器更新這個新列。
若對表按類進行重復計算，就增加新表（一般而言，存放類和結果兩列就可以了）存儲相關結果。但若參與計算的列被更新時，就必須要用觸發器立即更新、或存儲過程或應用代碼批量更新這個新表。
若對多行進行重復性計算（如排名次），就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器或存儲過程更新這個新列。
總之，存儲冗餘數據有利於加快訪問速度；但違反了第三範式，這會增加維護數據完整性的代價，必須用觸發器立即更新、或存儲過程或應用代碼批量更新，以維護數據的完整性。
3.3 消除昂貴結合
對於頻繁同時訪問多表的一些主要過程，考慮在主表內存儲冗餘數據，即存儲冗餘列或衍生列（它不依賴於主鍵），但破壞了第三範式，也增加了維護難度。在源表的相關列發生變化時，必須要用觸發器或存儲過程更新這個冗餘列。當主要過程總同時訪問兩個表時可以合並表，這樣可以減少磁碟I/O*作，但破壞了第三範式，也增加了維護難度。對父子表和1：1關系表合並方法不同：合並父子表後，產生冗餘表；合並1：1關系表後，在表內產生冗餘數據。
4 資料庫對象的放置策略
資料庫對象的放置策略是均勻地把數據分布在系統的磁碟中，平衡I/O訪問，避免I/O瓶頸。
⑴ 訪問分散到不同的磁碟，即使用戶數據盡可能跨越多個設備，多個I/O運轉，避免I/O競爭，克服訪問瓶頸；分別放置隨機訪問和連續訪問數據。
⑵ 分離系統資料庫I/O和應用資料庫I/O。把系統審計表和臨時庫表放在不忙的磁碟上。
⑶ 把事務日誌放在單獨的磁碟上，減少磁碟I/O開銷，這還有利於在障礙後恢復，提高了系統的安全性。
⑷ 把頻繁訪問的「活性」表放在不同的磁碟上；把頻繁用的表、頻繁做Join*作的表分別放在單獨的磁碟上，甚至把把頻繁訪問的表的欄位放在不同的磁碟上，把訪問分散到不同的磁碟上，避免I/O爭奪；
⑸ 利用段分離頻繁訪問的表及其索引（非聚族的）、分離文本和圖像數據。段的目的是平衡I/O，避免瓶頸，增加吞吐量，實現並行掃描，提高並發度，最大化磁碟的吞吐量。利用邏輯段功能，分別放置「活性」表及其非聚族索引以平衡I/O。當然最好利用系統的默認段。另外，利用段可以使備份和恢復數據更加靈活，使系統授權更加靈活。
㈢ 在資料庫存儲結構設計時要考慮哪些因素
第一：各個參數是否對應的一個對象（面向對象編程思想）；
第二：各個參數可能類型和出現的最大長度，之後合理的設計各個欄位的最大長度和相應類型；
第三：各個參數中哪些欄位具有唯一性，考慮作為主鍵或者是外鍵來進行表關聯；
第四：根據數據量的大小來考慮是否需要進行分區處理；
第五：哪些欄位是不經常便跟欄位，可以考慮進行多張表的存儲來節省存儲空間（可能影響查詢修改效率）
㈣ 急求一份管理信息系統課程設計
1成績管理系統------分析報告(不知如何貼數據流程圖之類的到這里，所以把相關圖片貼到空間里啦)（另：數據字典是表格形式啦，貼來這里就變了。）
一 . 引言
1.系統名稱：學生成績管理信息系統
2.開發目標：開發出一個操作簡便，界面友好，靈活實用，安全可靠的學生成績管理信息系統。
該系統的開發以教務管理人員和任課教師服務為對象，能夠提高學校對學生成績的統計分析效率，減輕教務管理人員對學生成績管理和統計的負擔，提高學校對學生成績的規范化管理。
該成績管理系統能夠及時對學生成績進行收集整理，使學校相關部門及時獲取可靠的學生成績信息，便於管理。
3.主要功能：
本系統的使用者根據其使用者------教務處管理人員和任課教師-----可分為以下幾方面：
（1）教務處管理人員登陸後，進入教務人員管理模塊，可以進行個人信息查詢，教師住處職稱工資情況的查詢，學生信息查詢，成績查詢以及退出系統等操作。
（2）教師登陸教師管理子系統，要能夠對學生成績進行許可權范圍內的錄入、添加、修改、刪除、查詢；查詢教師信息、更改個人登陸密碼、修改個人信息等；
（3）學生單科成績、全科成績的總分、平均分，最高分、最低分，排序等計算和統計實現自動化；可以按班級、按個人進行信息查詢；信息可以發布到網路，以實現數據共享；
（4）能夠自動進行錄入錯誤檢查
4.開發背景
每個學校都需要在學期末進行期末考試成績的統計分析工作，而這些工作都必須在考試結束後近一個星期的時間內完成。大量的成績數據的統計分析工作如果只靠人工來完成，費時費力，還容易出錯。隨著計算機技術的飛速發展，計算機在日常管理應用中迅速普及，利用計算機進行學生成績管理勢在必行。因此需開發出一個能滿足學校進行成績的錄入，統計，查詢，報表和列印等需求的、功能完善、安全可靠、迅速簡便的成績管理信息系統。
二. 系統目標和開發的可行性
1.系統目標：
(1)為教務處管理人員提供各學期、各年級、各班級學生的基本成績信息，以作為其進行成績匯總，分析和考績和總結評比的依據。
(2)方便各任課教師記錄，統計所帶班學生成績，提高工作效率，減輕負擔；總結經驗，提高教學質量。
(3)實現快速方便地處理大量成績數據信息，完成成績的錄入、添加、修改、刪除、統計、查詢、排序等處理要求。
(4)輸出和列印成績單和各種成績報表。
2.開發的可行性
(1)系統的名稱、功能、目標等已如前所述，此地不再重復。
(2)系統環境以及工具：
A. 軟體環境：
用戶端：Windows2000，Windows2003，Windows XP
伺服器端：WindowsNT/Windows2000及以上操作系統
編程語言：SOL
資料庫：Access2003
B 硬體環境：
有高性能的電子計算機、大容量的存貯裝置，個人電腦（終端）以及聯結起來的網線等，組成信息資源共享的計算機網路，有共享的列印機，掃描儀等等
（3）系統設計原則：
1) 系統運行安全可靠，穩定性好；
2) 系統的可管理性和可維護性好；
3) 系統輸入界面友好，操作簡便易行，盡量減少用戶的輸入工作量；
4）允許多種數據輸入方式，能實現多種查詢，允許進行模糊查詢；
5）數據具有規范性，整體性，方便數據之間的比較分析。
（4）系統可行性分析：
A． 技術可行性：系統要求在windows2000以上環境運行，後台資料庫採用access2003，使用SOL編程，採用ADO方式連接資料庫，這些在目前都是容易實現的。程序將部分需要經常調用的數據存入內存，可提高程序運行速度．
B．經濟可行性：在經濟上，用此系統加強了成績信息管理效率，為教務人員提供了較高的效率，可節省人力資源的開支。
C．管理的可行性：在工作上，教務人員管理學生信息量非常大，開發了此系統，可極大提高教務人員的工作的效率。方便成績的儲存和修改，及以後隨時查詢成績信息，是一個比較人性化的管理系統。
（5）．系統分析結論：
由以上分析得出，本系統可進行開發。
三. 現行系統概況
1.現行系統現狀調查
現有的學生成績管理系統主要是以成績數據信息的存儲和統計為目標，而且系統的設計繁瑣，管理不夠專人化，需要的人員過多，因此系統的安全性保密性不好；查詢功能簡單，數據共享性不高。
2.系統需求說明
（1）系統需要在實現數據錄入，存儲，統計自動化的基礎上增強查詢功能；
（2）要能夠充分利用網路擴大信息共享程度；
（3）設專人管理員，明確劃分管理許可權，規范管理，以提高系統的安全性保密性。
四. 新系統的邏輯方案
1.業務流程圖
2．數據流程圖
（1）頂層圖：
（2）第一層：
（3）第二層：
A:身份驗證圖：
B:成績變動處理科：
C:教務人員身份驗證：
3.數據字典
A:數據存儲條目：
編號 名稱 組成
D1.1
教師信息表 教師編號,教師姓名,教師職稱,所教班級,所在學院
D1.2
學生成績記錄單 學生學號，姓名，課程名稱，課程編號，課程成績，教師編號
D1.3
教務人員信息表 教務人員姓名，編號，職稱
D1.4
反饋信息表 教務處人員信息後對教師的評價，學生成績的分析
B:數據加工條目：
編號 名稱 輸入 處理邏輯 輸出
P1.1 身份驗證處理 教師登陸信息 檢驗教師教工號與密碼是否一致 ———
P1.2 成績變動處理 學生學科成績 錄入、修改、刪除成績並檢驗是否輸入錯誤 學生成績記錄單
P1.3 成績查詢處理 學生班別、學號、姓名 查詢學生成績，排序等 學生成績記錄單
P1.4
身份驗證處理 教務人員登陸信息量 檢驗教務人員編號與密碼 ———
P1.5 成績查詢處理 學院編號、年級、學號 查詢班級成績、排序及學期平均分等 學生成績記錄單及對教師的反饋信息
C:數據元素項目：
編號 名稱 數據類型 長度 小數位 取值范圍 說明
01 教師編號 N 8 0
02 教師名字 C 8
03 教師職稱 C 6
04 所教班級 N 8 0
05 學生學號 N 8 0
06 學生姓名 C 8
07 課程名稱 C 16
08 課程編號 N 10
09 成績 N 3 1 0~~100
10 教務人員編號 N 8 0
11 教務人員姓名 C 8
12 教務人員職稱 C 6
五．系統實施計劃：
1．工作任務分工：
系統初步規劃：
實驗報告填寫及圖表繪制：
系統編程：，
後期系統檢測完善：
2．進度安排：
系統分析階段：2006.6.11—2..6.6.13
系統設計階段：20066.20—2006.6.24
系統實施階段：2006.25—2006.6.29
__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
2系統設計報告：
系統設計報告
一、概述
以需求分析說明書為依據，針對教務管理人員及教師對學生成績的管理需求，參照現有的開發環境，利用可用資源和使用環境，設計出能滿足相應功能的特點,構造並確定出類和類成員函數。
二、環境說明
1．硬體環境：CPU型號為Pentium Ⅲ以上，內存128M以上。
系統環境：Windows98 及WindowsXP等系統均可。
2．開發環境：Access軟體下開發，此軟體是面向對象的開發工具，易於上手，而且界面比較友好
三、模塊圖
四、功能模塊
本系統大致分為如下四大功能模塊。
1．用戶登陸模塊
用戶登陸模塊：（教務處管理人員---葉飛—密碼：950281）
（教師---劉力—密碼：980102）
A:教務處管理人員登陸後，進入教務人員管理模塊，可以進行個人信息查詢，教師住處查詢，學生信息查詢，成績查詢以及退出系統等操作。
B:教師登陸後，進入教員管理模塊，可以進行個人資料修改，學生信息查詢，本班成績查詢，其它班成績查詢，退出登陸等操作。
2．查詢及修改模塊
包括以下四個模塊：
A:學生個人信息查詢模塊：此模塊又分為學生個體模塊和班級模塊。學生個體模塊包含了學生的基本信息以及成績，可進行如學生所在班組，學院，專業，英語成績等相關查詢操作；
在班級模塊則可按班級查詢學生的信息。
B:教師信息查詢及修改模塊：此模塊主要服務於教務管理人員，可以通過打開「教師表」或「單個教師信息」進行總體或指定個體查詢，如對教師工齡、工資額的設定，對各個工齡段及相應的工齡工資額進行修改、添加、刪除等操作。
C:成績查詢及修改模塊：該模塊又分為三部分：按指定學號進行學生個體成績查詢及修改； 按指定教工號進行教師所教班級成績查詢； 按指定班級號或專業號進行綜合成績查詢其中還包括教師對其它班成績的查詢（但不無修改權）。
成績查詢具體內容包括指定科目成績查詢，成績排序，排名，平均分和不及格科目查詢等
D:用戶信息修改模塊：此模塊用於教務管理人員及教師修改密碼或用戶名，教師教課班級及工資職稱等信息的修改。
3．退出模塊
查詢修改完畢，通過退出模塊退出成績管理系統，以確保系統及個人信息的安全。
五、代碼設計：
1 用戶登陸模塊代碼：
A：教務處管理人員登陸
◆Private Sub 教務處人員登錄_Click()
On Error GoTo Err_教務處人員登錄_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(21153) & ChrW(22788) & ChrW(20154) & ChrW(21592) & ChrW(30331) & ChrW(24405)
DoCmd.RunMacro stDocName
Exit_教務處人員登錄_Click:
Exit Sub
Err_教務處人員登錄_Click:
MsgBox Err.Description
Resume Exit_教務處人員登錄_Click
End Sub
B: 教師登陸
◆Private Sub 教師登錄_Click()
On Error GoTo Err_教師登錄_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(30331) & ChrW(24405)
DoCmd.RunMacro stDocName
Exit_教師登錄_Click:
Exit Sub
Err_教師登錄_Click:
MsgBox Err.Description
Resume Exit_教師登錄_Click
End Sub
◆Private Sub ok_Click()
If Len(Nz(Me!UserName)) = 0 And Len(Nz(Me!UserPassword)) = 0 Then
MsgBox "用戶名、密碼為空！請輸入", vbCritical, "error"
Me!UserName.SetFocus
ElseIf Len(Nz(Me!UserName)) = 0 Then
MsgBox "用戶名為空！請輸入", vbCritical, "error"
Me!UserName.SetFocus
ElseIf Len(Nz(Me!UserPassword)) = 0 Then
MsgBox "密碼為空！請輸入", vbCritical, "error"
Me!UserName.SetFocus
Else
If Me!UserName = "劉力" Then
If UCase(Me!UserPassword) = "980102" Then
MsgBox "歡迎使用！", vbInformation, "成功"
DoCmd.OpenForm "教師-綜合信息查詢"
Else
MsgBox "密碼有誤，非正常退出。", vbCritical, "error"
DoCmd.Close
End If
Else
MsgBox "用戶名有誤，非正常退出。", vbCritical, "error"
DoCmd.Close
End If
End If
End Sub
2 學生個人信息查詢模塊代碼
A:指定學生信息查詢：
◆ Private Sub Command1_Click()
On Error GoTo Err_Command1_Click
Dim stDocName As String
stDocName = ChrW(23398) & ChrW(29983) & ChrW(20010) & ChrW(20154) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command1_Click:
Exit Sub
Err_Command1_Click:
MsgBox Err.Description
Resume Exit_Command1_Click
End Sub
B:班級所有學生信息查詢：
◆Private Sub Command20_Click()
On Error GoTo Err_Command20_Click
Dim stDocName As String
stDocName = ChrW(29677) & ChrW(32423) & ChrW(23398) & ChrW(29983) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command20_Click:
Exit Sub
Err_Command20_Click:
MsgBox Err.Description
Resume Exit_Command20_Click
End Sub
3 教師信息查詢及修改模塊代碼
A:指定教師信息查詢
◆Private Sub Command13_Click()
On Error GoTo Err_Command13_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(20449) & ChrW(24687) & ChrW(21333) & ChrW(20010) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command13_Click:
Exit Sub
Err_Command13_Click:
MsgBox Err.Description
Resume Exit_Command13_Click
End Sub
B:全體教師信息查詢：
◆Private Sub Command14_Click()
On Error GoTo Err_Command14_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(24072) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command14_Click:
Exit Sub
Err_Command14_Click:
MsgBox Err.Description
Resume Exit_Command14_Click
End Sub
4 成績查詢及修改模塊代碼
A:指定學生個體成績查詢：
◆Private Sub Command23_Click()
On Error GoTo Err_Command23_Click
Dim stDocName As String
stDocName = ChrW(23398) & ChrW(29983) & ChrW(20010) & ChrW(20154) & ChrW(25104) & ChrW(32489) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command23_Click:
Exit Sub
Err_Command23_Click:
MsgBox Err.Description
Resume Exit_Command23_Click
End Sub
B: 指定班級綜合成績查詢
◆Private Sub Command24_Click()
On Error GoTo Err_Command24_Click
Dim stDocName As String
stDocName = ChrW(25353) & ChrW(29677) & ChrW(32423) & ChrW(26597) & ChrW(-29726) & ChrW(23398) & ChrW(29983) & ChrW(25104) & ChrW(32489)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command24_Click:
Exit Sub
Err_Command24_Click:
MsgBox Err.Description
Resume Exit_Command24_Click
End Sub
5 用戶信息修改模塊代碼
◆Private Sub Command28_Click()
On Error GoTo Err_Command28_Click
Dim stDocName As String
stDocName = ChrW(25945) & ChrW(21153) & ChrW(22788) & ChrW(20154) & ChrW(21592) & ChrW(20449) & ChrW(24687) & ChrW(26597) & ChrW(-29726)
DoCmd.OpenQuery stDocName, acNormal, acEdit
Exit_Command28_Click:
Exit Sub
Err_Command28_Click:
MsgBox Err.Description
Resume Exit_Command28_Click
End Sub
6 退出模塊代碼
◆Private Sub Command31_Click()
On Error GoTo Err_Command31_Click
DoCmd.Quit
Exit_Command31_Click:
Exit Sub
Err_Command31_Click:
MsgBox Err.Description
Resume Exit_Command31_Click
End Sub
__________________________________________________________________________________________________________
3系統實施報告
㈤ 大數據時代，數據應該如何存儲
PB或多PB級基礎設施與傳統大規模數據集之間的差別簡直就像白天和黑夜的差別，就像在筆記本電腦上處理數據和在RAID陣列上處理數據之間的差別。"
當Day在2009年加入Shutterfly時，存儲已經成為該公司最大的開支，並且以飛快的速度增長。
"每N個PB的額外存儲意味著我們需要另一個存儲管理員來支持物理和邏輯基礎設施，"Day表示，"面對大規模數據存儲，系統會更頻繁地出問題，任何管理超大存儲的人經常都要處理硬體故障。大家都在試圖解決的根本問題是：當你知道存儲的一部分將在一段時間內出現問題，你應該如何確保數據可用性，同時確保不會降低性能？"RAID問題解決故障的標准答案是復制，通常以RAID陣列的形式。但Day表示，面對龐大規模的數據時，RAID解決問題的同時可能會製造更多問題。在傳統RAID數據存儲方案中，每個數據的副本都被鏡像和存儲在陣列的不同磁碟中，以確保完整性和可用性。但這意味著每個被鏡像和存儲的數據將需要其本身五倍以上的存儲空間。隨著RAID陣列中使用的磁碟越來越大（從密度和功耗的角度來看，3TB磁碟非常具有吸引力），更換故障驅動器的時間也將變得越來越長。
"實際上，我們使用RAID並不存在任何操作問題，"Day表示，"我們看到的是，隨著磁碟變得越來越大，當任何組件發生故障時，我們回到一個完全冗餘的系統的時間增加。生成校驗是與數據集的大小成正比的。當我們開始使用1TB和2TB的磁碟時，回到完全冗餘系統的時間變得很長。可以說，這種趨勢並沒有朝著正確的方向發展。"
對於Shutterfly而言，可靠性和可用性是非常關鍵的因素，這也是企業級存儲的要求。Day表示，其快速膨脹的存儲成本使商品系統變得更具吸引力。當Day及其團隊在研究潛在技術解決方案以幫助控制存儲成本時，他們對於一項叫做糾刪碼（erasure code）的技術非常感興趣。
採用擦除代碼技術的下一代存儲
里德-所羅門糾刪碼最初作為前向糾錯碼（Forward Error Correction, FEC）用於不可靠通道的數據傳輸，例如外層空間探測的數據傳輸。這項技術還被用於CD和DVD來處理光碟上的故障，例如灰塵和劃痕。一些存儲供應商已經開始將糾刪碼納入他們的解決方案中。使用糾刪碼，數據可以被分解成幾塊，單塊分解數據是無用的，然後它們被分散到不同磁碟驅動器或者伺服器。在任何使用，這些數據都可以完全重組，即使有些數據塊因為磁碟故障已經丟失。換句話說，你不需要創建多個數據副本，單個數據就可以確保數據的完整性和可用性。
基於糾刪碼的解決方案的早期供應商之一是Cleversafe公司，他們添加了位置信息來創建其所謂的分散編碼，讓用戶可以在不同位置（例如多個數據中心）存儲數據塊或者說數據片。
每個數據塊就其自身而言是無用的，這樣能夠確保隱私性和安全性。因為信息分散技術使用單一數據來確保數據完整性和可用性，而不是像RAID一樣使用多個副本，公司可以節省多達90%的存儲成本。
"當你將試圖重組數據時，你並不一定需要提供所有數據塊，"Cleversafe公司產品策略、市場營銷和客戶解決方案副總裁Russ Kennedy表示，"你生成的數據塊的數量，我們稱之為寬度，我們將重組數據需要的最低數量稱之為門檻。你生成的數據塊的數量和重組需要的數量之間的差異決定了其可靠性。同時，即使你丟失節點和驅動器，你仍然能夠得到原來形式的數據。"
㈥ 數據存儲解決方案可以實現什麼作用
數據存儲解決方案可以實現的作用有以下8點：
1 信息資產的統一管控
企業運行過程中，可能產生一些違規數據，可將違規數據定位，並且統一刪除，對所有用戶的查詢和使用集中控制。
2 分公司管理員角色設置
雲企網盤可針對大中型企業，靈活的配置用戶許可權，可設置多級的管理員許可權。
3 標准API介面，系統間無縫對接
雲企網盤系統提供了全套的API介面，可完成所有功能的數據對接，其他系統調用即可將數據傳輸至雲企網盤集中管理，安全存儲。
雲企網盤系統從底層上就設計為可對接的數據管理系統，各終端都通過API對系統進行訪問。
4 按鈕級許可權設置
考慮到企業的數據管控，文件系統的防擴散。雲企網盤的授權體系可細分到按鈕，可以控制每個用戶，能否操作每一個具體的功能。
5 集團級組織架構設置
雲企網盤是針對企業管理設計的系統，可針對復雜的企業組織架構進行設置，可適用與集團級的大型企業。可對組織的級別、性質、順序進行定義，可以添加、刪除、移動組織單元。
6 信息資產的查詢
雲企網盤可根據數據的授權，統一對數據進行查詢，可根據條件進行高級檢索。
7 文檔版本管理
文件上傳更新以後，所有歷史版本都會繼續保存，這樣即使工作中發生了失誤，也可以通過網盤補救。 查看原始文檔 找回丟失文件 修復崩潰文檔
找回錯誤覆蓋的文件
8 信息資產的遷移
企業員工根據工作內容的變化，可能發生工作的交接情況，雲企網盤可將員工的文件管理許可權進行一鍵交接。快速的工作交接同時，也避免數據丟失，避免企業資產受損。
㈦ ScaleIO、VSAN、MFS、Ceph這幾種存儲方案的區別是什麼
ScaleIO:使用彈性聚合軟體產品來革新數據存儲，該軟體產品利用本地磁碟來創建伺服器存儲區域網路 (SAN)。純軟體方式的基於伺服器的存儲區域網路 (SAN)，將存儲和計算資源聚合到一起，形成單層的企業級存儲產品。 ScaleIO 存儲彈性靈活，可以提供可線性擴展的性能。 其橫向擴展伺服器 SAN 體系結構可以從幾個伺服器擴展至數千伺服器。
基本適用於全平台。https://community.emc.com/thread/198500
VSAN：VMware Virtual SAN™ 是面向虛擬環境中超聚合的軟體定義存儲.Virtual SAN 是第一款專為 vSphere 環境設計的策略驅動型存儲產品，可幫助用戶實現存儲調配和管理的簡化和優化。 通過使用虛擬機級存儲策略，Virtual SAN 可自動將需求與底層存儲資源進行動態匹配。藉助 Virtual SAN，許多手動存儲任務都可以實現自動化，從而提供更加高效和經濟實惠的運維模式。對比 ScaleIO，它是僅限於VMware虛擬化平台的。
參考鏈接：Virtual SAN：軟體定義的共享存儲 | VMware 中國
MFS 是分布式文件系統，可參考：分布式存儲系統MFS -
Ceph是一個 Linux PB 級分布式文件系統。
㈧ 大數據下的地質資料信息存儲架構設計
頡貴琴 胡曉琴
(甘肅省國土資源信息中心)
摘要 為推進我國地質資料信息服務集群化產業化工作，更大更好地發揮地質資料信息的價值，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。
關鍵詞 大數據 地質資料 存儲 NoSQL 雙資料庫
0 引言
新中國成立60多年來，我國形成了海量的地質資料信息，為國民經濟和社會發展提供了重要支撐。但在地質資料管理方面長期存在資料信息分散、綜合研究不夠、數字化信息化程度不高、服務渠道不暢、服務能力不強等問題，使地質資料信息的巨大潛在價值未能得到充分發揮。為進一步提高地質工作服務國民經濟和社會發展的能力，充分發揮地質資料信息的服務功能，擴大服務領域，國土資源部根據國內外地質工作的先進經驗，做出了全面推進地質資料信息服務集群化產業化工作的部署。
目前，全國各省地質資料館都在有條不紊地對本省成果、原始和實物地質資料進行清理，並對其中重要地質資料進行數字化和存儲工作。然而，由於我國地質資源豐富，經過幾十年的積累，已經形成了海量的地質資料，數據量早已經超過了幾百太位元組(TB)。在進行地質資料信息服務集群化工作中，隨著共享數據量的不斷增大，傳統的數據存儲方式和管理系統必然會展現出存儲和檢索方面的不足以及系統管理方面的缺陷。為了解決該問題，需要設計更加先進的數據存儲架構來實現海量地質資料的存儲。
而大數據(Big Data)作為近年來在雲計算領域中出現的一種新型數據，科技工作者在不斷的研究中，設計了適合大數據存儲管理的非關系型資料庫NoSQL進行大數據的存儲和管理。本文將針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，提出一種海量地質資料存儲架構，改進現有系統存儲架構，以便於我國全面推進地質資料信息服務集群化產業化工作。
1 工作現狀
1.1 國內外地質資料信息的存儲現狀
在美國，主要有兩大地質資料公共服務平台，分別是地球科學信息中心(ESIC)、地球資源觀測和科學中心(EROS)，其目的是通過為社會和政府提供更加便利、快速的地質信息服務。20世紀90年代初，澳大利亞出台了國家地球科學填圖協議，採用先進的科學方法和技術進行數據存儲，從而形成了第二代澳大利亞陸地地質圖。
目前，我國地質資料信息服務集群化產業化工作剛剛起步，雖然國土資源部信息中心已經開發了地質資料信息集群化共享服務平台，並倡導各地方用戶使用該系統。但由於各個地方早期的工作背景不一致，因此各地方所使用的存儲系統也不盡相同，主要有Access、SQL Server、Oracle、MySQL等系統。本文以國土資源部信息中心開發的地質資料信息集群化共享服務平台的存儲系統MySQL為例說明。該系統是基於關系資料庫管理系統MySQL的一套分布式存儲檢索系統。該系統的部署使得我國地質資料信息服務集群化產業化工作取得了重大進展，同時也為我國建立標准統一的地質資料信息共享服務平台和互聯互通的網路服務體系奠定了堅實的基礎。然而，該系統的研發並沒有考慮到地質資料信息進一步集群化以及在未來地質資料信息進入大數據時代的信息共享和存儲管理問題，也沒有給出明確的解決方案。
1.2 大數據的存儲架構介紹
大數據是近年在雲計算領域中出現的一種新型數據，具有數據量大、數據結構不固定、類型多樣、查詢分析復雜等特點。傳統關系型資料庫管理系統在數據存儲規模、檢索效率等方面已不再適合大數據存儲。NoSQL(Not Only SQL)是與關系資料庫相對的一類資料庫的總稱。這些資料庫放棄了對關系資料庫的支持，轉而採用靈活的、分布式的數據存儲方式管理數據，從而可以滿足大數據存儲和處理的需求。NoSQL基於非關系型數據存儲的設計理念，以鍵值對進行存儲，採用的數據字的結構不固定，每一個元組可以有不一樣的欄位，且每個元組可以根據自己的需要增加一些自己的鍵值對，可以減少一些檢索時間和存儲空間。目前，應用廣泛的 NoSQL 資料庫有 Google BigTable、HBase、MongoDB、Neo4 j、Infinite Graph等。
2 大數據下的地質資料信息存儲架構設計
根據國土資源部做出的全面推進地質資料信息服務集群化產業化工作的部署，國土資源部倡導全國地質資料館使用國土資源部信息中心開發的地質資料信息集群化共享服務平台，實現地質資料信息的存儲和共享。該系統採用了資料庫管理系統MySQL作為數據存儲系統。
為了與現有系統和現有的工作進行對接，並為將來地質資料進入大數據時代後的存儲工作做准備，本文設計了一種能用於海量地質資料信息存儲並且兼容MySQL的分布式的數據存儲架構(圖1)。
整個系統可以根據不同的用戶等級分為不同的用戶管理層，由於圖幅限制，在圖1 中僅僅展示了3級：國家級管理層(即共享服務平台用戶層)、省級管理層以及市級管理層(可根據實際需要延伸至縣級)。
每級管理層的每個用戶可以單獨管理一個伺服器。如國土資源部信息中心可以單獨管理一個伺服器；甘肅省國土資源信息中心可以單獨管理一個伺服器，陝西省國土資源信息中心可以單獨管理一個伺服器；甘肅的若干個市級國土資源局可以根據需要分別管理各自的伺服器。
在伺服器上分別安裝兩套資料庫管理系統，一套是原有的MySQL資料庫管理系統，另一套是為大數據存儲而配備的NoSQL型資料庫管理系統。在伺服器上還專門開發一個資料庫管理器中間件，用於進行用戶層和資料庫的通信以及兩套資料庫之間的通信。
由於各個管理層都各自維護自己的資料庫和數據。當用戶需要進行數據存儲時，他所影響的資料庫僅僅是本地資料庫，存儲效率較高；當用戶需要從多個資料庫讀取數據時，頂層的共享服務平台會根據用戶需求進行任務分解，將任務分發給下層的管理層進行資料庫讀取，由於各個資料庫並行讀取，從而提高了資料庫讀取效率。
圖1 大數據下的地質資料信息存儲架構框圖
2.1 用戶管理層
用戶管理層根據許可權范圍，分為多層(本文以3層為例)。
位於頂層的國家級管理層(共享服務平台用戶層)負責用戶訪問許可權的分配、與其直接關聯的資料庫的訪問、下級管理層任務的分配等工作。
用戶訪問許可權的分配是指為訪問本共享服務平台的個人用戶和單位用戶分配數據的使用許可權、安全性的設計等。
與其直接關聯的資料庫訪問是指直接存儲在其本地資料庫上的數據的訪問。在該資料庫中不僅要存儲所需要的地質資料，還要存儲注冊用戶信息等數據。
下級管理層任務分配是指如果用戶需要訪問多個下層資料庫，用戶只需要輸入查詢這幾個下層資料庫的命令，而如何查找下層資料庫則由該功能來完成。例如某用戶要查找甘肅、陝西、上海、北京的鐵礦分布圖，則用戶只需要輸入這幾個地方及鐵礦等查詢條件，系統將自動把各個省的資料庫查詢任務分派到下級管理層。
同理，位於下層的省級管理層和市級管理層除了沒有用戶訪問許可權功能外，其餘功能與國家級管理層是相同的。各層之間的資料庫通過互聯網相互連接成分布式的資料庫系統。
2.2 MySQL和NoSQL的融合
MySQL是關系型資料庫，它支持SQL查詢語言，而NoSQL是非關系型資料庫，它不支持SQL查詢語言。用戶要想透明地訪問這兩套資料庫，必須要設計資料庫管理器中間件，作為用戶訪問資料庫的統一入口和兩套資料庫管理系統的通信平台。本文所設計的資料庫管理器簡單模型如圖2所示。
圖2 資料庫管理器模型
伺服器管理器通過用戶程序介面與應用程序進行通訊，通過MySQL資料庫介面與MySQL伺服器通訊，通過NoSQL資料庫介面與NoSQL資料庫介面通訊。當應用程序介面接收到一條資料庫訪問命令之後，交由資料庫訪問命令解析器進行命令解析，從而形成MySQL訪問命令或者NoSQL訪問命令，通過相應的資料庫介面訪問資料庫；資料庫返回訪問結果後經過匯總，由應用程序介面返回給應用程序。
兩套資料庫可以通過雙資料庫通信協議進行相互的通信和互訪。此通信協議的建立便於地質工作人員將已經存入MySQL資料庫的不適合結構化存儲的數據轉存到NoSQL資料庫中，從而便於系統的升級和優化。
2.3 系統的存儲和檢索模式
在本存儲框架設計中，系統採用分布式網路存儲模式，即採用可擴展的存儲結構，利用分散在全國各地的多台獨立的伺服器進行數據存儲。這種方式不僅分擔了伺服器的存儲壓力，提高了系統的可靠性和可用性，還易於進行系統擴展。另外，由於地質資料信息存儲的特殊性，各地方用戶的數據存儲工作基本都是在本地伺服器進行，很少通過網路進行遠程存儲，所以數據存儲效率較高。
在一台資料庫伺服器上安裝有MySQL和NoSQL型兩套資料庫管理系統，分別用於存儲地質資料信息中的結構化數據和非結構化數據。其中，NoSQL型資料庫作為主資料庫，用於存儲一部分結構化數據和全部的非結構化數據；而MySQL資料庫作為輔助資料庫，用於存儲一部分結構化的數據，以及舊系統中已經存儲的數據。使用兩套資料庫不僅可以存儲結構化數據而且還可以適用於大數據時代地質資料信息的存儲，因此系統具有很好的適應性和靈活性。
2.4 安全性設計
地質資料信息是國家的機密，地質工作人員必須要保證它的安全。地質資料信息進入數字化時代之後，地質資料常常在計算機以及網路上進行傳輸，地質資料信息的安全傳輸和保存更是地質工作人員必須關注和解決的問題。在本存儲架構的設計中設計的安全問題主要有資料庫存儲安全、數據傳輸安全、數據訪問安全等問題。
資料庫設計時採用多邊安全模型和多級安全模型阻止資料庫中信息和數據的泄露來提高資料庫的安全性能，以保障地質信息在資料庫中的存儲安全；當用戶登錄系統訪問資料庫時，必須進行用戶甄別和實名認證，這主要是對用戶的身份進行有效的識別，防止非法用戶訪問資料庫；在對地質資料進行網路傳輸時，應該首先將數據進行加密，然後再進行網路傳輸，以防止地質信息在傳輸過程中被竊取。
3 結語
提高地質資料數字化信息化水平，是國外地質工作強國的普遍做法。為推進我國地質資料信息服務集群化產業化工作，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。該存儲架構的設計只涉及了簡單模型的構建，具體詳細復雜的功能設計和軟體實現還需要在進一步的研究工作中完成。
參考文獻
[1]吳金朋.一種大數據存儲模型的研究與應用[D].北京：北京郵電大學計算機學院，2012.
[2]吳廣君，王樹鵬，陳明，等.海量結構化數據存儲檢索系統[J].計算機研究與發展，2012，49(Suppl)：1～5.
[3]黃
㈨ Redis百億級Key存儲設計方案
該應用場景為DMP緩存存儲需求，DMP需要管理非常多的第三方id數據，其中包括各媒體cookie與自身cookie（以下統稱supperid）的mapping關系，還包括了supperid的人口標簽、移動端id（主要是idfa和imei）的人口標簽，以及一些黑名單id、ip等數據。
在hdfs的幫助下離線存儲千億記錄並不困難，然而DMP還需要提供毫秒級的實時查詢。由於cookie這種id本身具有不穩定性，所以很多的真實用戶的瀏覽行為會導致大量的新cookie生成，只有及時同步mapping的數據才能命中DMP的人口標簽，無法通過預熱來獲取較高的命中，這就跟緩存存儲帶來了極大的挑戰。
經過實際測試，對於上述數據，常規存儲超過五十億的kv記錄就需要1T多的內存，如果需要做高可用多副本那帶來的消耗是巨大的，另外kv的長短不齊也會帶來很多內存碎片，這就需要超大規模的存儲方案來解決上述問題。
人⼝標簽主要是cookie、imei、idfa以及其對應的gender（性別）、age（年齡段）、geo（地域）等；mapping關系主要是媒體cookie對supperid的映射。以下是數據存儲⽰示例：
媒體編號-媒體cookie=>supperid
supperid => { age=>年齡段編碼，gender=>性別編碼，geo=>地理位置編碼 }
imei or idfa => { age=>年齡段編碼，gender=>性別編碼，geo=>地理位置編碼 }
顯然PC數據需要存儲兩種key=>value還有key=>hashmap，⽽而Device數據需要存儲⼀一種
key=>hashmap即可。
存儲吃緊的一個重要原因在於每天會有很多新數據入庫，所以及時清理數據尤為重要。主要方法就是發現和保留熱數據淘汰冷數據。
網民的量級遠遠達不到幾十億的規模，id有一定的生命周期，會不斷的變化。所以很大程度上我們存儲的id實際上是無效的。而查詢其實前端的邏輯就是廣告曝光，跟人的行為有關，所以一個id在某個時間窗口的（可能是一個campaign，半個月、幾個月）訪問行為上會有一定的重復性。
數據初始化之前，我們先利用hbase將日誌的id聚合去重，劃定TTL的范圍，一般是35天，這樣可以砍掉近35天未出現的id。另外在Redis中設置過期時間是35天，當有訪問並命中時，對key進行續命，延長過期時間，未在35天出現的自然淘汰。這樣可以針對穩定cookie或id有效，實際證明，續命的方法對idfa和imei比較實用，長期積累可達到非常理想的命中。
Hash表空間大小和Key的個數決定了沖突率（或者用負載因子衡量），再合理的范圍內，key越多自然hash表空間越大，消耗的內存自然也會很大。再加上大量指針本身是長整型，所以內存存儲的膨脹十分可觀。先來談談如何把key的個數減少。
大家先來了解一種存儲結構。我們期望將key1=>value1存儲在redis中，那麼可以按照如下過程去存儲。先用固定長度的隨機散列md5(key)值作為redis的key，我們稱之為BucketId，而將key1=>value1存儲在hashmap結構中，這樣在查詢的時候就可以讓client按照上面的過程計算出散列，從而查詢到value1。
過程變化簡單描述為：get(key1) -> hget(md5(key1), key1) 從而得到value1。
如果我們通過預先計算，讓很多key可以在BucketId空間里碰撞，那麼可以認為一個BucketId下面掛了多個key。比如平均每個BucketId下面掛10個key，那麼理論上我們將會減少超過90%的redis key的個數。
具體實現起來有一些麻煩，而且用這個方法之前你要想好容量規模。我們通常使用的md5是32位的hexString（16進制字元），它的空間是128bit，這個量級太大了，我們需要存儲的是百億級，大約是33bit，所以我們需要有一種機制計算出合適位數的散列，而且為了節約內存，我們需要利用全部字元類型（ASCII碼在0~127之間）來填充，而不用HexString，這樣Key的長度可以縮短到一半。
下面是具體的實現方式
參數bit決定了最終BucketId空間的大小，空間大小集合是2的整數冪次的離散值。這里解釋一下為何一個位元組中只有7位可用，是因為redis存儲key時需要是ASCII（0~127），而不是byte array。如果規劃百億級存儲，計劃每個桶分擔10個kv，那麼我們只需2^30=1073741824的桶個數即可，也就是最終key的個數。
碎片主要原因在於內存無法對齊、過期刪除後，內存無法重新分配。通過上文描述的方式，我們可以將人口標簽和mapping數據按照上面的方式去存儲，這樣的好處就是redis key是等長的。另外對於hashmap中的key我們也做了相關優化，截取cookie或者deviceid的後六位作為key，這樣也可以保證內存對齊，理論上會有沖突的可能性，但在同一個桶內後綴相同的概率極低(試想id幾乎是隨機的字元串，隨意10個由較長字元組成的id後綴相同的概率*桶樣本數=發生沖突的期望值<<0.05,也就是說出現一個沖突樣本則是極小概率事件，而且這個概率可以通過調整後綴保留長度控制期望值)。而value只存儲age、gender、geo的編碼，用三個位元組去存儲。
另外提一下，減少碎片還有個很low但是有效的方法，將slave重啟，然後強制的failover切換主從，這樣相當於給master整理的內存的碎片。
推薦Google-tcmalloc， facebook-jemalloc內存分配，可以在value不大時減少內存碎片和內存消耗。有人測過大value情況下反而libc更節約。
1）kv存儲的量級必須事先規劃好，浮動的范圍大概在桶個數的十到十五倍，比如我就想存儲百億左右的kv，那麼最好選擇30bit 31bit作為桶的個數。也就是說業務增長在一個合理的范圍（10 15倍的增長）是沒問題的，如果業務太多倍數的增長，會導致hashset增長過快導致查詢時間增加，甚至觸發zip-list閾值，導致內存急劇上升。
2）適合短小value，如果value太大或欄位太多並不適合，因為這種方式必須要求把value一次性取出，比如人口標簽是非常小的編碼，甚至只需要3、4個bit（位）就能裝下。
3）典型的時間換空間的做法，由於我們的業務場景並不是要求在極高的qps之下，一般每天億到十億級別的量，所以合理利用CPU租值，也是十分經濟的。
4）由於使用了信息摘要降低了key的大小以及約定長度，所以無法從redis裡面random出key。如果需要導出，必須在冷數據中導出。
5）expire需要自己實現，目前的演算法很簡單，由於只有在寫操作時才會增加消耗，所以在寫操作時按照一定的比例抽樣，用HLEN命中判斷是否超過15個entry，超過才將過期的key刪除，TTL的時間戳存儲在value的前32bit中。
6）桶的消耗統計是需要做的。需要定期清理過期的key，保證redis的查詢不會變慢。
人口標簽和mapping的數據100億條記錄。
優化前用2.3T，碎片率在2左右；優化後500g，而單個桶的平均消耗在4左右。碎片率在1.02左右。查詢時這對於cpu的耗損微乎其微。
另外需要提一下的是，每個桶的消耗實際上並不是均勻的，而是符合多項式分布的。
上面的公式可以計算桶消耗的概率分布。公式是唬人用的，只是為了提醒大家不要想當然的認為桶消耗是完全均勻的，有可能有的桶會有上百個key。但事實並不沒有那麼誇張。試想一下投硬幣，結果只有兩種正反面。相當於只有兩個桶，如果你投上無限多次，每一次相當於一次伯努利實驗，那麼兩個桶必然會十分的均勻。概率分布就像上帝施的魔咒一樣，當你面對大量的桶進行很多的廣義的伯努利實驗。桶的消耗分布就會趨於一種穩定的值。接下來我們就了解一下桶消耗分布具體什麼情況：
通過采樣統計
31bit（20多億）的桶，平均4.18消耗
100億節約了1.8T內存。相當於節約了原先的78%內存，而且桶消耗指標遠沒有達到預計的底線值15。
對於未出現的桶也是存在一定量的，如果過多會導致規劃不準確，其實數量是符合二項分布的，對於2 30桶存儲2 32kv，不存在的桶大概有（百萬級別，影響不大）：
Math.pow((1 - 1.0 / Math.pow(2, 30)), Math.pow(2, 32)) * Math.pow(2, 30);
對於桶消耗不均衡的問題不必太擔心，隨著時間的推移，寫入時會對HLEN超過15的桶進行削減，根據多項式分布的原理，當實驗次數多到一定程度時，桶的分布就會趨於均勻（硬幣投擲無數次，那麼正反面出現次數應該是一致的），只不過我們通過expire策略削減了桶消耗，實際上對於每個桶已經經歷了很多的實驗發生。
總結：信息摘要在這種場景下不僅能節約key存儲，對齊了內存，還能讓Key按照多項式分布均勻的散列在更少量的key下面從而減少膨脹，另外無需在給key設置expire，也很大程度上節約了空間。
這也印證了時間換空間的基本理論，合理利用CPU租值也是需要考慮的。
關注分布式存儲技術以及分布式計算方法