『壹』 eoq模型的優缺點
優點：經濟訂貨批量模型是目前大多數企業最常採用的貨物定購方式.該模型適用於整批間隔進貨、不允許缺貨的存儲問題，即某種物資單位時間的需求量為常D，
存儲量以單位時間消耗數量D的速度逐漸下降，經過時間T後，存儲量下降到零，此時開始定貨並隨即到貨，庫存量由零上升為最高庫存量Q，然後開始下—個存儲周期，形成多周期存儲模型。
缺點：
①它是一項魯莽的投資政策——不顧有多少可供使用的資本，就確定投資的數額。
②它強行使用無效率的多階段訂貨辦法，根據這種辦法所有的部件都足以不同的周期提供的。
③它迴避准備階段的費用，更談不上分析及減低這項費用。
④它與一些成功的企業經過實踐驗證的工業經營思想格格不入。
(1)存儲模型問題背景擴展閱讀
雖然EOQ模型可以確定最佳的補給數量，但它需要某些相當嚴格的假設才能直接應用。在簡單的EOQ模型中需要做出的主要假設有：
①已知全部需求的滿足數；
②已知連續不變的需求速率；
③已知不變的補給完成周期時間；
④與訂貨數量和時間保持獨立的產品的價格不變（即購買數量或運輸價格不存在折扣）；
⑤不限制計劃制定范圍；
⑥多種存貨項目之間不存在交互作用；
⑦沒有在途存貨；
⑧不限制可得資本等。不過，通過計算上的延伸，可以克服這些假設強加的限制。總而言之，EOQ概念說明了與存放成本和收購成本有關的優選問題的重要性。
『貳』 語義信息的存儲
無論是知識庫還是服務的語義描述都需要具有良好的組織和存儲，以支持高效推理和服務檢索發現。目前對於本體的存儲方法基本有三種(李勇等，2008):
(1)純文本，如 OWL 文件。由於 XML 的信息組織和存儲方式結構復雜，而且存在冗餘等，基於其上的查詢檢索效率通常會比較低。純文本的方式適合本體比較小的時候，不適合本體大規模應用的情況。
(2)資料庫: 是一種比較好的持久化存儲方式，最大好處是便於查找，可存放大本體，查詢效率高，特別在 I/O 效率上。但是資料庫方式存在本體查詢語言到 SQL 的轉換問題，需要藉助於第三方中間件或自定義實現。
(3)專門的管理工具: 比如說 OMM(Ontology Middleware Mole)支持對 RDF、OWL 的存儲管理，還提供各種介面，可以使用查詢語言對 RDF 或者 OWL 進行查詢。綜合對比這三種本體存儲方式，由於關系資料庫存儲幾十年的技術積累，以及它的海量存儲特點而成為了許多研究者的首選。
5.4.3.1 本體的關系資料庫存儲模式
由於本體模型和關系模型的差異，目前存在多種在關系模型中存儲本體的方法，其主要可以分為以下四類(陶皖等，2007; 陳光儀，2009)。
5.4.3.1.1 水平模式
該模式只在資料庫中保留一張通用表，表中列為本體中的屬性。整個本體庫中定義了多少個屬性，這張表就有多少個列，具體如圖 5.28 所示。本體中的每個實例對應該表中的一條記錄。這種存儲模式結構簡單，執行查詢操作比較方便。但是該通用表包含了大量的列，而現有的資料庫系統對一張表中列的個數都是有限制的，所以該模式無法存儲規模較大的本體。而且表中的數據過於稀疏。由於每個實例對應關系表中的一行，如果其在某些屬性列上沒有值，那麼必須將對應的屬性值設置為空，這將導致大量空欄位的出現，不僅浪費存儲空間，而且增加了索引維護的代價。另外該通用表中一個實例的屬性和屬性值只能是一對一，而實際情況往往是一對多，因此無法存儲具有這種特徵的本體。隨著應用中本體的進化，還需要時常更新通用表中的列，重新組織表結構，這將耗費極大的系統代價。
圖 5.28 水平存儲模式
5.4.3.1.2 垂直模式
垂直模式包含一張三元組表，表中的每條記錄都對應一個 RDF 三元組(主語，謂詞，賓語)，具體如圖 5.29 所示。因此這種模式下，需要將本體中的所有信息都以 RDF 三元組的形式表示出來。Protege(2002)中便是使用了這種存儲模式將本體存儲於資料庫中。這種模式設計簡單，並且結構穩定。如果本體進行了更新，只需修改表中相應的元組即可。另外，該模式通用性好，因為現有的本體模型都可以轉換為 RDF 模型表示。但是這種模式的可讀性較差，若對本體信息進行查詢，那麼設計對應的 SQL 語句比較麻煩。除此之外，由於所有信息都存放在三元組表中，導致任何一個本體信息查詢都必須遍歷整個數據表，特別是那些需要進行表連接的查詢，使得查詢效率非常低，這是這種模式最大的不足之處。
圖 5.29 垂直存儲模式
5.4.3.1.3 分解模式
該模式與水平模式和垂直模式的一個顯著的區別是它使用了若干張表，其基本思想是將資料庫進行模式分解。根據分解的對象不同，現有的採用分解模式的方法有兩種。①基於類的分解模式，即為本體中的每個類都創建一張單獨的表，表名為類名，表的列為類的屬性，具體如圖 5.30 所示。這種模式結構清晰，但是很難適應本體動態變化的情況，因為隨著本體中類或者屬性的變化，表結構都要隨著變化。②基於屬性的分解模式，即為本體中的每個屬性創建一張單獨的表，表名為屬性名，每個表都包含兩個列，分別代表RDF 三元組中的主語和賓語，具體如圖 5.31 所示。在該模式中對類的隱含實例的查詢代價很大，而且在現有的這兩種分解模式的方法中，隨著本體的變化都要不斷的創建和刪除表，而在資料庫系統中創建和刪除表的效率很低。
圖 5.30 按類分解模式
圖 5.31 按屬性分解模式
5.4.3.1.4 混合模式
該模式通常將上述幾種模式進行混合使用。例如，Pan 等(2003)提出這樣一種將基於類的分解模式與基於屬性的分解模式混合的存儲模式，即在本體中定義一個類就為該類創建一個表(創建方法類似於基於類的分解模式)，在本體中定義一個屬性就為該屬性創建一個表(創建方法類似於基於屬性的分解模式)。然而，與基於類的分解模式不同的是，該混合模式在類對應的表中不記錄相應實例的所有信息，而只記錄實例的 ID。實例在各個屬性上的取值則分別記錄在各屬性對應的表中，所以和基於屬性的分解模式類似，該模式在屬性對應的表中仍然需要兩列: 主語和賓語。對於本體類數目不多的情況下，這種模式在簡單檢索的情況下，運行得很好。但是，如果本體的類比較多，這種方式就會存在一些問題，例如: 資料庫無法容納這么多表，或者效率低下。
針對上述四種模式，陳光儀(2009)從四個方面對適用場合、查詢和更新效率、結構清晰以及易理解性、可擴展性四個方面對他們進行了綜合對比(表 5.4):
表 5.4 不同存儲模式的綜合對比
(修改自陳光儀，2009)
通過上述對本體存儲模式的闡述及之間的綜合對比發現，本體存儲模式除了應該具有盡量高的規范化程度(例如滿足第三範式或 BCNF 范圍等)，還應該滿足以下三個原則。
(1)模式結構易於理解。該原則是為了便於本體查詢的實現。如果模式結構不直觀，會給查詢語句的設計帶來困難。例如，垂直模式不滿足該要求，它將所有的信息都採用三元組的形式存儲在一張表中，不容易理解表中元組的含義，加重了本體查詢設計的負擔。
(2)模式結構穩定。即本體的變化不會引起資料庫表結構的變化。因為本體是不斷進化的，如果設計的模式結構會隨著本體的變化而變化，資料庫系統對其維護代價太大。現有的水平模式、分解模式和混合模式都不滿足該要求。
(3)查詢效率高。該原則是評價各種存儲模式的一個重要指標。因為本體中不僅包含大量的數據，而且查詢中還經常需要進行表連接。例如在現有的垂直模式和基於屬性的分解模式中，那些涉及表連接的查詢效率非常低。
目前在基於資料庫的本體存儲的實踐上，一些學者開展了相關的研究工作:
燕雲鵬(2007)和陳光儀(2009)提出了類似的針對於針對 OWL 的本體資料庫的混合本體存儲模式(圖 5.32，5.33)。可以看出這種模式是以基於屬性的分解模式與垂直模式的混合體，具有較好的擴展性。但是存在的問題是效率不夠高，所有的類存儲在一個表中，所有的實例也存儲在一個表中，這種方式的檢索效率比較低。另外存儲實例的表(Instance，Proterty，Value)中欄位 Value 必須存儲許多種不同類型的數值，比如有的是文本型，而有的卻是數值型，使得數據不夠清晰。此外，在針對幾何體這種復雜的地理對象，這種欄位就比較難以存儲。
圖 5.32 本體的資料庫混合存儲模式(據燕雲鵬，2007)
ebRIM(ebXML Registry Information Model)是一個主流的信息注冊模型，已成為事實上的標准，得到了 OGC 等支持。OGC 已經實現了基於 ebRIM 的目錄服務，並推薦其作為目錄服務的實現規范。但是目前基於 ebRIM 的目錄服務只支持普通的基於關鍵字的檢索。為此，一些學者已經開始研究如何擴展 ebRIM 實現對語義信息特別是 OWL 的注冊。Dogac 等(2004)提出了如圖 5.34 所示的一種通過將 XML 形式存儲的 OWL 文件轉換為以資料庫形式存儲，使得查詢檢索更加快速，管理維護也更加方便。為了能在 ebRIM 存儲復雜的地理空間信息對象，一些學者開展了基於 ebRIM 的地理擴展方面的研究工作。樂鵬(2007)在其論文中提出了兩種擴展方式: ① 從類 「ExtrinsicObject」 派生了「CSWExtrinsicObject」來描述那些不是 ebRIM 自身定義的元數據對象。比如類 「Dataset」繼承了 「CSWExtrinsicObject」來描述空間數據集。②對 ebRIM 已有的類別增加 「Slot」。每一個從 「RegistryObject」繼承下來的類均允許添加 「Slot」。ebRIM 中的 「Service」類可以用來描述空間服務，但是已有的屬性不足以描述空間網路服務。因此，通過添加「Slot」到 「Service」類中以定義從 ISO 19119 派生的屬性。如圖 5.35 所示為經擴展後的ebRIM 高層模型圖，其中 灰 色 填 充 的 矩 形 框表示 擴 展 的對 象 類。該 模 式 與 前 面 燕 雲 鵬(2007)和陳光儀(2009)提出的模式相比，本質上差別不大，也是以基於屬性的分解模式與垂直模式的混合體，只不過是基於標準的 ebRIM 注冊模型，並且將其中的分類系統相關的類單獨以兩張表存儲。該模式也具有很好的擴展性，也存在同樣的一些問題。
圖 5.33 本體的資料庫混合存儲模式(據陳光儀，2009)
海洋信息網格技術與應用
續表
5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)
5.4.3.2 基於多分解策略的混合存儲模式實現
對知識庫以及服務語義注冊信息的存儲的實現上，本書在現有的研究成果的基礎上，結合本體組織構成及特點等實際需求，提出了一種基於多分解策略的混合關系資料庫存儲模式。
該方法的指導思想是: 先按類對其中的數據專題、數據模式、處理模型等進行類的分解，然後結合屬性的特性進行基於屬性的分解。其中基於類的分解中，可能粒度的大小不一，可能是一個類或者具有相關或相似的一些類劃分為一張表存儲; 而基於屬性的剖分，也並不是所有具有該屬性的類以一個表存儲，而可能是只針對一個類也單獨組織為一張表，其具體思路如下:
圖 5.35 經擴展的 ebRIM 高層模型圖(據樂鵬，2007)
(1)類的分解: 因為本研究的存儲模型不是為了實現一個通用的本體存儲模型，而是為了實現一個服務於海洋信息服務領域的本體存儲模型。海洋信息服務領域必然會牽涉到一些對象，比如對服務、模型、參數等對象，並且對這些對象的認識也基本上確定(也就是說這些對象類所具有的屬性及之間的關系基本明確)，所以沒必要像上面幾種實現方案那樣因為不能預知都有哪些類，各類都有哪些屬性而將所有的實例的組織按垂直方式進行存儲，也沒有必要有一些表(比如獨立的屬性表，屬性的作用域和值域表等); 而有必要針對海洋信息服務領域內的這些類的信息內容獨立出一些表: 對於海洋專題，地理名實體、處理模型、數據模式等海洋信息檢索發現中常用的對象，則有必要進行分開存儲，否則必然使得結構不清晰，且檢索查詢效率低。
(2)對於專題、空間形態以及模型功效等只是簡單的分類系統，所具有的屬性少，而且今後存在派生新的種類的可能，因此必須具備一定的擴展性。針對這類數據。它們的存儲方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 標注本體類是屬於專題(比如 「海流」)或者其他。
(3)對於取值不唯一的屬性，且大部分類或實例都具有的屬性，則採用基於屬性的分解模式。比如對於別名屬性(hasAliasName)，有可能一個類實例具有多個別名，這種情況下，則採取基於屬性的組織方式。該表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本體類的 ID，也可以是本體實例的 ID，還可以是本體屬性的 ID，因為類、實例和屬性都可以有別名。
(4)對於復雜的屬性，採取大二進制存儲的方式。比如對於地名實例的空間覆蓋范圍，則不考慮其實際內部是包含多少個組成部分，統一按一個 shape 存儲在資料庫中。當然這里藉助了 ArcGIS 的 GDB 的 FeatureClass 矢量數據模型，並對於不同空間形態的則採用了多張表(點狀地名類、線狀地名類、面狀地名類)，其組織方式是(GeoNameObjec-tID，shape)。同樣，對於模型本體中的內部流程本體，也採用了大二進制方式存儲，將整個流程 XML 描述文件，作為一個整體存放於欄位中，其大體組織方式為(ModelID，FlowXML)。
(5)本研究採用 ArcGIS 的 GeoDatabase 作為存儲模型。本體類(ontClass)的存儲結構如圖 5.36 所示，資料庫的總體組織結構如圖 5.37 所示。
圖 5.36 本體類(onClass)的存儲結構
『叄』 文件的邏輯存儲模型為
邏輯文件一般指文件邏輯結構，文件的邏輯結構是用戶可見結構。邏輯文件從結構上分成二種形式：一種是無結構的流式文件，是指對文件內信息不再劃分單位，它是依次的一串字元流構成的文件。一種是有結構的記錄式文件， 是用戶把文件內的信息按邏輯上獨立的含義劃分信息單位，每個單位稱為一個邏輯記錄
文件的邏輯結構：
文件的邏輯結構是用戶可見結構。邏輯文件從結構上分成二種形式：
一種是無結構的流式文件，是指對文件內信息不再劃分單位，它是依次的一串字元流構成的文件。
一種是有結構的記錄式文件, 是用戶把文件內的信息按邏輯上獨立的含義劃分信息單位，每個單位稱為一個邏輯記錄（簡稱記錄）。
所有記錄通常都是描述一個實體集的，有著相同或不同數目的數據項，記錄的長度可分為定長和不定長記錄兩類。
在文件系統設計時，選擇何種邏輯結構才能更有利於用戶對文件信息的操作呢?
一般情況下，選取文件的邏輯結構應遵循下述原則：
(1)當用戶對文件信息進行修改操作時，給定的邏輯結構應能盡量減少對已存儲好的文件信息的變動。
(2)當用戶需要對文件信息進行操作時，給定的邏輯結構應使文件系統在盡可能短的時間內查找到需要查找的記錄或基本信息單位。
(3)應使文件信息占據最小的存儲空間。
(4)應是便於用戶進行操作的。
『肆』 簡述記憶的多重存貯模型
當前得到公認的解釋記憶儲存的模型是記憶的三存儲模型,該模型認為記憶加工有三個不同的階段,它們分別是感覺記憶,短時記憶和長時記憶.來自環境的信息首先到達感覺記憶.如果這些信息被注意,它們則進入短時記憶.正是在短時記憶中,個體把這些信息加以改組和利用並作出反應.為了分析存人短時記憶的信息,你會調出儲存在長時記憶中的知識.同時,短時記憶中的信息如果需要保存,也可以經過復述存入長時記憶.
一,感覺記憶
感覺記憶又稱感覺寄存器或瞬時記憶,是感覺信息到達感官的第一次直接印象.感覺寄存器只能將來自各個感官的信息保持幾十到幾百毫秒.在感覺寄存器中,信息可能受到注意,經過編碼獲得意義,繼續進入下一階段的加工活動,如果不被注意或編碼,它們就會自動消退.
各種感覺信息在感覺寄存器中以其特有的形式繼續保存一段時間並起作用,這些存儲形式就是視覺表象和聲音表象,稱視象和聲象.它們雖然保存的時間極短,但在生活中也有自己的作用.例如,在看電影時,是視象幫助我們把相繼出現的一組圖片看成是一個平滑連續的畫面.大多數視象持續的時間不會超過一秒鍾,但在有些情況下,一些視象可以持續更長的時間.這取決於刺激的強度(如亮度),視覺剌激的強度越大,視象消失得越慢.
聲象記憶和視象記憶基本上具有相同的性質,只是聲象在感覺寄存器中的持續時間較長,可達幾秒鍾.使得我們能夠有更多的時間加工語音信息,達到詞的意義.研究表明,視象和聲象是物理刺激的忠實復製品,是感覺器官提供的信息的有效拷貝.選擇性注意控制著什麼信息將得到進一步的加工,傳遞到短時記憶.
二,短時記憶
短時記憶(STM)也稱工作記憶,是信息加工系統的核心.在感覺記憶中經過編碼的信息,進入短時記憶後經過進一步的加工,再從這里進入可以長久保存的長時記憶.信息在短時記憶中一般只保持20~30秒,但如果加以復述,便可以繼續保存.復述保證了它的延緩消失.短時記憶中儲存的是正在使用的信息,在心理活動中具有十分重要的作用.首先,短時記憶扮演著意識的角色,使我們知道自己正在接收什麼以及正在做什麼.其次,短時記憶使我們能夠將許多來自感覺的信息加以整合構成完整的圖像.第三,短時記憶在思考和解決問題時起著暫時寄存器的作用.例如在做計算題時每做下一步之前,都暫時寄存著上一步的計算結果供最後利用.最後,短時記憶保存著當前的策略和意願.這一切使得我們能夠採取各種復雜的行為直至達到最終的目標.正因為發現了短時記憶的這些重要作用,在當前大多數研究中被改稱為工作記憶.
『伍』 簡述企業存貨管理的存儲模型原理
存貨管理實質就是庫存管理,1915年，美國的F·W·哈里斯發表關於經濟訂貨批量的模型，開創了現代庫存理論的研究。在此之前，義大利的V·帕雷托在研究世界財富分配問題時曾提出帕雷托定律，用於庫存管理方面的即為ABC分類法。隨著管理工作的科學化，庫存管理的理論有了很大的發展，形成許多庫存模型，應用於企業管理中已得到顯著的效果。
庫存管理模型的分類：
（1）不同的生產和供應情況採用不同的庫存模型。按訂貨方式分類，可分為5種訂貨模型。
①定期定量模型：訂貨的數量和時間都固定不變。
②定期不定量模型：訂貨時間固定不變，而訂貨的數量依實際庫存量和最高庫存量的差別而定。
③定量不定期模型：當庫存量低於訂貨點時就補充訂貨，訂貨量固定不變。
④不定量不定期模型：訂貨數量和時間都不固定。
以上4種模型屬於貨源充足、隨時都能按需求量補充訂貨的情況。
⑤有限進貨率定期定量模型：貨源有限制，需要陸續進貨。
（2）庫存管理模型按供需情況分類可分為確定型和概率型兩類。確定型模型的主要參數都已確切知道；概率型模型的主要參數有些是隨機的。
（3）按庫存管理的目的分類又可分為經濟型和安全型兩類。經濟型模型的主要目的是節約資金，提高經濟效益；安全型模型的主要目的則是保障正常的供應，不惜加大安全庫存量和安全儲備期，使缺貨的可能性降到最小限度。庫存管理的模型雖然很多，但綜合考慮各個相互矛盾的因素求得較好的經濟效果則是庫存管理的共同原則。
具體的詳細模型，您可以參照網路文庫里的資料，在網路文庫里輸入「存儲模型」，點擊查看其中的PPT，查看更加方便快捷，看起來也舒服。
『陸』 倉庫管理系統的背景和意義
一、倉庫管理系統的背景：
隨著計算機的應用普及，目前大多數企業的倉庫管理數據資料已開始採用計算機數據系統管理，但數據還是採用先紙張記錄、再手工輸入計算機的方式進行採集和統計整理。這不僅造成大量的人力資源浪費，而且由於人為的因素，數據錄入速度慢、准確率低。
隨著企業規模的不斷發展，倉庫管理的物資種類機數量在不斷增加、出入庫頻率劇增，倉庫管理作業也已十分復雜和多樣化，傳統的人工倉庫作業模式和數據採集方式已難以滿足倉庫管理的快速、准確要求，嚴重影響了企業的運行工作效率，成為制約企業發展的一大障礙。
二、倉庫管理系統的意義：
倉庫管理系統幫助企業解決了以下問題：
（1）採集輸入代替手工輸入減少了失誤率。
（2）使產品信息能快速錄入到資料庫中
（3）減少了原材料的浪費和成品的丟失。
（4）為企業把生產和銷售整合在一起。
拓展資料：
簡介：
使用條形碼管理系統 , 對倉儲各環節實施全過程式控制制管理，並可對貨物進行貨位、批次、保質期、配送等實現條形碼標簽序列號管理，對整個收貨、發貨、補貨、集貨、送貨等各個環節的規范化作業 , 還可以根據客戶的
倉庫管理系統流程示意
需求製作多種合理的統計報表 .憑借豐富的條碼資源及多年實施條碼系統的經驗，將條碼引入倉庫管理，去掉了手工書寫票據和送到機房輸入的步驟，解決庫房信息陳舊滯後的弊病。不論物品流向哪裡，我們都可以自動跟蹤。條碼技術與信息技術的結合幫助企業合理有效地利用倉庫空間，以快速、准確、低成本的方式為客戶提供最好的服務。
倉庫管理系統是通過入庫業務、出庫業務、倉庫調撥、庫存調撥和虛倉管理等功能，綜合批次管理、物料對應、庫存檔點、質檢管理、虛倉管理和即時庫存管理等功能綜合運用的管理系統，有效控制並跟蹤倉庫業務的物流和成本管理全過程，實現完善的企業倉儲信息管理。該系統可以獨立執行庫存操作，與其他系統的單據和憑證等結合使用，可提供更為完整全面的企業業務流程和財務管理信息。
『柒』 雲存儲的核心技術：虛擬化存儲，究竟虛擬是怎樣實現的
虛擬化改變了計算機使用存儲的方式。就像物理機器抽象成虛擬機（VM：Virtual Machine）一樣，物理存儲設備也被抽象成虛擬磁碟（Virtual Disk）。今天我們就來聊聊虛擬化存儲（Storage Virtualization）技術，究竟虛擬磁碟是怎樣實現的？
虛擬磁碟的實現
我們知道，伺服器擴展存儲的手段主要有直連存儲（DAS）、存儲區域網路（SAN）和網路附加存儲（NAS）這三種類型。那麼哪種存儲類型可以用來實現虛擬磁碟呢？
在虛擬化環境中，類似VMWare這樣的虛擬機管理程序hypervisor，要同時給很多VM分配存儲空間。這個過程中，我們需要先把物理存儲資源重新劃分成虛擬磁碟，然後再分配給VM。
顯然我們不能用DAS方式把物理磁碟直連到VM上，如果這樣，需要的物理磁碟就太多了。SAN是以邏輯單元（LUN：Logic Unit）的形式提供存儲資源，但是虛擬環境中VM的數量是很大的，而且倫的數量不足以支持這么多虛擬磁碟。
更重要的是，虛擬磁碟是為大量VM共享的，由於VM需要隨時創建、刪除或遷移，所以需要在遷移VM時共享存儲空間，只有原始數據不會丟失。DAS還是SAN，都不適合共享存儲。
考慮到資源分配以及共享的問題，虛擬機管理程序以NAS的方式實現虛擬磁碟。VMware通常使用VMFS（虛擬機文件系統）或NFS協議實現虛擬磁碟，VMFS文件系統是專門針對虛擬機環境協議。
每一個虛擬機的數據實際上是一堆文件，及最重要的文件的虛擬磁碟文件（VMDK文件），也有交換分區文件（VSWP文件，等價交換），非易失性存儲器（NVRAM的文件相當於BIOS），等等。每個VM對虛擬磁碟的IO操作實際上是對虛擬磁碟文件的讀寫操作。
設計、施工、和虛擬伺服器環境和優化，允許多個虛擬機訪問集成的集群存儲池，從而大大提高了資源的利用率。使用和實現資源共享，管理員可以直接從更高的效率和存儲利用率中獲益。
那麼我們如何在雲計算中使用虛擬磁碟呢？
實例存儲
最主要的一種使用虛擬磁碟的方式就是實例存儲，每個VM都是虛擬機的一個實例，虛擬機管理程序在每個實例中提供一個模擬硬體環境，它包括CPU、內存和磁碟。這樣，虛擬磁碟就是虛擬機實例的一部分，就像物質世界。刪除VM後，虛擬磁碟也將被刪除。
在這個實例存儲模型中，虛擬磁碟與虛擬機之間的存儲關系，事實上，它是DAS存儲。但是虛擬磁碟的底層實現，我們說，它是以NAS的方式實現的。虛擬機管理程序的作用是存儲VM層的存儲模型，這是從實施協議分離（VMFS或NFS）的虛擬機的低層。
VMFS協議實現了存儲資源的虛擬化，再分配各VMs
卷存儲
實例存儲有它的限制，開發人員通常希望分離實例數據，例如OS和安裝的一些伺服器應用程序和用戶數據，這樣重建VM的時候可以保留用戶的數據。
這個需求衍生出另外一種存儲模型：卷存儲。卷是存儲的主要單元，相當於虛擬磁碟分區。它不是虛擬機實例的一部分，它可以被認為是虛擬機的外部存儲設備。
該卷可以從一個VM卸載，然後附加到另一個VM。通過這種方式，我們實現了實例數據與用戶數據的分離。OpenStack的煤渣是一個體積存儲的實現。
除了實例存儲和卷存儲之外，最後我們還提到另一種特殊的虛擬存儲：對象存儲。
對象存儲
很多雲應用需要在不同的VM之間共享數據，它常常需要跨越多個數據中心，而對象存儲可以解決這個問題。在前一篇文章中的雲計算IaaS管理平台的基本功能是什麼？》中曾經提到過對象存儲。
在對象存儲模型中，數據存儲在存儲段（bucket）中，桶也可以被稱為「水桶」，因為它字面意思。我們可以用硬碟來類推，對象像一個文件，而存儲段就像一個文件夾（或目錄）。可以通過統一資源標識符（URI：統一資源標識符）找到對象和存儲段。
對象存儲的核心設計思想實際上是虛擬化，它是文件的物理存儲位置，如卷、目錄、磁碟等，虛擬化是木桶，它將文件虛擬化為對象。對於應用層，簡化了對數據訪問的訪問，屏蔽了底層存儲技術的異構性和復雜性。
對象存儲模型
NAS與對象存儲各有所長
當然你也許會問，NAS存儲技術也是一個可以解決數據共享的問題嗎？由於對象存儲的大小和成本優勢，許多雲環境使用對象存儲而不是NAS。
因為對象存儲將跨多個節點傳播，最新數據並不總是可用的 因此，對象存儲的數據一致性不強。如果有強一致性的要求，然後你可以使用NAS。目前，在雲計算環境中，NAS和對象存儲是共存的。
和NAS一樣，對象存儲也是軟體體系結構，而不是硬體體系結構。應用程序通過REST API直接訪問對象存儲。公共對象存儲包括：Amazon S3和OpenStack的Swift。
結語
在實際的雲平台應用中，我們需要根據自己的實際情況來合理運用不同的虛擬化存儲技術。
對於非結構化的靜態數據文件，如音視頻、圖片等，我們一般使用對象存儲。
對於系統鏡像以及應用程序，我們需要使用雲主機實例存儲或者卷存儲。
對於應用產生的動態數據，我們一般還需要利用雲資料庫來對數據進行管理。
『捌』 北大青鳥java培訓：Java內存模型原理
這篇文章主要介紹模型產生的問題背景，解決的問題，處理思路，相關實現規則，環環相扣，希望讀者看完這篇文章後能對Java內存模型體系產生一個相對清晰的理解，知其然知其所以然。
內存模型產生背景在介紹Java內存模型之前，java課程http://www.kmbdqn.cn/認為應該先了解一下物理計算機中的並發問題，理解這些問題可以搞清楚內存模型產生的背景。
物理機遇到的並發問題與虛擬機中的情況有不少相似之處，物理機的解決方案對虛擬機的實現有相當的參考意義。
物理機的並發問題硬體的效率問題計算機處理器處理絕大多數運行任務都不可能只靠處理器「計算」就能完成，處理器至少需要與內存交互，如讀取運算數據、存儲運算結果，這個I/O操作很難消除(無法僅靠寄存器完成所有運算任務)。
由於計算機的存儲設備與處理器的運算速度有幾個數量級的差距，為了避免處理器等待緩慢的內存完成讀寫操作，現代計算機系統通過加入一層讀寫速度盡可能接近處理器運算速度的高速緩存。
緩存作為內存和處理器之間的緩沖：將運算需要使用到的數據復制到緩存中，讓運算能快速運行，當運算結束後再從緩存同步回內存之中。
緩存一致性問題基於高速緩存的存儲系統交互很好的解決了處理器與內存速度的矛盾，但是也為計算機系統帶來更高的復雜度，因為引入了一個新問題：緩存一致性。
在多處理器的系統中(或者單處理器多核的系統)，每個處理器(每個核)都有自己的高速緩存，而它們有共享同一主內存(MainMemory)。
當多個處理器的運算任務都涉及同一塊主內存區域時，將可能導致各自的緩存數據不一致。
為此，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議進行操作，來維護緩存的一致性。
『玖』 魔獸爭霸模型載入問題
魔獸爭霸3 地圖的游戲載入畫面背景是一個 *.mdx 文件. 所有魔獸3的單位3D模型都是這種文件。
這種模型由兩部分組成, 一是存儲模型坐標動畫等各種信息的MDX文件, 還有就是BLP或者TGA貼圖文件(或者叫蒙皮,就是包裹模型的皮膚).
兩部分都得正確才能顯示出模型來.
注: BLP是暴雪開發的一種模型貼圖壓縮格式, TGA是一種常見的圖片格式. 可以用ACDsee或者PhotoShop來轉換格式.
用PhotoShop保存為TGA格式的時候一般選為24位,若是需要透明效果則選32位. 建議勾上"壓縮RLE"以減小文件大小.
若希望製作自己的載入畫面, 有兩種辦法:
一種是下載現成的載入畫面模型,將其中的貼圖文件修改成自己想要的樣子.
另一種就是用3DMAX來完全自己製作, 當然這個比較復雜. 僅適合有製作過魔獸模型的朋友
現成載入畫面修改：
這里我整理和製作了幾種載入畫面放到這個ZIP包里。請下載後選擇自己適合的MDX和對應的TGA文件。
1.修改將要顯示的tga圖片文件為你需要的內容。
圖象編輯通常工具用: WINDOWS畫圖, PhotoShop, CorelDRW......
2.導入你的地圖中(注意導入後的tga文件路徑為根目錄)
打開WE,按"F12" 打開輸入文件管理器. 導入相應的MDX和貼圖文件.
3.指定運用該MDX文件為載入畫面。
WE的菜單里 "情節->地圖讀取設定" ,選"使用輸入的文件". 然後選中導入的載入畫面MDX文件.保存地圖後就可以察看效果了.
=========================================
LoadingScreen.mdx
4張圖片顯示地圖載入畫面左上,右上,下左,下右四個區域,其餘區域為黑色背景.
圖片路徑為:
LoadingScreenTL.tga (左上, 尺寸: 512*512)
LoadingScreenTR.tga (右上, 尺寸: 512*512)
LoadingScreenBL.tga (下左, 尺寸: 512*256)
LoadingScreenBR.tga (下右, 尺寸: 512*256)
Loading.mdx
一張圖片顯示整個地圖載入畫面. 圖片路徑為: LoadingScreenTL.tga
建議圖片尺寸為:1024*768 /800*600 /640*480 /512*384
Loading 2.mdx
一張圖片顯示地圖載入畫面左上方區域,其餘區域為黑色背景. 圖片路徑為: LoadingScreenTL.tga
建議圖片尺寸為:512*512 或 256*256
BOOMmapLoad.mdx
水元素動態效果的地圖載入畫面. (動態效果演示)
全部共使用魔獸爭霸3自帶的8張圖片,無須再導入 圖片路徑為: Textures\Lords0000.blp ~~~ Textures\Lords0007.blp
BOOMmapLoad2.mdx
群星閃爍動態效果的地圖載入畫面. (動態效果演示)
使用魔獸爭霸自帶的的"Textures\Star7b.blp"圖片作為星星, 另外需要導入一張路徑為"LoadingscreenTL.tga"的512*512圖片作為顯示內容.
3DMAX製作魔獸3載入畫面要求:
製作魔獸3模型只能是3DMAX4或5。需要安裝 WarcraftIIIArtTools1.01 這些常識就不說了。
講一下地圖載入畫面和一般模型區別的特殊之處：
3DMAX中僅僅很小一部分區域顯示為地圖載入畫面的屏幕。
他們是從坐標: X=0, Y=0, Z=0, 到 X= 0.6 , Y= -0.8, Z=0。也就是第4象限靠著原點一個很小的矩形。
（有點奇怪的是3DMAX中的坐標和MDL文件中的坐標方向不一樣， 當然我們不用管他）
貼圖同一般的魔獸貼圖，但貼圖材質必須要勾上"Unshaded"才能顯示出來。否則是看不到的。
可以加個軌跡還有動畫片段：如 Birth。也可以不加。建議加上吧。
=================
1月份的時候我應某某要求地圖需要載入畫面中加入一些LOGO，搜索了網上都是些用現成的MDX來修改，我就想既然是魔獸模型那麼應該可以用3DMAX來自己做個動態的，於是進行嘗試卻發現不少問題。經過反復實驗總算找到了其中規律，在此分享給大家。相信很快就能在網路上看到各種漂亮的載入畫面。