雲端環境下應用Google電子試算表於分散式儲存架構平台之研究 - 政大學術集成

‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 國立政治大學資訊管理學系. 碩士學位論文. 指導教授：楊建民博士. 雲端環境下應用 Google電子試算表. 於分散式儲存架構平台之研究. A Study of Distributed Storage Architecture Platform. by Using Google Spreadsheet in Cloud Environment. 研究生：連偉志. 中華民國 103年 1月. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. I. 摘要. 資訊科技不斷進步，近年來使用雲端儲存和運算服務之人數漸多，更多的企. 業盡可能保留全數資料以進行更強大的分析來預測產業環境的變動。但資料成長. 速度極快，過去兩年所建立的資料即為當今世界總量的 90%。而現今雲端服務收. 費與存放於雲的資料量成正比，許多中小企業在成本和資訊安全考量下，可能會. 放棄雲端服務供應商所提供的解決方案。. 本研究利用 Google 電子試算表做為資料庫能大量儲存資料且使用空間免費. 之優勢以及本地端資料庫安全性高、小量資料存取速度極快的優點，結合兩者並. 配合本研究開發之資料處理相關模組，提出並且實作驗證一個分散式儲存架構平. 台，並以商店銷售商品之相關流程為平台應用案例，將資料分割儲存在本地與雲. 端兩端之資料庫中，以達到節省本地資料庫之儲存空間，亦能將非關鍵資料大量. 存放至 Google 電子試算表之優點。. 於案例應用中，本研究成功驗證此雲端分散式儲存架構平台之可行性與應用. 層面廣，除解決原本 Google 試算表作為資料庫之資料查詢限制之問題外，並於. 資料切割分散儲存的過程額外發現此種儲存於雲的方式亦能達到部分資訊安全，. 且在資料量越大的情況下，能比傳統本地端資料庫之儲存方式省下更多空間。此. 平台架構提供企業一個進入門檻較低且成本較低的分散式儲存平台，在資料庫備. 份及後援上線上也有快速上線的優勢。. 關鍵字: Google 電子試算表、海量資料、分散式儲存架構、雲端儲存. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. II. Abstract. Continuing innovation in information technology, using cloud storage and cloud. computing services, the number of users gradually become more in the past years.. More and more Small and Medium Enterprises (SME) try to keep all the information. in order to carry out a more powerful analysis to predict changes in the industrial. environment. With the rapid growth of data, the data in the past two years to establish. the total world today, accounting for more than 90%. And today, cloud service charges. and the amount of data stored in the cloud is proportional to the cost. Base on cost and. information security consideration, many SME may abandon the cloud service. providers to provide solutions.. In this study, we use the advantages of Google spreadsheets: huge amount of. storage, and the advantages of local database: higher security, access fast on small. amount of data. Combine both of two advantages and coordinate the data processing. module of this study. This study proposes and inspects a distributed storage. architecture platform, with shops selling merchandise flow as a platform for. application cases, dividing data stored in local and cloud database, to save local. storage space, and to reach a large number of non-critical data stored in Google. spreadsheets advantages.. In the application cases, this study successfully validated cloud platform for. distributed storage architecture and the application of the feasibility of wide-ranging,. in addition to solving the original Google Spreadsheets data as the database query. limit issues, and cutting dispersion in the data storage process additional findings of. this storage method can achieve part of information security, and in the case of the. larger amount of data can be compared to the traditional local database storage. method saves more space. This platform architecture provides SME lower barriers. to entry and low cost of distributed storage platform, database backup and backup. easy backup on the line also has the advantage of fast on-line backup.. Keyword: Google Spreadsheets, Big Data, Distributed Storage Architecture,. Cloud Storage. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. III. 目錄. 第一章緒論 ................................................................................................................. 1. 第一節研究背景.................................................................................................. 1. 第二節研究動機.................................................................................................. 2. 第三節研究目的.................................................................................................. 3. 第四節研究架購.................................................................................................. 4. 第二章文獻探討 ......................................................................................................... 5. 第一節資料庫管理系統...................................................................................... 5. 一、集中式資料庫管理系統........................................................................ 6. 二、分散式資料庫管理系統........................................................................ 7. 第二節資料儲存模式........................................................................................ 11. 一、關聯式資料儲存模式.......................................................................... 11. 二、實體關係模型...................................................................................... 12. 第三節 Google Drive 及 Google Spreadsheets .................................................. 14. 一、Google Spreadsheets ............................................................................ 16. 二、Google Spreadsheets API ..................................................................... 18. 三、電子試算表資料操作之開放源碼套件.............................................. 21. 第三章研究設計 ....................................................................................................... 25. 第一節分散式儲存架構平台架構.................................................................... 25. 一、分散式儲存架構平台整體架構圖...................................................... 26. 二、模組簡介.............................................................................................. 29. 第二節資料分級儲存機制................................................................................ 30. 一、分散式儲存架構平台正規化.............................................................. 31. 二、雲端資料庫設計.................................................................................. 32. 三、本地端資料庫設計.............................................................................. 33. 第四章分散式儲存架構平台建置 ........................................................................... 36. 第一節分散式儲存架構平台運作機制............................................................ 37. 一、使用定位.............................................................................................. 37. 二、運作機制.............................................................................................. 37. 第二節分散式儲存架構平台整體架構............................................................ 42. 一、基礎建設層.......................................................................................... 44. 二、服務介面層.......................................................................................... 45. 三、中央控管層.......................................................................................... 45. 四、海量資料儲存層.................................................................................. 47. 第五章便利商店案例應用於平台展示 ................................................................... 48. 第一節商店營運銷售庫存應用案例................................................................ 48. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. IV. 第二節案例分散式儲存架構平台分析與設計................................................ 49. 一、本地端資料庫設計.............................................................................. 51. 二、雲端資料庫設計.................................................................................. 52. 第三節案例分散式儲存架構平台展示............................................................ 53. 一、購買行為產生發票之資料儲存.......................................................... 53. 二、使用者查看自身發票資訊.................................................................. 54. 三、便利商店產生銷售報表...................................................................... 56. 四、空間使用比例比較.............................................................................. 57. 第六章未來展望與結論 ........................................................................................... 58. 第一節結論........................................................................................................ 58. 第二節未來研究方向與建議............................................................................ 59. 參考文獻 ..................................................................................................................... 60. 一、英文文獻...................................................................................................... 60. 二、中文文獻...................................................................................................... 63. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. V. 圖目錄. 圖 2-1 集中式資料庫管理系統 .................................................................................. 7. 圖 2-2 分散式資料庫管理系統 .................................................................................. 8. 圖 2-3 微軟的範例關聯式資料庫圖表 .................................................................... 11. 圖 2-4 範例 E-R Model 圖 ........................................................................................ 12. 圖 2-5 檔案文件權限修改示意圖 ............................................................................ 17. 圖 2-6 試算表資料圖像化範例圖 ............................................................................ 19. 圖 2-7 動態查詢回應圖 ............................................................................................ 20. 圖 3-1 分散式儲存架構平台整體架構圖 ................................................................ 26. 圖 3-2 分散式儲存架構平台服務介面層 ................................................................ 27. 圖 3-3 分散式儲存架構平台中央控管層 ................................................................ 29. 圖 3-4 資料分級儲存機制 ........................................................................................ 31. 圖 3-5 資料切割 ........................................................................................................ 33. 圖 3-6 原關聯式儲存方法 ........................................................................................ 34. 圖 3-7 關聯儲存於本地端資料庫表示圖 ................................................................ 34. 圖 3-8 資料分開儲存於兩張電子試算表表示圖 .................................................... 34. 圖 4-1 試算表資源配置控管圖 ................................................................................ 38. 圖 4-2 備援檔案備份上線流程圖 ............................................................................ 39. 圖 4-3 資料分級控管示意圖 .................................................................................... 40. 圖 4-4 海量查詢資料機制流程圖 ............................................................................ 42. 圖 4-5 整體架構與各種服務介面關係示意圖 ........................................................ 43. 圖 4-6 兩端基礎建設層 ............................................................................................ 44. 圖 4-7 資料操作相關架構流程 ................................................................................ 46. 圖 4-8 海量資料儲存層資料控管示意圖 ................................................................ 47. 圖 5-1 案例應用模擬流程示意圖 ............................................................................ 48. 圖 5-2 應用案例兩端資料庫設計關聯圖 ................................................................ 50. 圖 5-3 商品資訊資料表 ............................................................................................ 51. 圖 5-4 發票基本資料表 ............................................................................................ 51. 圖 5-5 雲端關聯資料表 ............................................................................................ 51. 圖 5-6 案例雲端資料表 ............................................................................................ 52. 圖 5-7 發票示意圖 .................................................................................................... 53. 圖 5-8 消費者購買模擬與發票資料儲存流程圖 .................................................... 54. 圖 5-9 使用者查看消費月報表 ................................................................................ 55. 圖 5-10 便利商店銷售報表圖 .................................................................................. 56. 圖 5-11 傳統儲存與分散式儲存架構在便利商店案例下之資料量比較圖 .......... 57. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. VI. 表目錄. 表 2-1 集中式與分散式資料庫管理系統優缺點比較表 ........................................ 10. 表 2-2 Google Drive 版本年表 ............................................................................... 15. 表 2-3 免費雲端儲存服務提供商 ............................................................................ 16. 表 2-4 Google 電子試算表 API主要功能表 ......................................................... 18. 表 2-5 Zend Gdata 套件支援 Google 服務表 ......................................................... 24. 表 4-1 SPQuery()和 catch_td()部分程式碼示意表 ................................................ 41. 表 5-1 應用案例發票資訊資料庫欄位名稱表 ........................................................ 49. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 1. 第一章緒論. 第一節研究背景. 隨著資訊科技持續的進步，無論是硬體技術或是功能逐漸強大的軟體，都使. 企業在處理及保留資料和資訊上有了更多的選擇。為保留資料以便分析或預測得. 到對企業有用的資訊，企業過去被儲存成本限制而挑選重要資料保留的情況已漸. 漸改變。現今商業環境複雜變動快速，影響企業生存的因素變多，更多的企業盡. 可能保留所有資料以便進行更強大的分析來預測產業環境的變動。. 資料成長速度極快，每日約 2.5 百萬兆位元組的資料，數量之多，光是過去. 兩年所建立的資料即為當今世界總量的 90%。這些資料來源廣泛，像是用於蒐集. 氣候資訊的感應器、社群網站的文章、數位圖片與影像、採購交易記錄和行動電. 話 GPS 訊號等 (IBM 2013)。資料成長迅速，IDC 更將 2013 年訂為海量資料 (Big. Data)實踐元年，可見 Big Data 熱潮持續增溫，但也顯現出 Big Data 的分析應用. 環境尚未成熟 (iThome 2013)。Big Data 時代來臨，成功企業面臨轉型時，面對. Big Data 時代，企業如何運用這樣大量的數據，來預估、分析，藉以成長和保留. 客戶，如何正確使用和儲存資料已經成為企業重要經營的其中一種目標 (錢大群. 2013)。. 雲端服務由知名網路公司 Amazon.com 率先在 2006 年推出，接著 Google 在. 2007 年提出雲端運算概念，同年 IBM 和 Google 為了減少分散式運算在學術研究. 上的成本，開始在美國大學校園中推廣雲端運算計畫，2008 年 Google 在台灣啟. 動「雲端運算學術計畫」(張德厚 2008)，接著 Dell 電腦公司在美國專利商標局. 申請雲端運算（Cloud Computing）的申請檔案中稱，雲端運算是「在資料中心. 與巨型規模的運算環境中，為他人提供電腦硬體客製製造」 (新浪科技 2008)。. 而到了 2010 年，任何人都能自行建立且提供雲端運算服務的 Open Stack 開放專. 案由 NASA 和 Rackspace、AMD、Intel、Dell 等合作進行 (Rackspace.com 2010)，. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 2. 後來 Microsoft 和 Cisco 的進入支援以及 Apache Hadoop 專案，讓雲端發展有更. 大的應用方向，而現今無論是雲端儲存或是運算發展都有了一定的穩定性。企業. 期望能夠保留更多的資料，但資料成長速度往往超出企業原本預期，快速的成長. 讓尚未擁有像是 Hadoop人才的中小企業，為了成本以及訓練人才的時間考量下，. 開始選擇使用成本較低的雲端儲存空間來進行海量資料的儲存。根據 2010 年一. 項研究調查指出，公用的雲端儲存服務正快速成為對企業具吸引力的選擇，IDC. 儲存分析師 Brad Nisbet 指出，這種「成本效益高、使用方式友善」解決方案服. 務的提供，讓市場中有越來越多的中小企業樂於採用雲端儲存 (Steve Wexler. 2010)。. 知名硬碟製造商 Seagate 成立於 1979 年，在 29 年後的 2008 年完成 10 億顆. 硬碟出貨里程碑，接著僅僅用了 4 年的時間便在 2012 年達到第 2 個 10 億顆出貨. 量，全因雲端儲存服務和雲端運算發展快速所賜 (VR-ZONE.com 2013)。而其它. 雲端儲存供應商如 Dropbox5 年內便讓使用人數突破 1 億人次 (Dropbox 2012)，. 而Microsoft的Sky drive也達到6,000萬的使用人數 (Microsoft SharePoint 2012)。. 搜尋引擎龍頭 Google 所整合推出的 Google Drive來勢洶洶使用率與 Sky drive不. 相上下，由此可知雲端儲存服務正在快速成長中，而各中小企業也面臨如何選擇. 適合自己的服務方案的難題。. 第二節研究動機. 企業對於各種雲端儲存方案固然可以做出適合的選擇，但許多因素使得企業. 對於存放在雲端上的資料感到憂心，雲端儲存資料和應用更是需要投入許多訓練. 成本，對於中小企業來說亦是額外的人力與資金負擔，更何況還需承擔失敗的所. 有風險。如果是剛創立的企業則更不會考慮，基於成本和人力資源考量，會使用. 傳統的儲存解決方案，等到企業逐漸成長後再考慮更佳的解決方案。Google 在. 2006 年推出電子試算表後，於 2012 年將其整合至 Google Drive 中，隨著使用人. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 3. 數增加，Google 提供對於電子試算表做更多的資料操作服務，例如試算表可以. 作為小型資料庫，或是成為企業內部互相共有編輯的重要文件檔案，但多數應用. 都較難表現出電子試算表的最大優點，也就是大量的儲存欄位、簡易的備份方式、. 安全性高且容易使用等。加上由於 Google 將部分功能限制，例如官方查詢語言. 套件所能查詢到的資料最多 5 筆、使用套件在速度上會有疑慮等。因此在許多限. 制下，使得電子試算表目前多被侷限在簡單的應用上。. 基於上述，本研究將利用 Google 電子試算表的優點加上本地資料庫快速且. 安全性高等優點，提出一種雲端分散式儲存架構平台並且實作，使得企業在海量. 資料的儲存上能有另一種較低成本和低進入門檻的選擇，而此選擇亦兼有安全以. 及速度、維護及損害復原容易等優點。. 第三節研究目的. 基於雲端儲存運用對於中小企業進入成本高，且多數企業不願將核心資料儲. 存至雲端空間的疑慮。本研究結合本地資料庫優點與 Google 電子試算表作為大. 量資料儲存優點，且根據以上動機，本研究以海量資料儲存為概念，以分散式儲. 存架構為基礎，建構一進入門檻較低、較有彈性且成本較低的雲端分散式儲存平. 台。透過此平台，可以做海量資料的分散式儲存且兼具資料安全的成效，故本研. 究目的如下列項目所示。. 一、提出一個由 Google 電子試算表及 MySQL 資料庫組合而成的雲端分散式儲. 存架構模型。. 二、本研究將開發新的結構化查詢語言模組以解決使用Google電子試算表作為. 海量資料資料庫資料處理上的問題。. 三、本研究將以商店營運銷售庫存等資料來實作且透過中央控制管理層來整合. 資料內容之可行性。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 4. 第四節研究架購. 一、緒論. 說明本篇論文的研究背景、動機、目的與整體論文架構。. 二、文獻探討. 說明與本研究相關的文獻資料。包含分散式與集中式資料庫架構探討、資料. 儲存模式探討以及本研究所使用的 Google 相關技術與工具。. 三、研究設計. 說明如何將本地資料庫的優點與雲端儲存的優點透過本研究分散式儲存架. 構設計來結合運用。且說明如何將資料安全的分散儲存至兩端並透過分散式. 儲存平台的機制整合呈現至使用端中。. 四、分散式儲存架構平台建置. 說明在雲端環境下如何利用 Google 電子試算表與本地端資料庫實作分散式. 儲存平台，並說明開發步驟。. 五、平台實作與展示. 在說明平台的建置過程和方法後，將以商店營運銷售的流程為範例來做為平 . 台的使用展示。. 五、結論與建議. 根據本研究之研究結果與過程，歸納整理出本研究的結論，且提出未來研究. 方向與建議，以作為後續研究的參考。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 5. 第二章文獻探討. 本章將先探討資料庫管理系統應硬體架構不同所分成的集中式與分散式架. 構之優缺點比較及相關研究，接著探討關聯式資料庫儲存模式的優點以及相關研. 究，最後介紹本研究所使用工具 Google 電子試算表之介紹。. 第一節資料庫管理系統. 自古人類就有保存資料和資訊的習慣，從沒有文字的結繩記事到文字發明後. 人們開始記錄發生的種種故事。資料和資訊的保存也隨著時代的演化進步而逐漸. 延長可以被保存的年限，從易受外力影響腐爛的竹簡、紙本到磁帶及光碟的數十. 年，而如今沒有外力破壞的硬碟幾乎沒有期限的限制下，使得更多的資料和資訊. 能夠被保存。. 原本資料和資訊因為物理空間和成本而被企業挑選保存，但在電腦資料庫出. 現後，新的保存方式不受物理空間影響，成本也逐漸降低，企業電腦資料庫起源. 於 1960 年，此時使用電腦保存資料對私營企業是能降低成本的方法。在這 10. 年中，有 2 種資料模型，一種被稱為 CODASYL 的網路模型和被稱為 IMS 的層. 次結構模型。接著另一個被成功運用在商業上的資料庫系統，SABRE 系統，由. IBM 幫助美國航空管理並保留資料。至此逐漸開啟許多對於資料庫系統的研究. 以及商業運用。. 資料庫管理系統 (Database Management System, DBMS)，是一組程式，提供. 儲存、修改以及從資料庫中提取資料。能使用戶在同一時間不同地點對於資料庫. 進行新增、修改、查詢、分析和儲存資料等動作，且用戶無須檢視任何後端程式. 碼 (黃三益 2012)。一個群組用戶能夠透過查詢和報表工具來存取資料，這些都. 是組成 DBMS 的一部分。一個 DBMS 通常支援結構化的查詢語言 (Structured. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 6. Query Language, SQL)，這是有效的高級程式語言，對於資料庫的查詢做了許多. 簡化以及效能上的改進。資料庫查詢語言也簡化了資料庫的組織以及檢索和顯示. 資訊，其中有許多研究自 1980 年起對於查詢語言的效能及最佳化有深入的探討. 及貢獻，如 (Jarke & Koch, 1984) 針對資料庫系統，而 (Alashqur, Su, & Lam, 1989). 則是針對物件導向型資料庫，(McHugh & Widom, 1999)則是對於 xml 型態的資料. 庫，SQL 在眾多技術改良後成為標準化且有效率的資料庫查詢語言，讀者能夠. 自行參閱文獻，本研究將不贅述。. DBMS 提供資料存取控制，資料完整性，以及故障後從備份文件中復原資料. 庫，以及維護資料庫的安全性。而其中對於資料庫系統的分類，以處理資料地點. 來區分可被可分為:集中式資料庫管理系統、分散式資料庫管理系統兩種主要架. 構。無論何種資料庫管理系統大多擁有下列優點，以達到對資料的管理性. (Connolly & Begg, 2004)。. 一避免資料重覆 (Data Redundancy). 二避免資料不一致 (Inconsistency). 三數據共享 (Multi-User). 四妥善安全性與完整性控制 (Security Constraints and Integrity Constraints). 五資料獨立性 (Data Independence). 一、集中式資料庫管理系統. 最傳統的資料處理方式，其所有工作任務在同一伺服器或主機中完成，而終. 端機或用戶端電腦只負責接收及顯示資料，並無負責任何資料的處理。資料的處. 理和儲存在同一地點。其架構如下圖 2-1。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 7. 圖 2-1 集中式資料庫管理系統. 資料來源: 本研究整理. 集中式資料庫管理系統的管理方式有許多優點，例如資料備份容易、保有較. 高的資訊安全、單一資料出入口管理容易、節省存到其它異地的成本以及資料在. 小量的情況下存取速度快 (Ramakrishnan & Gehrke, 2000)，但當然也有其它缺點，. 例如資料量大時，存取速度會變慢，或者是當系統故障時，所有功能都無法使用，. 故近年來在海量資料成長速度快速增加下，使用分散式資料庫管理系統的情況逐. 漸多於集中式資料庫管理系統，但集中式資料庫管理系統中某些優點卻又是分散. 式管理系統所無擁有的，在取捨上十分困難。. 二、分散式資料庫管理系統. 根據(Elmasri, 2008)，首先我們將分散式資料庫以及分散式資料庫管理系統. 定義如下且其基本架構如下圖 2-2。. (一) 分散式資料庫定義 (Distributed Database, DDB):指資料在邏輯上屬於同. 一資料庫系統，但實際上實體資料卻是分散儲存在不同硬體位置上，並. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 8. 且透過網路互相連接。. (二) 分散式資料庫管理系統定義(Distributed Database Management System,. DDBMS):管理分散式資料庫的軟體，提供管理機制，對於使用者來說. 並不需要了解其中細節，依然是一個完整的資料庫系統，具有透通性. (Transparent)。. 圖 2-2 分散式資料庫管理系統. 資料來源: 本研究整理. 分散式管理資料庫系統在管理大量資料上有較大的優勢，關於分散式資料庫. 管理系統的效能研究像是 (Ries, 1970) 就指出在高速網路的情況下，使用分散式. 資料庫管理系統的並行處理是能增加效能和效率的。而建立分散式資料庫之 12. 項規則如下所示，其中幾項也是分散式資料庫的優點 (Date & Darwen, 1987)。而. 分散式系統的主要缺點有系統複雜、分散儲存成本高昂、維護不易、缺乏標準等. 以及在 SQL 查詢上 JOIN 語法會影響效率的問題。而本研究在探討完兩種的優缺. 點後整理比較如下表 2-1。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 9. (一) 本地端自主性(Local autonomy):在分散式系統中的節點應該是獨立. (二) 不依賴中央節點(No reliance on a central site):單一的中央站點可能會成. 為單點故障，也可能成為瓶頸，影響整個系統。. (三) 連續性運作(Continuous operation): 一個分散式資料庫系統應該永遠不. 需要停機時間。. (四) 位置獨立和通透性(Location independence and transparency):使用者存取. 別台主機所提供的資料時，並不會對其它主機造成影響。. (五) 分割獨立性(Fragmentation independence):關聯資料表可以被切割並儲. 存在不同的節點中。. (六) 複製獨立性(Replication independence):資料能透過網路被多個節點複. 製。. (七) 分散式查詢處理(Distributed query processing). (八) 分散式交易管理(Distributed transaction management). (九) 硬體獨立性(Hardware independence). (十) 作業系統獨立性(Operating system independence). (十一) 網路獨立性(Network independence). (十二) DBMS 獨立性: 一個理想的分散式數據庫管理系統必須能夠支援在. 不同的節點上運行不同的 DBMS 系統。. . ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 10. 表 2-1 集中式與分散式資料庫管理系統優缺點比較表. 集中式資料庫管理系統分散式資料庫管理系統. 優點.  備份容易.  資料保密性高.  系統簡單. 優點.  可靠性高、彈性和擴充性高.  分享與區域自主性.  本地端自主性.  不依賴中央節點.  連續性運作.  位置獨立和通透性.  分割、複製獨立性.  分散式查詢處理.  分散式交易管理.  硬體、作業系統、網路獨立性.  DBMS 獨立性. 缺點.  資料量大時，存取速度會變慢.  系統故障，所有功能都無法使. 用.  本地儲存量大時，硬體成本高. 缺點.  資料的保密性與安全性受到威脅.  系統複雜.  分散儲存成本高昂.  維護不易.  備份和還原困難. 資料來源:本研究整理. 本研究選用 Google 電子試算表作為雲端資料庫的原因之一也因其備份和還. 原容易，配合分散式儲存架構應用，將重要關鍵資料儲存在主要伺服器，而其它. 海量資料儲存在雲端，使得此架構能兼具兩種資料庫管理系統的優點，同時也避. 免其缺點的發生，其資料儲存機制將於第三章說明。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 11. 第二節資料儲存模式. 上個小節探討了兩種不同硬體架構下的資料庫管理系統優缺點，而資料依照. 儲存模式的不同亦可分為多種，其中 1970 年起至今已經十分成熟且多為現今資. 料庫使用的關聯式模式 (Codd, 1970)，在關聯型資料模型中，用二維表格表示資. 料庫中的資料。這些表格稱為關聯。現今 DBMS 使用不同的資料庫模型追蹤實. 體、屬性和關聯。在個人電腦、大型電腦和主機上應用最廣泛的資料庫管理系統. 亦是關聯型 DBMS (Laudon & Traver, 2011)。本節文獻探討將探討關聯式儲存模. 式並成為本研究後面研究設計的設計精神之一。. 一、關聯式資料儲存模式. 此模式在 1970 年由當時在 IBM 工作的 Edgar Codd 提出，用來取代缺乏”搜. 尋”方法的 Navigational 模型，其核心概念為將單筆紀錄的資料拆開並存放置於. 多張資料表中，以解決資料重複的問題，且能確保資料在異動時的完整性. (Integrity) 與一致性 (Consistency)，其資料表有所謂主鍵 (Primary key)，在資料. 表中主鍵為唯一且不得重複的鍵，而外部鍵 (Foreign key) 即是用來與其它資料. 表作關聯的鍵。一個關聯式資料庫的資料表表示如下圖 (Microsoft ORM 2002)。. 圖 2-3 微軟的範例關聯式資料庫圖表. 資料來源: Microsoft. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 12. 二、實體關係模型. 實體關係模型（Entity-Relationship Model)，簡稱 E-R Model，是一套用來設. 計資料庫的工具，它運用了真實世界中事物與關係的觀念，來解釋資料庫中抽象. 的資料架構。實體關係模型利用圖形的方式來表示資料庫的概念設計，對於呈現. 資料庫的架構設計能清楚明瞭且有助於資料庫式設計團隊的討論和溝通，與關聯. 式資料庫的設計有極大的關係，其主要元件和專有名詞解釋即定義整理如下面幾. 張表格，而下圖 2-4 則為範例 E-R Model 圖 (Chen, 1976)。. 圖 2-4 範例 E-R Model 圖. 資料來源: Chou-it.com. (一) 實體. 專有名詞符號說明. 強勢實體(Strong entity). 可以獨立存在的如商品資料。. 弱勢實體(Week entity). 強勢實體不存在時消失，如製造日期。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 13. (二) 屬性. 專有名詞符號說明. 單一(Simple). 複合(Composite). 電腦是由許多其. 它實體組成如硬. 碟、顯示卡、主機. 板…等。. 單值(Simple-value). 多值(Multi-value) . 人能擁有多部電. 腦。. 基本(Base). 衍生(Derived). 電腦這個實體會. 衍生使用了幾年. 的問題，於是已使. 用年便是衍生屬. 性。. 鍵值(Key). 複合鍵(Compound Key). 編號可能是電腦. 實體的唯一主鍵。. 而航班則擁有多. 個鍵向外關聯。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 14. (三) 關係基數. 項目表示圖. 一對一. 一對多. 多對多. 標準資料查詢語言是一種基於關聯式資料庫的查詢語言，這種語言執行對關. 聯式資料庫中資料的檢索和操作，前面章節有提到幾項較為知名的標準資料查詢. 語言研究 (w3schools.com SQL 2013)。關聯式資料庫搭配 E-R Model 在使用上以. 資料少的情況下有較高的存取速度與安全性，本研究將以關聯資料儲存模式為分. 散儲存資料切割的精神作為平台之研究設計。. 第三節 Google Drive 及 Google Spreadsheets. 近年來由於雲端服務的發展逐漸成熟穩定，許多企業開始接受並使用雲端服. 務，科技市調機構 Gartner 全球雲端市場預估，至 2012 的全球千大企業中，80 %. 購買雲端服務，30 % 採購雲端基礎設施 (行政院經建會 2010)。成立不到 6 年. 的Dropbox在 2012年 12月 13日宣布用戶達到一億，更證明此市場迅速擴大中。. 而其它類似的雲端儲存服務還有微軟 SkyDrive、Apple iCloud、Amazon S3 Simple. Storage Service 以及由搜尋引擎龍頭 Google Inc.所開發的 Google Drive。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 15. Google Drive 為 Google Inc.於 2012 年 4 月 24 號發表並逐漸開放給用戶使用. 的雲端免費儲存空間，前身為 Google Docs 服務，其釋放版本和演進過程請見下. 表 2-2。在空間的配置上，雲端硬碟部分給予每位用戶 5GB 的免費空間，電子郵. 件服務上給予 10GB 的信箱儲存上限 (Google Drive 2013)。而幾種雲端儲存空間. 免費的大小額度如下表 2-3。. 表 2-2 Google Drive 版本年表. 時間事項. 2006/06/06 Google Spreadsheets 確定成為第一個 Google Docs 中的程式. 2007/02 Google Docs 開始開放給 Google Apps 使用者使用. 2007/09/17 Google 發表了有關 Google Docs 的展示影片. 2009/07/06 Google Docs 從 Google Apps 中被獨立取出成為測試版本. 2010/01/13 Google Docs 配置 1 GB 的可用空間且允許任何類型的文件，而. $0.25/GB 為額外的儲存費用計算方式. 2010/03/07 Google 收購 DocVerse 在線文件檔案協作公司. 2010/04 支援 Microsoft Office 兼容的文件格式，如 Word、Excel 和. PowerPoint. 2011/09/29 支援 HTML5 Web 應用程式的線下查看. 2012/04/26 Google 推出 Google Drive 取代 Google Docs，並結合了所有的文. 檔功能與改進的儲存功能. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 16. 表 2-3 免費雲端儲存服務提供商. 名稱免費大小. Dropbox 2GB. Google Drive 5GB. 微軟 SkyDrive 7GB. Apple iCloud 5GB. Mega Cloud 5GB. 資料來源: 本研究整理. 一、Google Spreadsheets. Google Spreadsheets (Google 電子試算表)，是由 Google Labs 於 2006 年 6 月. 6 號起上線的一個免費試算表程式，最初僅開放部分用戶，而現今已開放予所有. Google 用戶使用。其主要技術來源是 Google Inc.所收購的 2Web Technologies 公. 司產品: XL2Web。電子試算表大部分的核心功能類似於現今微軟作業系統中的. Office Excel，可使用多種數學函數及將資料轉化成簡單易懂的圖表方式作為呈現，. 而其最大優點是支援多個使用者線上同時編輯文件內容，且檔案擁有者能對於該. 檔案文件進行權限的控管如圖 2-5。Google 官方發布聲明主要功能如下 (Google. Drive 2006):. (一) 提高可存取性: . 電子試算表能讓所有使用者從任一地用戶端存取使用，且檔案文件被安. 全的儲存在 Google 上，使用電子試算表無需在本地用戶端安裝任何軟體。. (二) 即時的協作模式:. 支援多個使用者同時對於電子試算表進行編輯、修改及更新的動作，且. 檔案文件能經由分享的控管機制來達到基本的權限的控制。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 17. (三) 簡易的資料表格匯入方式:. 使用者能輕易地從任一地電腦桌面匯入格式為.ODS、.CSV、.TXT、.TAB. 及檔案格式為 Office Excel 的.XLS、.XLSX 檔案。. 圖 2-5 檔案文件權限修改示意圖. 資料來源: 本研究整理. 目前電子試算表除了線上試算表的應用之外，較為有趣的應用即是將電子試. 算表作為網站平台後端的資料庫，其概念就是一個電子試算表檔案文件視為一個. 資料庫，一個電子試算表檔案文件中的單一頁面視為一個資料表 (Table)。如今. Google 的線上問卷調查產生器即是使用 Google 電子試算表作為後端的問卷資料. 庫，前端則是使用模組化的問卷製作頁面提供使用者使用。本研究即是以電子試. 算表作為後端儲存資料來進行分散式儲存架構之研究。但由於每張電子試算表的. 工作表在存取上目前有受到限制，即每張工作表最大容量為 250 欄 40 萬個儲存. 格，但電子試算表檔案無論多大，目前都不算在 Google Drive 的儲存空間中，代. 表目前的使用者可以利用電子試算表做無限量的資料儲存工作。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 18. 二、Google Spreadsheets API. Google Spreadsheets API (Google 電子試算表 API)，主要功能是讓開發人員. 能夠透過此 API 來編寫應用程式，進而讀取甚至對於電子試算表中的表格資料. 進行操作。API 1.0 及 2.0 的版本從 2012 年 10 月 20 號起已經不再支援，並且已. 整合至 3.0 的版本中。使用 Google 電子試算表 API version 3.0 必須先設定並下載. client library 的程式庫，目前官方提拱的程式語言包括.NET 以及 Java，此外也能. 使用 PHP 或 Python 進行操作，而 Google 電子試算表 API主要功能如下表 2-4。. 表 2-4 Google 電子試算表 API主要功能表. 項目說明. 創建新的電子試算表允許創立新的電子試算表和工作表. 電子試算表 API的 URL 權限控. 管. 控制電子試算表的權限. 檢索所有電子試算表列表檢索該帳號內所有電子試算表的資訊. 對電子試算表中的工作表進行. 操作.  取得工作表資訊和修改其標題及大小.  增加和刪除工作表. 使用 list-based feeds 對電子試算. 表中的工作表列進行操作.  對工作表中的列作排序的動作.  傳送結構化的查詢給列.  增加、更新、刪除工作表中的列. 使用 cell-based feeds 對電子試算. 表中的工作表單元表格進行操. 作.  獲取特定的行或列.  更改單元表格的內容.  批次更新多個單元格. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 19. Google 官方除了提供電子試算表 API之外，另有 Google Visualization API。. Google Visualization API 讓應用程式開發人員能以 Query Language (查詢語言). 的方式，將電子試算表中的資料以 SQL 語言來做資料篩選取出並顯示的動作，. 原本方法是用來篩選資料讓試算表以圖像化方式呈現如下圖2-6以及下面範例程. 式碼，但亦能透過 URL 的方式以 GET 帶查詢語言及電子試算表的 Key 來對電. 子試算表作查詢的動作，送出查詢後，會得到動態產生的 XML 網頁回應。. function drawVisualization() { // 電子式算表的 key 為 12345678. var query = new. google.visualization.Query('http://spreadsheets.google.com/tq?key=12345678&pub=1. '); // 查詢語言 query.setQuery('SELECT A,D WHERE D > 100 ORDER BY D');. // 將查詢語言送至圖像化函數中 query.send(handleQueryResponse); }. 圖 2-6 試算表資料圖像化範例圖. 資料來源: Google Spreadsheet. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 20. 使用 URL 方式如下範例，將 URL 中粗體 Query 位置填入 SQL 語法，而粗. 體 Key 的位置填入欲查詢之電子試算表的 Key 即可。當然此方法會有資訊安全. 上的問題，將最重要的 Key 暴露在網址列上，對於電子試算表來說並不安全，. 若在權限上沒有控制好的話，有心人隨時都能夠利用電子試算表的 Key 來加以. 填入或破壞資料。但利用此方法卻又擁有極大優點，即 SQL 查詢結果沒有筆數. 顯示上的限制。由於Google電子試算表API在查詢的部分有限制單次查詢筆數，. 而下面即將介紹的 Zend 套件亦有限制及效率上問題，故本研究將利用此方法來. 開發新的查詢語言介面，將機密資訊做隱藏並包裝，以達到資訊安全的目的，詳. 細方法將會在第三章節做更進一步的介紹。以 SELECT * 語法查詢某一試算表. 會獲得類似如下圖 2-7 的動態網頁回應。. http://spreadsheets.google.com/tq?tqx=out:html&tq=Query&key=Key. 圖 2-7 動態查詢回應圖. 資料來源: 本研究整理. http://spreadsheets.google.com/tq?tqx=out:html&tq=Query&key=Key. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 21. 三、電子試算表資料操作之開放源碼套件. 當我們要將電子試算表作為一個資料庫的同時，首先會遇到的問題即是如何. 對於資料庫的單元內容作處理，如何新增、修改、更新、刪除甚至是更進一步的. 問題，資料表的混合操作。對於處理電子試算表表格資料的方式，在上述 Google. 官方所提供給開發人員的套件 Google 電子試算表 API中已有初步介紹。. 但僅僅是使用套件只能做到最基本的行列和單元處理，並無法滿足作為一個. 資料庫應該有的基本功能，於是許多非官方的開放原始碼套件開始被開發使用。. 像是做出類似 SQL 語言般結構化查詢的套件，抑或是真正將電子試算表當成是. 非關聯式資料庫使用的套件都逐漸的被開發出來，但事實上大部分的套件都較像. 是小工具，幾乎沒有真正一套用來管理電子試算表作為資料庫的資料庫管理套件. 或軟體。. 下面將介紹由知名 PHP網頁程式語言開放原始碼團體所整合Google電子試. 算表 API version 3.0 開發出來的 PHP 套件。本研究將利用並修改此套件的程式. 碼作為資料庫管理程式對資料表基本操作，即新增、更新以及刪除功能，而查詢. 的功能的部分後面會再介紹。MVC 架構的鬆散耦合的體系結構允許開發人員使. 用任何他們想要的組件來進行開發。強大的套件節省了開發時間，套件之間互不. 依賴是模組化的關鍵，且支援多種資料庫，像是 MySQL、Oracle、IBM DB2、. 微軟 SQL Server、PostgreSQL、SQLite 和 Informix Dynamic Server…等，上述優. 點即是本研究選擇使用 PHP Zend Framework 作為網站系統開發框架的原因。. (一) PHP Zend Framework. PHP Zend Framework 是一個用來方便快速開發網頁程式的開放原始碼. 框架，其概念是從 Ruby on Rails 和 Spring Framework 發展而來，由 Zend. Technologies公司的Andi Gutmans和Zeev Suraski所發起。2007年 7月 1日，. Zend Framework 1.0 發布後，在 2012 年 9 月 5 日，Zend Framework 2.0 正式. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 22. 版發布前 (Zend 2012)，1.0 版本在全世界有超過 1500 萬次下載，其特色為. 物件導向程式撰寫架構，是以 PHP 網頁程式語言撰寫而成，目前已支援到. PHP 5.3+的版本，且最新框架版本使用並支援 PHP 5.3 較新的功能，像是靜. 態函數綁定、命名空間、lambda 函數等。. (二) Zend Gdata. Zend Gdata 套件提供程式開發人員一個端口和介面去對於 Google 的幾. 種線上服務做連接和操作，可以發送查詢檢索、更新數據、刪除數據…等。. 目前支援的線上服務如後面表 2-5 所示，本研究即是使用 Google 電子試算. 表的部分。. (三) Zend Gdata Google Spreadsheets. 如同前表所述，Zend Gdata Google Spreadsheets 即是將 Google 電子試. 算表 API整合所成套件，如前所述目前 Google 所提供支援程式若要轉為網. 頁程式語言，需自行修改開發，而此套件不但方便程式開發人員能夠快速使. 用來開發網頁程式來管理工作表格或文件檔案，且程式彈性極強，十分符合. 現今開發軟體或網頁的架構。但由於其結構化查詢功能被 Google 限制查詢. 筆數單次最多 5 筆，故本研究只修改使用此套件查詢語言之外的功能，而結. 構化查詢則利用上述 Google 另一查詢語言來開發新套件使用。下面介紹. Zend Gdata Google Spreadsheets 所提供開發人員能使用的功能。. 1. 獲取電子試算表列表. 可以透過 getSpreadsheetFeed()方法提供授權用戶電子試算表列表資. 訊，將會以 Zend_Gdata_Spreadsheets_SpreadsheetFeed 物件回傳。. 2. 獲取電子試算表中工作表列表. 給予一組電子試算表的 key，. Zend_Gdata_Spreadsheets_SpreadsheetEntry 物件方法會回傳該. Spreadsheets 中所有的工作表列表 . ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 23. 3. 透過 List-based Feeds 方法和工作表中的橫列作互動. 使用此方法能操作工作表中的橫列資料，需特別注意的是工作表的第. 一列不能儲存資料，而是欄位名稱，因為此方法會動態產生 XML 檔. 且以第一列為標頭。在呼叫此方法時，橫列若有空白則資料抓取會立. 即停止，意為若第二列就空白，則抓取到的資料會是空白資料。下面. 將介紹此方法下的各種函數呼叫。. (1) 利用 getListFeed()取得列資料:可用此方法取得已存在列資料。. (2) 排序列資料:True 的話則按照原本順序排序，false 則反向如下。. (3) 發送結構化查詢:允許發送結構化查詢，但其中最多只會找到前. 面五筆資料，為何本研究不使用此套件的查詢功能原因。. (4) 增加列資料:新增一筆列資料到工作表中。. (5) 刪除列資料:使用 deleteRow()方法刪除現有列資料如下，其中. $listEntry為要刪除的列資料。. (6) 編輯列資料:更新現有列資料內容，其中若原本內容不變則需填. 入原值，否則會自動填入 0。. 4. 透過 Cell-based Feeds 方法和工作表中的單元格作互動. 可以透過此方法來修改資料，但須注意的是不支援同步修改，意思是. 同一時間內工作表的同一單元格不能被同時修改。. (1) 利用Cell-based Feed取得單元格資料:可利用此方法取得已存在. 的單元格資料。. (2) 結構化查詢指定條件下單元格內容:可以獲取自訂條件查詢該. 單元格的內容如下。. (3) 修改單元格資料:允許使用 updateCell()方法來更新修改單元格. 內容，無論指定單元格中有無內容，都將被覆蓋。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 24. 表 2-5 Zend Gdata 套件支援 Google 服務表. 支援項目說明. Google Calendar 可用 Zend_Gdata_Calendar 類別來查看、創建、更新和. 刪除用戶在 Google Calendar 上的事件紀錄. Google 電子試算表能夠使用 Google data API feeds 以表單形式查看、更新、. 編輯或刪除表格內容，以及發送查詢. Google Documents. List. 能用讓使用者上傳文件，以及送出請求查看文件列表. Google Provisioning 允許網域管理員作用戶管理，存取如 Calendar、Docs 和. 電子試算表服務。具體而言，此 API允許創建、檢索、. 更新和刪除用戶帳戶、暱稱、群組和郵件列表的功能. YouTube 提供用戶可以未經身份驗證的讀取和寫入訪問 YouTube. 的內容，用 Google Data feeds 檢索流行的視頻、評論、. YouTube 用戶的公開訊息及播放列表、收藏和訂閱. Picasa Web Albums 允許用戶增加、更新和刪除他們的相簿，以及標記照片. 和評論. Google Analytics 允許存取該用戶被儲存在 Google Analytics 上的數據. Google Blogger 允許查看和更新的 Blogger 內容. Google CodeSearch 能從很多專案中作查詢程式碼的動作. Google Notebook 可以查看公開的 Notebook 內容. 資料來源: 本研究整理. 綜合上述，本研究平台架構選擇 Zend Gdata Google Spreadsheets 套件，並做. 修改後作為資料新增、修改和刪除或移動的部分，而查詢語言的部分則是利用. Google 查詢語言套件無限制查詢筆數的優點來建立另外的專屬查詢套件，並將. 兩者加以整合運用在搭配上 MySQL 作為整個大平台架構的主要骨幹，其平台架. 構設計將於下一章節中詳細說明。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 25. 第三章研究設計. 本章將敘述平台的雛型架構與機制設計的架構，第一節將說明此分散式儲存. 平台的整體雛型架構與模組。第二節將說明分散式儲存架構平台機制設計。最後. 第三節將說明資料在分級儲存上的機制與兩端資料庫的設計。. 本研究將發展一套在雲端環境下的分散式資料儲存架構平台，其中將取關聯. 式資料庫模式核心精神，並結合集中式和分散式資料庫架構的優點和避免缺點，. 利用 Google 電子試算表來提出平台的雛型架構。其中分散式儲存架構平台的設. 計主要為。. 1. 如何運用 Google 電子試算表的海量資料儲存優點結合本地端資料庫安. 全穩定和快速存取的優點來設計平台模組。. 2. 透過此平台能輕易地做到海量資料存取，並減低架設成本。. 3. 平台中的資料如何分散儲存至兩端資料庫中以及儲存在本地端和雲端的. 資料為何。. 第一節分散式儲存架構平台架構. 目前市面上大多的雲端儲存服務除了較大服務商可提供客製化之外，許多僅. 為單純雲端儲存，由前面幾章可知客製化或使用服務商的解決方案會使成本提高，. 而某些中小企業在一開始無法承受該成本，故本研究為了結合兩端資料庫的優點. 以及兼具架構彈性及低成本的精神，此分散式儲存架構平台為在雲端環境之上發. 展且滿足集中式與分散式架構優點之服務平台。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 26. 一、分散式儲存架構平台整體架構圖. 此平台除包含與使用者的互動機制、資料的分級儲存機制外，另有支援此平. 台的電子試算表管理組、查詢語言模組、資料切割合併模組…等，其所呈現之整. 體架構圖如下圖 3-1 所示，本研究後面所有圖中若未特別說明，則箭頭均表示資. 料流動的方向。. 圖 3-1 分散式儲存架構平台整體架構圖. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 27. 圖 3-1 展示了本研究平台的整體概念架構，雙向箭頭部分代表資料與資訊的. 流動，也可以看作是服務的請求，而資料是透過資料分割組合模組來呈現與儲存。. 整體分散式儲存架構平台可以分為三層分別介紹如下:. 1. 服務介面層(Service Interface Layer). 服務介面層為提供使用者各種服務的一套介面，在此層可以將資料作不. 同的呈現或是開發各種不同的服務。在本研究中此服務介面層將會使用 PHP. 網頁程式語言來做為服務使用者的介面，使用者可以利用此介面做一些像是. 資料修改或查看的動作如下圖 3-2 以成績單為範例，後端程式模組將資料調. 出後組合並結合成完整成績單給予使用者查看，但其實使用者只是透過介面. 觀看，而資料也並非只儲存在單一地點。. 圖 3-2 分散式儲存架構平台服務介面層. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 28. 2. 中央控管層(Center Control Layer). 中央控管層是負責處理兩端資料庫中資料的整合和分隔以及海量資料. 儲存層和服務介面層的連接。當服務介面層傳送要求資料時，會由中央控管. 層中的核心資料管理模組將關鍵資料取出並向電子試算表管理模組要求剩. 餘非關鍵資料，接著透過資料分割組合模組將兩者資料在中央控管層合併傳. 回服務介面層。. 相同模式，若服務介面層是要將資料存入，則中央控管層接收到資料後. 會先讓資料分割合併模組將資料分割成關鍵資料和非關鍵資料，接著將關鍵. 資料傳入核心資料管理模組儲存，將非關鍵資料傳入電子試算表管理模組儲. 存。此中央控管層為整個架構平台的核心，由於有本地端資料庫安全和快速. 的優點，所以幾乎所有資料的Ｉ/O 處理都放於此處處理。而中央控管層整. 體架構圖如後面圖 3-3。. 3. 海量資料儲存層(Big Data Save Layer). 海量資料儲存層負責海量非關鍵資料的存入與取出部分，取出部分會使. 用到本研究開發的查詢語言模組，模組使用 PHP 與網頁爬蟲程式將資料從. 類 XML 格式中取出並傳至中央控管層作處理，而存入則是使用電子試算表. 管理模組中的 Zend 框架套件將分割完的非關鍵資料存入雲端資料庫中。而. 在資料進出控管上，需先取得由中央控管層所保護的鑰匙來決定取出的資料. 為何或是存入的資料要存入到哪張電子試算表中，其中組合資料的試算表關. 聯也需要先從中央控管層取得。故此層除了基本的資料儲存也會和中央控管. 層有溝通連結。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 29. 圖 3-3 分散式儲存架構平台中央控管層. 資料來源: 本研究整理. 二、模組簡介. 本研究為了此架構平台的兩端資料庫能整合運作，且使資料能正確的儲存和組. 合，開發了四個模組來整合整個平台，下面將簡述各模組功能。. 1. 電子試算表管理模組. 在電子試算表管理模組中，所有被分配要儲存至 Google 電子試算表中的. 資料都經由此模組來進行儲存，而當資料被提取要傳至前台呈現時也是. 經由此模組傳出，此模組所管理儲存的資料為大量且非關鍵資料。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 30. 2. 查詢語言模組. 此模組便是開發出來解決原本 Google 電子試算表查詢語言速度和查詢. 筆數被限制的問題，經由此模組可以由 Google 電子試算表中一次提取大. 量資料而不受原本套件限制。. 3. 資料切割合併模組. 資料切割合併模組用來將儲存在本地端的資料以及儲存在雲端的海量資. 料組合送至服務介面層，當然也是負責將欲儲存至分散式平台的資料作. 資料切割分散儲存的模組。. 4. 核心資料管理模組. 核心資料管理模組是負責關鍵資料的儲存是利用本地端資料庫在資料量. 小存取速度快且有安全性高的優點，此模組便是用來儲存管理關鍵核心. 資料。. 第二節資料分級儲存機制. Google 在推出電子試算表後，雖對於電子試算表有較多的權限控制，但仍. 然有安全上的問題，直到推出認證機制，但認證機制在使用開發上較耗費時間且. 耗處理麻煩，為了符合本研究降低成本的精神，故本研究將一份要儲存的資料切. 割成兩種資料，一為關鍵資料，二為非關鍵資料。關鍵資料會存放在較安全且存. 取較快速的本地端資料庫，而非關鍵資料則存放於儲存空間大，較難控制安全性. 的雲端 Google 電子試算表中，以解決不信任的問題，如下圖 3-4 所示。而其它. 相關電子試算表 Key 保護的問題後面會有一些基本的保護方式。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 31. 圖 3-4 資料分級儲存機制. 資料來源: 本研究整理. 而無論資料是要存入或提出都是統一由中央控管層來做操作，整合兩端資料. 後傳送制服務介面層供使用者使用。以下將先說明本架構下的正規化規則接著說. 明兩端資料庫設計方法。. 一、分散式儲存架構平台正規化. 過多重複的資料會造成維護上的困難，也會增加資料庫的負擔，正規化的動作. 即是為了讓資料庫或程式在處理資料上的速度更為快速，且刪除多餘的重複資料. 以減少資料庫的負擔。正規化在傳統資料庫上被分為 5 個等級，數字越大其正規. 化程度越高，但傳統資料庫在做正規化的程度時，通常最多只做到第 3 正規化。. 接著先說明幾種正規化的規則。第 1 正規化是指刪除所有資料表中的重複群組，. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 32. 替每組關聯的資料建立不同的資料表，使用主索引鍵識別每一組關聯的資料。第. 2 正規化是指為可套用於多筆記錄的多組值建立不同資料表，使用外部索引鍵，. 讓這些資料表產生關聯。第 3 正規化是指刪除不依賴索引鍵的欄位。第 4 正規化. 也稱為 Boyce Codd (BCNF)。. 對於本研究分散式儲存架構來說，資料儲存在雲端電子試算表中的其中一個. 優點便是管理者能輕易看出此份電子試算表資料庫所儲存的資料所代表的意思. 和面向，因此在正規化的程度上並不用一定要求做到完美，因為正規化太過完美. 會讓本研究分散式儲存架構的某些優點失去其價值，故經過實驗，本研究發現在. 此分散式儲存架構下的正規化程度最多只需符合第 2 正規化即可。而基於實驗，. 本研究提出並建議在使用此分散式儲存架構下的專屬正規化兩個主要步驟和要. 點如下。由於平台的兩端資料庫設計分為關鍵與非關鍵資料的儲存，故在資料正. 規化只要確保下列兩點即可，其餘端看設計者需求來做其它額外的步驟。. 1. 刪除重複資料. 將可能重複出現的資料刪除，並選出關聯資料表的索引鍵，及主鍵及外部鍵。. 2. 將資料表以索引鍵做為關聯. 將資料表做關聯，並決定該資料表是存放於雲端或本地端資料庫。. 二、雲端資料庫設計. 當資料屬於非關鍵資料，也就是單看資料無法看出該資料欲表達的資訊時，. 將會被送入雲端資料庫，以減少本地資料庫的儲存空間和硬體存取資料的負擔。. 在雲端資料庫中資料被切割成單獨幾張資料表各自存入不同的電子試算表，其每. 筆資料存入的格式如下圖 3-5，以較無意義的 Key 作為和本地端資料庫溝通的鑰. 匙，而其它欄位則為資料的值，這樣即使此資料表被單獨拿到也無法從中得到真. 正完整的資訊。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 33. 圖 3-5 資料切割. 資料來源: 本研究整理. 而在資料的提取上則是必須先取得本地端資料庫的資料，而資料表的關聯關. 係也是溝通的鑰匙之一，接著再利用鑰匙取得正確資料存放地點，然後使用本研. 究開發的 PHP 查詢語言模組將資料提出，而此模組是使用 PHP 的 cURL 函式，. 此函式模組用來抓取網頁爬蟲資料，而本研究的查詢語言模組則是在送出查詢後. 將回傳的資料存成網頁檔案型態，再由此函數將資料提出，以減少大量資料在雲. 端查詢和 I/O 會影響大部分效率的問題。. 三、本地端資料庫設計. 而當資料的機密程度較高，也就是當資料的重要性較高為關鍵資料時，則將. 資料存放於安全性較高且存取速度較快的本地端 MySQL 資料庫，藉此達到能兼. 具速度以及安全性的架構設計，當資料要提出時，核心資料管理模組便是管理關. 鍵資料且將關鍵資料傳入查詢的重要環節，一筆關鍵資料通常會存入唯一鍵，也. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 34. 就是所謂的主鍵 (PK)，接著在其它欄位填入各資料存放的電子試算表位置，簡. 單來說關鍵資料中含有存放在雲端的資料表的存取鑰匙以及關聯部分，本地端資. 料庫將原本的關聯式關係存入單筆資料中。其資料原本在關聯式資料庫儲存方式. 如下圖 3-6 所示，雙箭頭表示關聯鍵。而若使用本研究方式儲存，會先拆成兩部. 分，在本地端儲存的資料如圖 3-7，而該筆資料在雲端資料庫所存放方式則如下. 圖 3-8 所示，綜合兩圖表可清楚得知資料在切割後存放的位置和方法。. 圖 3-6 原關聯式儲存方法. 資料來源: 本研究整理. 圖 3-7 關聯儲存於本地端資料庫表示圖. 資料來源: 本研究整理. 圖 3-8 資料分開儲存於兩張電子試算表表示圖. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 35. 由上述設計可以得知，在本地端儲存的空間可以節省非常多，而將資料切割. 後亦能安全地存放在雲端資料庫上，使安全、成本和存取速度都能兼具，亦符合. 現今軟體開發彈性較高的設計需求，除充分利用了雲端儲存大量資料的優勢外，. 也保有關聯式資料庫的模式及優點。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 36. 第四章分散式儲存架構平台建置. 本研究於雲端儲存服務與資料庫基礎之上開發出一分散式儲存架構平台，其. 滿足資料庫關聯模式與資料庫設計核心精神，除解決企業將海量資料放入雲端時. 無需為了成本而篩選減少於雲上之資料外，使用此架構亦能達到部份資訊安全。. 本研究結合雲端儲存設計出彈性應用極大之服務平台，此平台包含海量資料儲存. 層、中央控管層、服務介面層、基礎建設層。. 海量資料儲存層主要負責大量非關鍵核心資料的儲存，資料大量被儲存在雲. 端的不同試算表中，且此層中還有包含負責處理資料查詢的查詢語言模組，此模. 組為本研究開發用於解決 Zend Gdata 和 Google API 於單次資料查詢筆數為 5 筆. 的限制，以及使用上述兩種方式查詢速度上極慢的問題，而此層的另一模組為電. 子試算表管理模組，此模組為海量資料進出試算表的出入口。. 中央控管層為整體架構核心，負責儲存雲端試算表的關聯關係與核心資料，. 因此儲存的資料大小極小。除了關聯資料和核心資料的儲存之外，此層還負責資. 料的整合，也就是本地端資料和雲端資料的整合，整合完後對服務介面層做輸出. 的動作。此層所包含的兩個模組核心資料管理模組與資料切割合併模組即負責上. 述工作和資料切割與合併。. 服務介面層則代表各種應用的介面，程式開發者可以開發各種介面和端口做. 為呈現，簡單來說即為資料的前台呈現。. 基礎建設層即為硬體設備，在本研究中，此層分為兩個部分，一個部分是本. 地端使用個人電腦架設平台，其配備為 Intel i5 4 核心處理器，8GB 記憶體以及. Windows 7 作業系統作為平台基礎建設層，另一部分則為雲端是 Google 自身的. 基礎建設。綜合上述本研究將利用商店販售商品和庫存扣減的流程來應用和說明. 本分散式儲存架構平台的運作和可行性，以及其優點。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 37. 第一節分散式儲存架構平台運作機制. 一、使用定位. 企業在使用雲端儲存和雲端運算服務時通常第一步驟為替資料做篩選，此動. 作全因雲端儲存服務和雲端運算服務的收費方式和儲存於雲的資料量大小有十. 分密切的關係，企業存放於雲的資料量越大，需付的費用就越高。因此企業無法. 將所有資料全部都丟上雲端，必須先將資料進行前置處理，決定何種資料放置於. 雲端會有較大的效益，但此動作對於成本和時間上是另一種負荷。. 本分散式儲存架構平台即針對此一因素，除提供企業較低之進入成本外，使. 用此平台無需考慮資料和存放的價錢因素，無論資料量多大，存放於雲端的費用. 依然為零，唯一需考慮的因素為要存放於雲的資料和資訊需如何做切割才符合資. 訊安全，此部分請參考前面研究設計章節。. 而除了為企業分散式儲存使用，本研究發現此平台亦能作為一般簡易網站使. 用。當作為一般簡易網站之儲存後台使用時，因儲存在本地端資料庫的資料量極. 小，因此對於系統的負荷極低，使得一台系統上能安裝和使用更多的網站，進而. 達到系統最大效益。綜合上述，此平台的使用定位為企業作於資料分散儲存與一. 般簡易網站後台儲存所用，兩種使用定位均在於減少本地端資料庫的儲存空間並. 減少系統的負荷。. 二、運作機制. 為使平台整體架構運作順利，本研究針對平台設計幾項運作機制，其中包含. 資源配置、資料分級控管以及本研究開發的海量資料無受限查詢機制，下面將說. 明各項詳細之情形與運作方式。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 38. (一)資源配置. 1. 試算表資源配置. 平台在雲端資源的配置上，當試算表的儲存空間到達上限的 40 萬欄位. 時將會停止將資料送入試算表，並發出警告訊息，且開啟新的試算表並將資. 料存入新試算表中，其中試算表的空間計算是由基本欄位來算出剩餘空間，. 例如:此試算表的儲存欄位有 4 欄，那就表示該試算表能夠儲存 40 萬除以 4. 欄的空間，也就是 10 萬列的資料空間，因此預設大小將被存在本地端資料. 庫，每次在加入新的一筆資料時也會同時記錄更新剩餘資料空間，並給予提. 醒，因此確保平台不會因試算表的空間到達極限而失去資料。試算表資源控. 管儲存於本地端資料庫的方式如下圖 4-1，其中欄位”key”代表何張試算. 表，”od”代表試算表內的何張工作表，”can”代表能儲存的列數，”now”代表. 目前儲存列數。. 圖 4-1 試算表資源配置控管圖. 資料來源: 本研究整理. 2.容錯備援機制. 使用此儲存架構平台的優點之一即為後備救援機制簡易快速，本架構平. 台使用每日批次處理方式將試算表作備份的動作，而當發生資料遺失或是雲. 端檔案損毀時，可以快速將備份檔案匯入，且匯入方式十分簡單，因此本平. 台儲存架構利用批次備份的方式，希望藉此將出錯的機率減少到最低，而更. 換的流程如下圖 4-2，箭頭表示步驟方向。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 39. 圖 4-2 備援檔案備份上線流程圖. 資料來源: 本研究整理. (二)資料分級控管. 在使用雲端儲存和運算服務時，資料的控管是較為麻煩的，由於資料存放於. 不同的地方，因此要如何管理分散的資料，是較麻煩的問題。而本研究中針對儲. 存於雲端不同地方試算表中的資料，是採用資料切割存放，儲存於雲端試算表的. 資料雖為非關鍵的大量資料，但必須先由本地端資料庫中取得授權，方可存取試. 算表中的資料。而單一試算表中所存放的資料也因為切割而有資訊安全的效果，. 所有資料必須被同時取得才能看出其資料之代表意義，否則單一取得任何一張試. 算表中資料均無法得知該資料所代表意義。因此可知資料在切割時必須小心且盡. 量將關鍵資料與資料的關聯存放於本地端資料庫中是較為妥當的。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 40. 圖 4-3 資料分級控管示意圖. 資料來源: 本研究整理. (三)電子試算表查詢機制. 此機制主要用來解決資料查詢在 Google 電子試算表中被限制查詢筆數為 5. 筆的部分所開發，主要是使用 PHP 程式語言開發而成，並將之封裝成兩個函數. SPQuery()和 catch_td()，兩個函數的部分程式碼請參考下表 4-1，SPQuery()函數. 所負責的便是將要查詢的 SQL 指令送入函數中，並產生動態網頁網址，接著由. catch_td()這個爬蟲程式改寫而成的函數將網址送入函數中並產生動態網頁資料. 檔，接著再將查詢結果取出，兩個函數的運作機制流程如下圖 4-4，其中若要使. 用 JOIN 的方法則會先將資料單欄取出後再做 JOIN 的動作。利用此種方式來查. 詢儲存於雲端的海量資料並與本地端資料做溝通結合。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 41. 表 4-1 SPQuery()和 catch_td()部分程式碼示意表. 項目程式碼說明. SPQuery() function SPQuery($spkey,$query){ . return $url="https://spreadsheets.google.com/tq. ?tqx=out:html&tq=. ".$query."&key=".$spkey; }. 函數傳入欲查詢. 試算表的 key 和. 欲查詢的 SQL指. 令，並回傳動態. 網頁檔案之網址. catch_td() function catch_td($url){. $ch = curl_init(); $timeout = 5;. curl_setopt($ch,CURLOPT_SSL_VERIFYHO. ST,0);. curl_setopt($ch,CURLOPT_SSL_VERIFYPEE. R,0); . curl_setopt($ch, CURLOPT_URL, $url);. curl_setopt($ch,CURLOPT_RETURNTRANS. FER, 1);. curl_setopt($ch,CURLOPT_CONNECTTIME. OUT, $timeout);. curl_setopt($ch, CURLOPT_HTTPAUTH,. CURLAUTH_ANY);. $contents = curl_exec($ch);. curl_close($ch);$text=$contents;. $text=str_replace(array("\r","\n","\t","\s"), '',. $text); . preg_match_all("/\<td\>(.*?)\<\/td\>/",$text,$m. atch);. 函數傳入動態網. 頁網址，並使用. 爬蟲程式抓取查. 詢完成的資料. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 42. 圖 4-4 海量查詢資料機制流程圖. 資料來源: 本研究整理. 第二節分散式儲存架構平台整體架構. 本研究平台設計架構分為四個層次，其中有兩個層次的關係密不可分，為整. 個平台能運作順利的主要核心，即為海量資料儲存層和中央控管層，此兩層互相. 溝通協調資料的流動和組合，而另一個服務介面層則代表著對外窗口，因此服務. 介面層可以是任何服務的元件，而服務介面層的接口即為中央控管層，此設計架. 構保有對外服務介面單一窗口，且對內海量資料儲存層和本地端資料庫需取得關. 鍵資料，最後則為本地端基礎建設層。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 43. 透過整個架構，可以使得平台在使用上對外鬆散，對內關係緊密，使得在應. 用於各種服務介面上時能更加彈性化。除了整體架構設計彈性程度高之外，各層. 次的設計也採用 MVC 架構，在元件呼叫的使用上只須呼叫到需要使用的元件，. 以減少系統的負擔，也讓程式在使用和開發上更有效率。下圖 4-5 為整體宏觀設. 計架構與其它各種應用服務的關係圖。其中基礎建設層分為本地端基礎建設層與. Google 自身基礎建設兩層，後面會陸續說明。. 圖 4-5 整體架構與各種服務介面關係示意圖. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 44. 一、基礎建設層. 此基礎建設層代表硬體和軟體的一些基礎建設架構，以本研究分散式儲存架. 構平台來說，此基礎建設層分為兩個部分，第一個部分即為雲端部分，因本研究. 平台使用 Google 試算表作為雲端儲存資料的資料庫和資料表，故雲端的基礎建. 設則視 Google 自身改變而改變，目前得知 Google 在此方面是採用伺服器等級之. 硬體相關設備。而第二部分之基礎建設層即為本研究平台的其它軟硬體部分，本. 研究採用Windows 7作業系統以及 Intel i5等級 4核心處理器、獨立顯示卡和 8GB. 記憶體作為本平台的硬體基礎建設層，而在上面則架有 Apache 網頁運作伺服器. 以及本地端資料庫 MySQL，來供應 PHP 等其它網頁和前端處理的運作，詳細相. 關基礎建設細節如下圖 4-6，黑色箭頭方向代表該程式或項目被安裝在某項目之. 上。. 圖 4-6 兩端基礎建設層. 資料來源: 本研究整理. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 45. 二、服務介面層. 此層代表各種服務應用的介面，本研究的服務介面應用使用 PHP 和 HTML. 程式語言開發，並採用 MVC 架構，讓程式碼與服務介面外觀分開以達到彈性化. 高的架構，使用此兩種程式語言開發除了彈性高，且在應用面上由於為主流網頁. 程式語言，故在發展度上十分成熟，對於漏洞的補缺也較高，可以減少雲端儲存. 較嚴重的資訊安全問題。而在開發上，若採用此兩種程式語言開發，所需安裝的. 其它必須軟體就減少很多，在開發速度上也會快上許多，且由於中央控管層的對. 外端口也是使用此兩種語言作為開發，故本研究平台後面章節展示的服務應用將. 以此兩種程式語言為主開發。. 三、中央控管層. 中央控管層負責服務介面應用端以及雲端資料的兩個端口連結工作，當服務. 介面端發出資料請求時，會先取得授權接著向中央控管層要求雲端資料的組合鑰. 匙，接著向雲端試算表資料庫拿取資料在中央控管層中將資料組合完成，最後中. 央控管層再將資料送出到服務介面應用層中，致此完成資料的呼叫和送出，因此. 中央控管層除了負責端口的連接之外，還負責最重要的資料操作和控制。而資料. 的進出流程架構圖 4-6 如下。. 資料在處理時由切割和合併的處理器負責處理，而儲存則有儲存相關的元件. 負責處理，在接收和呈現也是由額外的元件負責處理。因此中央控管層是本分散. 式儲存架構平台的核心，幾乎所有重要的資料處理都在此完成，且能將大量資料. 處理的速度降低的原因也是因為在此處理資料的相關操作。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 46. 圖 4-7 資料操作相關架構流程. 資料來源: 本研究整理. 本研究使用 Google 虛擬圖像化的功能和 PHP 程式語言的 preg_match()功能. 來設計儲存於雲端資料的查詢功能和資料的處理，Google 虛擬圖像化來傳送查. 詢語言產生動態網頁檔案，preg_match()用來將動態網頁檔案中的資料拉出後再. 使用一些 PHP 函數來對資料作處理，而切割和合併資料以及資料的呈現部分亦. 是使用網頁程式語言 HTML 和 PHP 來開發元件。所有資料的負擔和查詢所需的. 硬體資源全都由 Google 負擔，因此使用者完全不用負擔任何運算處理資源，只. 需送出要求即可。. ‧ 國. 立政治大. 學 ‧. N a. t io na l Chengch i U. ni ve. rs i t. y. 47. 四、海量資料儲存層. 在海量資料儲存層中的元件負責將切割完的資料儲存到正確位置的試算表. 資料庫中，或是將中央控管層要求的資料從雲端試算表中拉出並傳送給中央控管. 層。在此層的所有資料的進出都由中央控管層來要求，此層只負責管理儲存資料，. 因此作為純粹儲存資料的資料庫，資料的安全控管除中央控管層負責外，Google. 也會替此層把關，沒有擁有資料使用權的人或程式在資料的取得上較一般資料庫. 更為不易，一方面是需先取得中央控管層所掌控的資料鑰匙外，必須還是資料的. 擁有者才能對資料進行操作，此層透過兩方控管如下圖 4-7，來確保儲存於雲端. 的資料安全性。. 圖 4-8 海量資料儲存層資料控管示意圖. 資料來源: 本研究整理. ‧ 國.