㈠ 計算機中數據存儲的基本單位有哪些
常用的單位還有KB,MB,GB,TB
1TB=1024GB, 1GB=1024MB, 1MB=1024KB, 1KB=1024B
㈡ 對象存儲系統的與傳統存儲的比較
有大量的基於塊和基於文件的存儲系統可供選擇，一個明顯的問題是，我們為什麼需要另外一種存儲技術呢？塊和文件都是成熟且經過驗證的，所以也許看起來好像他們可以增強以滿足日益增長的分布式雲計算生態系統的需求。
基於塊的存儲系統，磁碟塊通過底層存儲協議訪問，像SCSI命令，開銷很小而且沒有其它額外的抽象層。這是訪問磁碟數據最快的方式，所有高級別的任務，像多用戶訪問、共享、鎖定和安全通常由操作系統負責。換句話講，基於塊的存儲關心所有底層的問題，但其它事情都要依靠高層的應用程序實現。所有的對象存儲擁有基於塊存儲的節點，利用對象存儲軟體集合提供所有其它的功能。
基於塊的存儲系統是對象存儲系統的補充，而基於文件的存儲系統一般被認為是直接的競爭者。橫向擴展的NAS系統的關鍵屬性就是擴展性，對象存儲也是這樣，通過增加節點實現水平擴展。但由於NAS系統是基於分層文件結構的有限的命名空間，它們對於有著接近無限擴展能力的、具有扁平結構的純對象存儲來講，所受的約束更多，對象存儲僅受到對象ID的位數限制。盡管限制多多，但橫向擴展的NAS系統仍然具備對象存儲的諸多特性，而其欠缺的功能，像對於表徵狀態轉移（REST）協議的支持，廠商們正在快速的完善中，這樣他們就可以把橫向擴展的NAS系統劃歸到對象存儲的類別中了。
㈢ 手機如何設置存儲SD卡優先
1.打開手機設置，選擇「高級設置」；
(3)數據存儲位置可作為SLA擴展閱讀：
相機SD卡的保養常識：
1、如SD卡在相機正常使用後，在電腦上查看所拍照片。需翻轉所查看的照片的時候，先把照片復制到電腦上再進行操作，若直接在卡裡面修改後，再次把卡放在相機里查看相關圖片，會出現無法查看該照片的情況，大量的圖片被修改後有可能會使SD卡「癱瘓」，要格式化後才能再正常使用。
2、SD卡在相機裡面拍攝過程中如出現卡機、死機的情況，可能是該SD卡有故障的情況或壽命已到，請用讀卡器把卡裡面的內容導出來保存再進行格式化（如果是要壞的卡讀取、復制的時候會慢很多）。格式化完後有的能正常使用，可以用一些修復軟體，它會把壞的地方分為單獨的一個分區，然後再隱藏。但建議別再存放重要的數據使用，因為其他的地方也可能飽經風霜，馬上就要故障了。
3、如果使用的時候不小心把SD卡折壞掉或摔壞不能用時，別急著把那「報廢」的卡扔掉，小心地拆開SD卡表面時，你就會看到裡面還「藏」著一個小小的TF卡，可供大部分的手機使用，也可以配個SD卡的TF轉接卡口繼續使用。
網路-SD卡
㈣ 數據存儲方式
數據存儲方式有以下幾種：
（1）順序存儲方法。該方法把邏輯上相鄰的結點存儲在物理位置上相鄰的存儲單元里，結點間的邏輯關系由存儲單元的鄰接關系來體現。由此得到的存儲表示稱為順序存儲結構 （Sequential Storage Structure ），通常藉助程序語言的數組描述。該方法主要應用於線性的數據結構。非線性的數據結構也可通過某種線性化的方法實現順序存儲。
（2）鏈接存儲方法。該方法不要求邏輯上相鄰的結點在物理位置上亦相鄰，結點間的邏輯關系由附加的指針欄位表示。由此得到的存儲表示稱為鏈式存儲結構（Linked Storage Structure）, 通常藉助於程序語言的指針類型描述。
（3）索引存儲方法。該方法通常在儲存結點信息的同時，還建立附加的索引表。 索引表由若干索引項組成。若每個結點在索引表中都有一個索引項，則該索引表稱之為稠密索引（Dense Index ）。
（4）散列存儲方法，該方法的基本思想是根據結點的關鍵字直接計算出該結點的存儲地址。
㈤ android 數據存儲的幾種方式
總體的來講，數據存儲方式有三種：一個是文件，一個是資料庫，另一個則是網路。其中文件和資料庫可能用的稍多一些，文件用起來較為方便，程序可以自己定義格式；資料庫用起稍煩鎖一些，但它有它的優點，比如在海量數據時性能優越，有查詢功能，可以加密，可以加鎖，可以跨應用，跨平台等等；網路，則用於比較重要的事情，比如科研，勘探，航空等實時採集到的數據需要馬上通過網路傳輸到數據處理中心進行存儲並進行處理。 對於Android平台來講，它的存儲方式也不外乎這幾種，按方式總體來分，也是文件，資料庫和網路。但從開發者的角度來講它可以分為以下五種方式： 1.SharedPreferences共享偏好 2.Internal Storage內部存儲空間 3.External Storage外部存儲空間 4.SQLite Database資料庫 5.Internet網路 這幾種方式各自有各自的優點和缺點，要根據不同的實際情況來選擇，而無法給出統一的標准。下面就各種方式談談它們的優缺點，以及最合適的使用情況： 1.Shared Preferences共享偏好 SharedPreferences是用來存儲一些Key/Value類似的成對的基本數據類型，注意，它只能存儲基本數據類型，也即int, long, boolean, String, float。事實上它完全相當於一個HashMap，唯一不同的就是HashMap中的Value可以是任何對象，而SharedPreferences中的值只能存儲基本數據類型(primitive types)。 對於它的使用方法，可以參考Android Developer Guide，這里不重復。 如此來看，最適合SharedPreferences的地方就是保存配置信息，因為很多配置信息都是Key/Value。事實上，在Android當中SharedPreferences使用最多的地方也是用來保存配置（Settings）信息，系統中的Settings中這樣，各個應用中的Settings也是這樣。並且，Android中為了方便的使用SharedPreferences保存配置信息，它來專門有PreferenceActivity用來封裝。也就是說如果你想在應用程序中創建配置（Settings），你可以直接使用PreferenceActivity和一些相關的專門為Preference封裝的組件，而不用再直接去創建，讀取和保存SharedPreference，Framework中的這些組件會為你做這些事。 再談談一些使用SharedPreference時的技巧，它只能保存基本數據類型，但假如我想保存一個數組，怎麼辦？可以把數據進行處理，把它轉化成一個String，取出的時候再還原就好了；再如，如想保存一個對象，怎麼辦，同樣，可以把對象序列化成為字元序列，或轉成String（Object.toString()），或是把它的HashCode（Object.hashCode()）當成Value保存進去。 總之，SharedPreferences使用起來十分的方便，可以靈活應用，因為它簡單方便，所以能用它就盡量不要用文件或是資料庫。 1.Internal Storage內部存儲空間 所謂的內部存儲與外部存儲，是指是否是手機內置。手機內置的存儲空間，稱為內部存儲，它是手機一旦出廠就無法改變，它也是手機的硬體指標之一，通常來講手機內置存儲空間越大意味著手機價格會越貴(很多地方把它稱為手機內存，但我們做軟體的知道，這並不準確，內存是指手機運行時存儲程序，數據和指令的地方；這里應該是手機內部存儲的簡稱為內存，而並非嚴格意義上的內存)。 內部存儲空間十分有限，因而顯得可貴，所以我們要盡可能避免使用；另外，它也是系統本身和系統應用程序主要的數據存儲所在地，一旦內部存儲空間耗盡，手機也就無法使用了。所以對於內部存儲空間，我們要盡量避免使用。上面所談到的Shared Preferences和下面要談到的SQLite資料庫也都是存儲在內部存儲空間上的。 Android本身來講是一個Linux操作系統，所以它的內部存儲空間，對於應用程序和用戶來講就是「/data/data"目錄。它與其他的（外部的存儲）相比有著比較穩定，存儲方便，操作簡單，更加安全（因為可以控制訪問許可權）等優點。而它唯一的缺點就是它比較有限，比較可貴。 雖然，可以非常容易的知道程序本身的數據所在路徑，所有的應用程序的數據路徑都是「/data/data/app-package-name/」，所有的程序用到的數據，比如libs庫，SharedPreferences都是存放在這個路徑下面。但我們在使用的時候最好不要，或是千萬不要直接引用這個路徑。 使用內部存儲主要有二個方式，一個是文件操作，一個是文件夾操作。無論哪種方式，Context中都提供了相應的函數來支持，使用Context不但操作簡單方便，最重要的是Context會幫助我們管理這些文件，也可以方便幫助我們控制文件的訪問許可權。先來系統的說下Context中關於文件和文件夾操作的函數有哪些。 a. 創建一個文件，並打開成一個文件輸出流，需要提供一個String，作為文件名 1.FileOutputStream output = Context.openOutputFile(filename， Context.MODE_PRIVATE); 2.output.write(data）；// use output to write whatever you like 3.output.close(); 1.FileOutputStream output = Context.openOutputFile(filename， Context.MODE_PRIVATE); output.write(data）；// use output to write whatever you like output.close(); b. 同樣，想打開一個文件作為輸入的話，也是只需要提供文件名 1.FileInputStream input = Context.openInputFile(filename); 2.input.read(); 3.input.close(); 1.FileInputStream input = Context.openInputFile(filename); input.read(); input.close(); c. 列出所有的已創建的文件 1.String[] files = Context.fileList(); 2.for (String file : files) ｛ 3. Log.e(TAG, "file is " + file); 4.} 1.String[] files = Context.fileList(); for (String file : files) ｛ Log.e(TAG, "file is " + file); } d. 刪除文件，能創建就要能夠刪除，當然也會提供了刪除文件的介面，它也非常簡單，只需要提供文件名 1.if (Context.deleteFile(filename)) { 2. Log.e(TAG, "delete file " + filename + " sucessfully「); 3.} else { 4. Log.e(TAG, "failed to delete file " + filename); 5.} 1.if (Context.deleteFile(filename)) { Log.e(TAG, "delete file " + filename + " sucessfully「); } else { Log.e(TAG, "failed to delete file " + filename); } e. 獲取文件已創建文件的路徑，它返回一個文件對象用於操作路徑 1.File fileDir = Context.getFileDir(); 2.Log.e(TAG, "fileDir " + fileDir.getAbsolutePath(); 1.File fileDir = Context.getFileDir(); Log.e(TAG, "fileDir " + fileDir.getAbsolutePath(); f. 創建一個目錄，需要傳入目錄名稱，它返回 一個文件對象用到操作路徑 1.File workDir = Context.getDir(dirName, Context.MODE_PRIVATE); 2.Log.e(TAG, "workdir " + workDir.getAbsolutePath(); 1.File workDir = Context.getDir(dirName, Context.MODE_PRIVATE); Log.e(TAG, "workdir " + workDir.getAbsolutePath(); g. 以File對象方式查看所創建文件，需要傳入文件名，會返迴文件對象 1.File store = Context.openFileStreamPath(filename); 2.Log.e(TAG, "store " + store.length()); 1.File store = Context.openFileStreamPath(filename); Log.e(TAG, "store " + store.length()); h. 獲取Cache路徑，無需要傳入參數，返迴文件對象 1.File cachedir = Context.getCacheDir(); 2.Log.e(TAG, "cachedir " + cacheDir.getAbsolutePath()); 1.File cachedir = Context.getCacheDir(); Log.e(TAG, "cachedir " + cacheDir.getAbsolutePath()); 總結一下文件相關操作，可以得出以下三個特點： 1. 文件操作只需要向函數提供文件名，所以程序自己只需要維護文件名即可； 2. 不用自己去創建文件對象和輸入、輸出流，提供文件名就可以返回File對象或輸入輸出流 3. 對於路徑操作返回的都是文件對象。 如前所述，內部存儲空間有限，可貴，安全，穩定，所以應該用來保存比較重要的數據，比如用戶信息資料，口令秘碼等不需要與其他應用程序共享的數據。也可以用來創建臨時文件，但一定要注意及時刪除。另外，對於內部存儲還有一個非常重要的特點，那就是在應用程序被卸載時，應用程序在內部存儲空間的文件數據將全部被刪除。系統這樣做的原因很簡單，就是因為內部存儲很有限，它必須保證它的可用性，因為一旦添滿，系統將無法再正常工作。 1.External Storage外部存儲空間 再來談談手機外部存儲空間，與內部存儲空間相對，外部存儲空間是指手機出廠的時候不存在，用戶在使用時候可以自由添加的外部存儲介質比如TS卡，SD卡等快閃記憶體儲介質。這些快閃記憶體介質由最初的空間小價格貴，到現在的大容量價格便宜，所以幾乎每個支持外部存儲的手機上面都有大容量（大於等於2G）的快閃記憶體卡。 Android也是不例外，它完全支持外部存儲介質。其實更確切的說，它是要依賴於外部存儲卡的，因為對於Android系統，如果沒有外部存儲卡，很多的系統應用無法使用，比如多媒體相關的應用程序無法使用。雖然Android很依賴，但是外部存儲卡也有它自身的特點，它最大的優點就是存儲空間大，基本上你可無限制的使用，也不怎麼擔心去清除數據。就目前來看，很多程序都在使用外部存儲卡，但很少有程序去主動清理數據，所以無論你的SD卡有多大，它的可用空間卻越來越少。與內部存儲不同的是，當程序卸載時，它在外部存儲所創建的文件數據是不會被清除的。所以清理外部存儲空間的責任丟給了用戶自己，每隔一段時間就去查看下SD卡，發現無用數據立馬刪除。外部存儲的缺點就是不是很穩定，對於Android手機來講可以說，很不穩定，本身快閃記憶體介質就容易出問題，SD卡處於不能正常使用的狀態十分多。 先來說說外部存儲相關的使用方法和API： a. Check media availability檢查介質的可用性 如前所述，外部存儲介質的穩定性十分的差，所以在使用之前一定要先檢查它的可用性，如果可用再去用 view plain to clipboardprint? 1.final String state = Environment.getExternalStorageState(); 2.if (state.equals(Environment.MEDIA_MOUNTED) || state.equals(Environment.MEDIA_READ_ONLY)) {// sd card is ready to us } view plain to clipboardprint? 1.final String state = Environment.getExternalStorageState(); if (state.equals(Environment.MEDIA_MOUNTED) || state.equals(Environment.MEDIA_READ_ONLY)) {// sd card is ready to us } final String state = Environment.getExternalStorageState(); if (state.equals(Environment.MEDIA_MOUNTED) || state.equals(Environment.MEDIA_READ_ONLY)) {// sd card is ready to us } b. Get the directory獲取外部存儲卡的路徑 事實上，外部存儲卡的路徑是「/mnt/sdcard"，所以你直接這樣寫去訪問也能訪問的到。鑒於可讀性和可移植性的考慮，建議這樣寫： view plain to clipboardprint? 1.File sdcardDir = Environment.getExternalStorageDirectory(); view plain to clipboardprint? 1.File sdcardDir = Environment.getExternalStorageDirectory(); File sdcardDir = Environment.getExternalStorageDirectory(); c. For API 8 or greater, there are some other useful APIs helping to manager files and directories. 如果你使用API 8(Android 2.2)或者更高，那麼SDK中又多了幾個操作外部存儲文件和路徑的介面，文檔中也建議開始者更加規范的使用SD卡。比如，創建相應的目錄去存儲相應的數據，Music，Picture，Video等。應用程序目錄也變成了"/Android/data/package-name/data"。具體的使用可以參考文檔，這里不重復。當然，就像編程規范一樣，這里只是規范，你完全可以不遵守它，但出於可讀性和可移植性，還是建議按照文檔建議的去做。 下面總結一下使用時應該注意的一些和外部存儲的特點： a. 外部存儲卡不是隨時想用就能夠用的，所以一定要記得在使用之前檢查它的可用性 b. 存儲在外部存儲卡上的數據是所有應用程序都可見，用戶也可見（使用FileManager），所以安全性不是很好，雖然文檔聲稱可以在外部存儲卡上寫程序私有數據，但貌似沒用，用FileManager仍然可以刪除或編輯文件（Market上面的FileManager功能都十分的強大，能讓用戶看到SD卡中的所有文件，和操作能看到的文件）。 c. Android手機支持把外部存儲卡Mount至PC做為U盤，當連接數據線時，這時SD卡變成了U盤連接到了另外的操作系統中。什麼意思，就是在Android當中雖然有的文件屬性（隱藏，私有等），到了PC上就不一定管用了，用戶在PC上可以隨意操作文件（這就是第二點中所提及的）。 d. 如果使用外部存儲卡保存數據，一定要額外做好異常處理：外部存儲卡不可用時把數據存入哪裡；可用的時候再怎麼同步數據（這是比較頭疼的地方，可行的做法就是當SD卡不可用時不準用戶寫數據，但這用戶體驗又不是很好，但如你所知，很多應用都這么干）；你的數據被破壞了。當然常見的異常也要考慮，比如空間滿了，無法寫入，磁碟壞道等。 1.SQLite Database資料庫 Android對資料庫的支持很好，它本身集成了SQLite資料庫，每個應用都可以方便的使用它，或者更確切的說，Android完全依賴於SQLite資料庫，它所有的系統數據和用到的結構化數據都存儲在資料庫中。 它具有以下優點： a. 效率出眾，這是無可否認的 b. 十分適合存儲結構化數據 c. 方便在不同的Activity，甚至不同的應用之間傳遞數據 先前有一篇文章講到了不同Activity和不同應用之間傳遞數據的麻煩，特別是對於大型數據結構，因為Activity雖是Java對象，但去無法像使用其他類對象那樣去創建一個實例然後使用它，更無法給Activity加上Setters和Getters（雖然這樣做了沒有編譯錯誤）。比較好的解決方案就是把結構化數據寫入資料庫，然後在不同的Activity之間傳遞它們的Uri。 d. 由專門的ContentProvider來幫忙管理和維護資料庫 e. 可以方便的設置訪問許可權，私有還是都可見 f. 操作方便，使用標準的CRUDE語句，ContentResolver.query(), update(), delete() insert()，詳見ContentResolver g. 良好的可移植性和通用性，用標準的SQL語句就能實現CRUDE 對於它的使用方法可以去參考文檔，這里也說不清楚。 1.Internet網路 網路是比較不靠譜的一個，因為移動終端的網路穩定性，以及所產生的流量讓人傷不起，用戶更傷不起。但若是對於非常重要的實時數據，或是需要發送給遠端伺服器處理的，也可以考慮使用網路實時發送。這已經有先例了，Apple和Google就是這樣，iPhone設備和Android設備都會在用戶不知情的情況 下收集用戶的信息，然後又在用戶不知情的情況 下發送到Apple和Google的伺服器上，也就是所謂的「跟蹤門」。除此之外，智能手機（特別是Android和火熱的iPhone）上面的應用程序都會偷偷的在後台運行，收集用戶數據，然後再偷偷的發伺服器，直接傷害是用戶流量，請看先前的文章。 對比這幾種方式，可以總結下： 1. 簡單數據和配置信息，SharedPreference是首選； 2. 如果SharedPreferences不夠用，那麼就創建一個資料庫 3. 結構化數據，一定要創建資料庫，雖然這稍顯煩鎖，但是好處無窮 4. 文件就是用來存儲文件(也即非配置信息或結構化數據)，如文本文件，二進制文件，PC文件，多媒體文件，下載的文件等等。 5. 盡量不要創建文件 6. 如果創建文件，如果是私密文件或是重要文件，就存儲在內部存儲，否則放到外部存儲 7. 不要收集用戶數據，更不要發到網路上，雖然你們也有很多無奈。用戶也無奈，也無辜，但更無助 平台為開發者准備了這么多的方式固然是一件好事，但我們要認清每一種的優點和缺點，根據實際情況選擇最合適的。還有一個原則就是最簡單原則，也就是說能用簡單的方式處理，就不要用復雜的方式。
㈥ 數據存儲的三類簡介
一、DAS(Direct Attached Storage)直接附加存儲，DAS這種存儲方式與我們普通的PC存儲架構一樣，外部存儲設備都是直接掛接在伺服器內部匯流排上，數據存儲設備是整個伺服器結構的一部分。
DAS存儲方式主要適用以下環境：
(1)小型網路
因為網路規模較小，數據存儲量小，且也不是很復雜，採用這種存儲方式對伺服器的影響不會很大。並且這種存儲方式也十分經濟，適合擁有小型網路的企業用戶。
(2)地理位置分散的網路
雖然企業總體網路規模較大，但在地理分布上很分散，通過SAN或NAS在它們之間進行互聯非常困難，此時各分支機構的伺服器也可採用DAS存儲方式，這樣可以降低成本。
(3)特殊應用伺服器
在一些特殊應用伺服器上，如微軟的集群伺服器或某些資料庫使用的原始分區，均要求存儲設備直接連接到應用伺服器。
(4)提高DAS存儲性能
在伺服器與存儲的各種連接方式中，DAS曾被認為是一種低效率的結構，而且也不方便進行數據保護。直連存儲無法共享，因此經常出現的情況是某台伺服器的存儲空間不足，而其他一些伺服器卻有大量的存儲空間處於閑置狀態卻無法利用。如果存儲不能共享，也就談不上容量分配與使用需求之間的平衡。
DAS結構下的數據保護流程相對復雜，如果做網路備份，那麼每台伺服器都必須單獨進行備份，而且所有的數據流都要通過網路傳輸。如果不做網路備份，那麼就要為每台伺服器都配一套備份軟體和磁帶設備，所以說備份流程的復雜度會大大增加。
想要擁有高可用性的DAS存儲，就要首先能夠降低解決方案的成本，例如：LSI的12Gb/s SAS，在它有DAS直聯存儲，通過DAS能夠很好的為大型數據中心提供支持。對於大型的數據中心、雲計算、存儲和大數據，所有這一切都對DAS存儲性能提出了更高的要求，雲和企業數據中心數據的爆炸性增長也推動了市場對於可支持更高速數據訪問的高性能存儲介面的需求，因而LSI 12Gb/s SAS正好是能夠滿足這種性能增長的要求，它可以提供更高的IOPS和更高的吞吐能力，12Gb/s SAS提高了更高的寫入的性能，並且提高了RAID的整個綜合性能。
與直連存儲架構相比，共享式的存儲架構，比如SAN（storage-area network）或者NAS（network-attached storage）都可以較好的解決以上問題。於是乎我們看到DAS被淘汰的進程越來越快了。可是到2012年為止，DAS仍然是伺服器與存儲連接的一種常用的模式。事實上，DAS不但沒有被淘汰，近幾年似乎還有回潮的趨勢。 二、NAS(Network Attached Storage)數據存儲方式
NAS(網路附加存儲)方式則全面改進了以前低效的DAS存儲方式。它採用獨立於伺服器，單獨為網路數據存儲而開發的一種文件伺服器來連接所存儲設備，自形成一個網路。這樣數據存儲就不再是伺服器的附屬，而是作為獨立網路節點而存在於網路之中，可由所有的網路用戶共享。
NAS的優點：
(1)真正的即插即用
NAS是獨立的存儲節點存在於網路之中，與用戶的操作系統平台無關，真正的即插即用。
(2)存儲部署簡單
NAS不依賴通用的操作系統，而是採用一個面向用戶設計的，專門用於數據存儲的簡化操作系統，內置了與網路連接所需要的協議，因此使整個系統的管理和設置較為簡單。
(3)存儲設備位置非常靈活
(4)管理容易且成本低
NAS數據存儲方式是基於現有的企業Ethernet而設計的，按照TCP/IP協議進行通信，以文件的I/O方式進行數據傳輸。
NAS的缺點：
(1)存儲性能較低(2)可靠度不高 三、SAN(Storage Area Network)存儲方式
1991年，IBM公司在S/390伺服器中推出了ESCON(Enterprise System Connection)技術。它是基於光纖介質，最大傳輸速率達17MB/s的伺服器訪問存儲器的一種連接方式。在此基礎上，進一步推出了功能更強的ESCON Director(FC SWitch)，構建了一套最原始的SAN系統。
SAN存儲方式創造了存儲的網路化。存儲網路化順應了計算機伺服器體系結構網路化的趨勢。SAN的支撐技術是光纖通道(FC Fiber Channel)技術。它是ANSI為網路和通道I/O介面建立的一個標准集成。FC技術支持HIPPI、IPI、SCSI、IP、ATM等多種高級協議，其最大特性是將網路和設備的通信協議與傳輸物理介質隔離開，這樣多種協議可在同一個物理連接上同時傳送。
SAN的硬體基礎設施是光纖通道，用光纖通道構建的SAN由以下三個部分組成：
(1)存儲和備份設備：包括磁帶、磁碟和光碟庫等。
(2)光纖通道網路連接部件：包括主機匯流排適配卡、驅動程序、光纜、集線器、交換機、光纖通道和SCSI間的橋接器
(3)應用和管理軟體：包括備份軟體、存儲資源管理軟體和存儲設備管理軟體。
SAN的優勢：
(1)網路部署容易；
(2)高速存儲性能。因為SAN採用了光纖通道技術，所以它具有更高的存儲帶寬，存儲性能明顯提高。SAn的光纖通道使用全雙工串列通信原理傳輸數據，傳輸速率高達1062.5Mb/s。
(3)良好的擴展能力。由於SAN採用了網路結構，擴展能力更強。光纖介面提供了10公里的連接距離，這使得實現物理上分離，不在本地機房的存儲變得非常容易。 DAS、NAS和SAN三種存儲方式比較
存儲應用最大的特點是沒有標準的體系結構，這三種存儲方式共存，互相補充，已經很好滿足企業信息化應用。
從連接方式上對比，DAS採用了存儲設備直接連接應用伺服器，具有一定的靈活性和限制性；NAS通過網路（TCP/IP,ATM,FDDI）技術連接存儲設備和應用伺服器，存儲設備位置靈活，隨著萬兆網的出現，傳輸速率有了很大的提高；SAN則是通過光纖通道（Fibre Channel）技術連接存儲設備和應用伺服器，具有很好的傳輸速率和擴展性能。三種存儲方式各有優勢，相互共存，佔到了磁碟存儲市場的70%以上。SAN和NAS產品的價格仍然遠遠高於DAS.許多用戶出於價格因素考慮選擇了低效率的直連存儲而不是高效率的共享存儲。
客觀的說，SAN和NAS系統已經可以利用類似自動精簡配置（thin provisioning）這樣的技術來彌補早期存儲分配不靈活的短板。然而，之前它們消耗了太多的時間來解決存儲分配的問題，以至於給DAS留有足夠的時間在數據中心領域站穩腳跟。此外，SAN和NAS依然問題多多，至今無法解決。
㈦ SLA在電腦中是什麼意思
SLA：Service-Level Agreement的縮寫，意思是服務等級協議。
是關於網路服務供應商和客戶間的一份合同，其中定義了服務類型、服務質量和客戶付款等術語。
項目
典型的SLA 包括以下項目：
分配給客戶的最小帶寬；
客戶帶寬極限；
能同時服務的客戶數目；
在可能影響用戶行為的網路變化之前的通知安排；
撥入訪問可用性；
運用統計學；
服務供應商支持的最小網路利用性能，如99.9%有效工作時間或每天最多為1分鍾的停機時間；
各類客戶的流量優先權；
客戶技術支持和服務；
懲罰規定，為服務供應商不能滿足 SLA 需求所指定。
要求
按照 SLA 要求，服務供應商採用多種技術和解決方案去監控和管理網路性能及流量，以滿足 SLP 中的相關需求，並產生對應的客戶結果報告。
另一方面，客戶本身也提出了自己的技術及解決方案去監控鄰居的流量和服務，以確保提供他們答應的傳送服務項目。
SLA概念已被大量企業所採納，作為公司 IT 部門的內部服務。大型企業的 IT 部門都規范了一套服務等級協議，以衡量、確認他們的客戶（企業其他部門的用戶）服務，有時也與外部網路供應商提供的服務進行比較。
1)IP SLA
Service Level Agrement(服務等級協議）在ISP領域指的是用戶和服務提供商簽訂的服務等級合同。用戶可以享受什麼樣的等級什麼樣的帶寬服務等等。當然此處我們探討的和這個無關，我們主要對企業網路環境中應用SLA的作用做探討。[1]
2) 靜態浮動路由
浮動靜態路由是一種靜態路由，在主路由失效時，提供備份路由。但在主路由存在的情況下它不會出現在路由表中。浮動靜態路由主要用於拔號備份.
3) IP SLA功能
-檢測路由器之間的網路性能。
-量化當前網路的性能，健康狀況。
-評估現有網路的服務質量。
-幫助用戶分析，排除網路故障。
-和浮動靜態路由，HSRP等技術結合做track功能（工程中應用較多的實例）
4) IP SLA原理
通過發送測試報文，對網路性能，服務質量進行分析，並為用戶提供網路服務質量的各種參數，例如：
抖動延遲，文件傳輸速率，TCP時延等。
測試
測試SLA以確保提供商承諾的服務水平有如下方式：
第一種方法是向提供商提出一個實際問題，這能使您對支持過程和工作人員熟練度有一定的掌握。也有助於驗證非工作時間內「7x24」或「8x5」服務的真正意義。
第二種方法是談論提供商所接觸的其他客戶。某些時候在一些事情上會出現錯誤，但外包服務提供商會做出如何反應。他們是否會提供實時性更新通知嗎？問題如果已解決，供應商將告訴你一個真實的情況。一般情況下，您將聽到好的消息和問題如何得到解決的例子。
第三種方法是檢查提供商的現行做法。例如：簽署一份包含數據中心空間、運行時間、溫度和濕度的SLA。需查看項目設備維護記錄。通過看報告，可以確定，其發電機的「定期測試」每年只有兩次。此外，也能夠驗證HVAC和UPS系統已經處於延遲維護狀態。以此確定選擇這個提供商是不明智的，盡管提供的設施表現足夠好，但是沒有文件備份。
外包SLA是服務提供商和客戶之間關系的基石。但至關重要的是，企業要了解SLA中的各項條款，還要知道如何在SLA談判中從提供商那裡獲得有利的條款。同樣重要的是，提供商要盡職盡責的確保客戶在正常運行時間的臨界條件。[2]
服務協議編輯
定義
SLA服務水平協議（簡稱：SLA，全稱：service level agreement）是在一定開銷下為保障服務的性能和可靠性，服務提供商與用戶間定義的一種雙方認可的協定。通常這個開銷是驅動提供服務質量的主要因素。
內容
一個完整的SLA同時也是一個合法的文檔，包括所涉及的當事人、協定條款(包含應用程序和支持的服務)、違約的處罰、費用和仲裁機構、政策、修改條款、報告形式和雙方的義務等。同樣服務提供商可以對用戶在工作負荷和資源使用方面進行規定。
保障
傳統上，SLA包含了對服務有效性的保障，譬如對故障解決時間、服務超時等的保證。但是隨著更多的商業應用在Internet的廣泛開展，越來越需要SLA對性能（如響應時間）作出保障。這種需要將會隨著越來越多的商業在Internet 的開展而重要起來。實際上，SLA的保障是以一系列的服務水平目標（SLO）的形式定義的。服務水平目標是一個或多個有限定的服務組件的測量的組合。一個SLO被實現是指那些有限定的組件的測量值在限定范圍里。SLO有所謂的操作時段，在這個時間范圍內，SLO必須被實現。但是由於Internet的統計特性，不可能任何時候都能實現這些保障。因此SLA一般都有實現時間段和實現比例。實現比例被定義為SLA必須實現的時間與實現時段的比值。例如：在工作負荷<100 transaction/s前提下，早上8點到下午5點服務響應時間<85ms，服務有效率>95%，在一個月內的總體實現比例 >97%。
監測
[3] 1、輕松監控SLA的先決條件
簽署SLA，會有一下形式：IaaS、PaaS和SaaS，分別是基礎設施即服務、平台即服務和軟體即服務。企業應該確保它們能對所有簽署的SLA的進行監控。
比如說，IT託管服務商景安網路使用多種工具來監控SLA和基礎設施的可用性。這些工具能夠監控性能和基礎設施、容量的健康狀況趨勢，並作出報告。
2、第三方監控
審計是很重要的一步，能夠確保安全，保證SLA的承諾和責任歸屬，保持需求合規。企業可以用第三方監控。如果企業在雲中運行業務關鍵的應用，這項服務應該保持定期審查，確保合規，敦促廠商與SLA步調一致。
對於不合規的處罰和SLA違反，我們只能基於服務信用。未來可以通過綁定業務級別SLA來作為彌補。
3、轉換SLA，幫助整個業務成果
盡管雲計算市場正在迅猛增長，中小企業的IT大多數都不夠成熟，不足以支撐基於基礎設施的SLA來幫助義務發展。企業應該選擇最適合業務需求的SLA，而不是急急忙忙簽署協議。
如果企業操之過急，直接選擇基礎設施級別的SLA，可能會由公司內部產生很多話費。比如說，某企業想要99.999%的高可用性，服務商就會提供更多冗餘和災難恢復，結果花費大幅提高。
當聚焦於節儉型業務級別SLA時，雲計算SLA監控應該具有邏輯性和可行性，而不僅僅是基礎設施級別的SLA。
4、確保告警裝置
為了讓SLA監控更高效，你得確保可用性和責任時間通過Web portal定期報告。企業應該保證及時的e-mail告警。
5、確保廠商有高效的後備設施
不同的廠商對於數據保護的系統也不同。但是有的廠商會把該職責推給客戶，這樣的話客戶只好自己保護數據。因此企業應該確定服務商在簽署SLA時，是否對此負有責任。
你可以問這些問題：廠商用什麼裝置保護數據？廠商是否在後端復制鏡像？有快照嗎？災難恢復計劃是否有效？未授權的人能否訪問數據？
6、確保服務商的生態系統
選擇廠商時，要看看它的生態系統是否整合了SI、ISP、IaaS/PaaS供應商。如果一個雲供應商只關注單一的基礎設施級別或者PaaS，不會關注別的，那就可能不適合長遠發展。
對於雲管理即服務，第三方解決方案可以考慮用來進行雲SLA監控，它能以每秒為單位檢查問題，畢竟災難常常源於細節問題。
服務標准
一、緊急情況
當網站發生伺服器宕機，資料庫無法讀寫等一級緊急事件時，網站維護方應當在1小時內響應，2小時內協助解決該情況。並在因外部原因無法立即解決時（例如伺服器所在機房受到黑客攻擊，伺服器硬碟讀寫失敗等事件），向客戶報告情況並提供具體解決的時間。成熟的網站建設公司對於緊急情況通常都會有一套完善的應急解決方案，幫助客戶及時解決突發事件，最大程度的挽救因網站無法訪問導致的損失。
二、重要情況
網站正式上線過程後，有時會出現在驗收過程中沒有察覺的bug，這個時候，建站企業應當積極協助客戶解決該bug，具體的響應時間根據bug造成的影響程度而定。根據SLA服務標准，bug的等級亦可進行進一步的劃分並制定相應的解決方案。這里不予以贅述。
三、標准情況
在網站設計和網站編碼階段，因設計師和程序員協作環節的不一致性，有可能出現網頁的樣式問題和兼容性問題。以及由於客戶臨時需求的變更和新增，都會對正式運行的網站產生新的維護需求。按照需求的難易性和工作量制定相應的響應標准，是保證客戶滿意度的關鍵所在，也是SLA服務標准體系當中的重要環節。
四、次要情況
包括頁面上一些細節的小調整，如個別文字、樣式上的調整，圖片的更替等等，通常在24小時內響應，雙方商議的時間內進行解決即可。當然，SLA服務體系的出發點是為IT服務提供完善、標准、科學的解決方案，任何忽略細節的處理方式都有可能影響客戶滿意度。[4]
SLA的可量化
SLA的協定有一個很重要的關注點，即SLA的「可測量性」與「測量方法」，有一些運維服務商與客戶協商一些復雜的指標，但這些指標在合同周期內是根本無法進行測量的，這種SLA的協定就喪失了意義，無法測量就意味著根本無法知道執行情況、無法計算執行結果，也無從改善與控制，這是一方面，另一方面，當我們確定了一些指標後，這些指標的計算方法與測量方法也是需要注意的，這些要與客戶商定清楚，避免了有指標，但最後的測量方法雙方不一致，導致最終的達成結果出現偏差而發生糾紛。
雲計算SLA
SLA概念已被大量企業所採納，作為公司IT部門的內部服務。
雲計算SLA現狀
許多IT經理正在考慮把許多應用及服務遷移進雲端。一部分人因為經濟原因被迫考慮雲計算，而另外一部分人考慮提供一些新的IT服務。不管怎樣，IT經理不久的將來不得不面對服務等級協議（SLA）[5] 。
對於許多IT經理來說，評估SLA是不容易的。畢竟大多數的SLA都是一些條款形式的內容，人們很難確定某個運營商實際能夠提供哪些服務。而且SLA的提出主要是為了保護運營商的利益，而不是針對客戶，這樣使整個事情變得更為復雜。許多運營商提供SLA主要是為了避免一些不必要的糾紛和訴訟，同時提供給客戶最小限度的保證。也就是說，當其企業選擇了一個雲運營商並且對那些服務進行有效的安排之後，SLA同樣能夠成為IT經理一種有效的工具。
IT經理需要關注SLA的三個方面：數據保護，連續性和費用開銷。毋庸置疑，數據保護是最需要關注的一個要素。IT經理想要確認誰有權使用這些數據。剛開始確定數據保護的級別似乎很容易，但是還是有很多隱藏的問題。IT經理必須查出這些問題並且解決他們。
這些問題進一步的升級就涉及到了知識產權保護問題。所有的問題最後都歸結為誰最終能夠控制客戶的這些私有數據。
一個IT經理需要明白如何利用運營商的基礎構架和服務來為那些必須的應用和數據提供連續不斷的保護。業務不間斷性非常重要。最理想的情形是運營商保證提供100%的不間斷服務，但實際上這樣的保證是不可能實現的。
所有的服務提供商都將會經歷在某一時刻宕機的情況，因為有很多超出他們控制范圍的情況發生，包括自然災害以及社會生活中發生的一些不確定因素。大部分的服務提供商最多能夠給予99.5%正常運行時間的保證。但是這些保證通常還附帶另外一些限制條件。即便如此，運營商可以盡力保證這些服務在一個可接受的層次范圍之內。
一些運營商都將價格要素包含在他們的SLA中，其餘的則將這些費用放置在一些獨立的合同條款中。不管怎樣，IT經理必須明白這些費用包含在基於雲的服務中。這些費用不僅僅和預算有關，而且通常被用來確定投資收益率。價格分析通常都是財務部門的任務，但是IT經理能夠幫助加速這個過程，或許還能夠為那些花費在雲服務上的費用提供一些簡單合理的解釋。
找到這些問題的的答案並牢記以上要點能夠幫助IT經理作出一些有理有據的決定。當他們選擇一個服務提供商並且打算和提供商建立長期合作的時候，這些決定能夠同時保證服務的有效以及可靠。所有這些歸結起來都是為了簡化關於服務等級協議（SLA）的描述，並且給大家提供SLA的一個通俗概念。
評估雲計算SLA的另一個問題是無法讓所有相關參與者都確保SLA。雲計算工作流程通常涉及三方——企業本地自有網路的員工、讓員工訪問雲計算的網路供應商以及雲計算供應商。具體可能還涉及企業的數據中心（網路與託管）和提供「雲計算至數據中心」連接的另一家網路供應商。供應商通常不會撰寫或接受用於處理他們所不涉及工作流程環節的SLA。你需要讓他們同意成為他們為此收取一定費用的「主要承包商」或者為所涉及的每一方得到或編寫一份SLA。
通常SLA中的最大問題是網路連接問題，因為在大多數情況下，除了在雲計算本身內部的情況外，雲計算供應商是不會提供網路服務。如果你希望嚴格的SLA，那麼你將需要為網路服務編制一份SLA。所以，你應當首先確認你的雲計算供應商是否會提供一個VPN或者他們是否能夠與你所使用VPN服務的供應商進行協作。在很多情況下，你仍然需要使用互聯網來實現用戶的連接性，但是VPN將為你提供一個你希望獲得保證的堅實網路邊界。[6]
簽署雲計算SLA當注意事項
沒有人能夠確定所有與企業防火牆外機密或私有信息存儲（雲計算）相關的法律風險。但是，越來越多的輿論認為，企業用戶應當要求雲計算供應商來維護一個安全的IT環境，以規避與雲計算相關的潛在法律風險。一般來說，與雲計算相關的關注領域類似於傳統IT的關注領域：
· 傳輸與存儲期間的數據安全；
· 數據的私密性和保密；
· 一般訪問、地方政府訪問以及電子查詢的權利；
· 數據所有權；
· 服務的暫停與終止；
· 與雲計算供應商共同協商和制定服務等級協議（SLA）。
因為許多領先的雲計算供應商是擁有更為龐大客戶群的實體，SLA的處罰細節並不總是可以通過談判解決的。通常情況下，SLA只是在「要就拿走，不要拉倒」基礎上提出的簡單形式。因此，你應當考慮的第一個問題是你是否願意把貴公司的數據放到一個你無法掌控的環境中。如果你對此感到無所適從，我建議你找一個供應商一起來討論服務條款細節。
雲計算存儲的新手，可以考慮優先順序的數據存儲。通過首先遷移非核心數據，許多公司開始了雲計算化的實施。這個策略可使他們試用這一服務，並確定該服務是否具有成本效益而不會擔心影響核心業務功能。例如，一個剛剛接觸雲計算技術的律師事務所可能會決定，在把特殊機密的客戶信息遷往標准網路防火牆外之前，可以嘗試先把後台管理系統信息（如薪金、雇員福利）放置在雲中。
雲計算SLA和點菜選項
要求敏感數據駐留在私有雲中既然雲計算的目的在於通過設施共享實現規模經濟效益，那麼這可能並不是一個合適的定義；但是，有可能出現這樣的場景，即使用專用雲計算基礎設施才是有意義的。尋找特殊的數據加密技術。如果信息特別的敏感，那麼你可能需要雲計算供應商來提供額外的保護。
數據存儲所在地的地域限制。出於法律或與客戶相關的目的，你可能不希望數據存儲在執法不嚴格或法律不確定的海外。
獨特的服務等級。如果你的企業有特殊的數據訪問和使用的需求，不要猶豫，請向你的雲計算供應商請求特殊服務。對違反協議條款的特殊處罰。如果對於你或你的客戶來說，違犯數據私密性處以特殊處罰是非常重要的，請直接向他們提出。
處理雲計算供應商所有權變更的規定。雲計算市場總是出於快速的變化中。你可能需要在你的SLA中增加所有權變更或不可轉讓的條款。在這樣的規定中，你可能需要澄清雲計算供應商永遠不得擁有你委託他們管理的數據，即便在你決定更換供應商時。
關於發生災難事件時業務連續性的規定。你需要知道在發生地震、海嘯或其它自然災害事件時對你的數據的影響。 除了這些條款之外，你可能還需要增加傳統的IT外包合同條款，其中你已逐漸習慣的電子查詢和違犯處罰，諸如：
· 基於預定義標准——內容、發件人和/或收件人、日期范圍和元數據的搜索；
· 與任意元數據相關的存儲搜索；
· 從搜索結果中新增和刪除，以創建一個電子查詢集。
㈧ 數據存儲形式有哪幾種
【塊存儲】
典型設備：磁碟陣列，硬碟
塊存儲主要是將裸磁碟空間整個映射給主機使用的，就是說例如磁碟陣列裡面有5塊硬碟（為方便說明，假設每個硬碟1G），然後可以通過劃邏輯盤、做Raid、或者LVM（邏輯卷）等種種方式邏輯劃分出N個邏輯的硬碟。（假設劃分完的邏輯盤也是5個，每個也是1G，但是這5個1G的邏輯盤已經於原來的5個物理硬碟意義完全不同了。例如第一個邏輯硬碟A裡面，可能第一個200M是來自物理硬碟1，第二個200M是來自物理硬碟2，所以邏輯硬碟A是由多個物理硬碟邏輯虛構出來的硬碟。）
接著塊存儲會採用映射的方式將這幾個邏輯盤映射給主機，主機上面的操作系統會識別到有5塊硬碟，但是操作系統是區分不出到底是邏輯還是物理的，它一概就認為只是5塊裸的物理硬碟而已，跟直接拿一塊物理硬碟掛載到操作系統沒有區別的，至少操作系統感知上沒有區別。
此種方式下，操作系統還需要對掛載的裸硬碟進行分區、格式化後，才能使用，與平常主機內置硬碟的方式完全無異。
優點：
1、 這種方式的好處當然是因為通過了Raid與LVM等手段，對數據提供了保護。
2、 另外也可以將多塊廉價的硬碟組合起來，成為一個大容量的邏輯盤對外提供服務，提高了容量。
3、 寫入數據的時候，由於是多塊磁碟組合出來的邏輯盤，所以幾塊磁碟可以並行寫入的，提升了讀寫效率。
4、 很多時候塊存儲採用SAN架構組網，傳輸速率以及封裝協議的原因，使得傳輸速度與讀寫速率得到提升。
缺點：
1、採用SAN架構組網時，需要額外為主機購買光纖通道卡，還要買光纖交換機，造價成本高。
2、主機之間的數據無法共享，在伺服器不做集群的情況下，塊存儲裸盤映射給主機，再格式化使用後，對於主機來說相當於本地盤，那麼主機A的本地盤根本不能給主機B去使用，無法共享數據。
3、不利於不同操作系統主機間的數據共享：另外一個原因是因為操作系統使用不同的文件系統，格式化完之後，不同文件系統間的數據是共享不了的。例如一台裝了WIN7/XP，文件系統是FAT32/NTFS，而Linux是EXT4，EXT4是無法識別NTFS的文件系統的。就像一隻NTFS格式的U盤，插進Linux的筆記本，根本無法識別出來。所以不利於文件共享。
【文件存儲】
典型設備：FTP、NFS伺服器
為了克服上述文件無法共享的問題，所以有了文件存儲。
文件存儲也有軟硬一體化的設備，但是其實普通拿一台伺服器/筆記本，只要裝上合適的操作系統與軟體，就可以架設FTP與NFS服務了，架上該類服務之後的伺服器，就是文件存儲的一種了。
主機A可以直接對文件存儲進行文件的上傳下載，與塊存儲不同，主機A是不需要再對文件存儲進行格式化的，因為文件管理功能已經由文件存儲自己搞定了。
優點：
1、造價交低：隨便一台機器就可以了，另外普通乙太網就可以，根本不需要專用的SAN網路，所以造價低。
2、方便文件共享：例如主機A（WIN7，NTFS文件系統），主機B（Linux，EXT4文件系統），想互拷一部電影，本來不行。加了個主機C（NFS伺服器），然後可以先A拷到C，再C拷到B就OK了。（例子比較膚淺，請見諒……）
缺點：
讀寫速率低，傳輸速率慢：乙太網，上傳下載速度較慢，另外所有讀寫都要1台伺服器裡面的硬碟來承擔，相比起磁碟陣列動不動就幾十上百塊硬碟同時讀寫，速率慢了許多。
【對象存儲】
典型設備：內置大容量硬碟的分布式伺服器
對象存儲最常用的方案，就是多台伺服器內置大容量硬碟，再裝上對象存儲軟體，然後再額外搞幾台服務作為管理節點，安裝上對象存儲管理軟體。管理節點可以管理其他伺服器對外提供讀寫訪問功能。
之所以出現了對象存儲這種東西，是為了克服塊存儲與文件存儲各自的缺點，發揚它倆各自的優點。簡單來說塊存儲讀寫快，不利於共享，文件存儲讀寫慢，利於共享。能否弄一個讀寫快，利 於共享的出來呢。於是就有了對象存儲。
首先，一個文件包含了了屬性（術語叫metadata，元數據，例如該文件的大小、修改時間、存儲路徑等）以及內容（以下簡稱數據）。
以往像FAT32這種文件系統，是直接將一份文件的數據與metadata一起存儲的，存儲過程先將文件按照文件系統的最小塊大小來打散（如4M的文件，假設文件系統要求一個塊4K，那麼就將文件打散成為1000個小塊），再寫進硬碟裡面，過程中沒有區分數據/metadata的。而每個塊最後會告知你下一個要讀取的塊的地址，然後一直這樣順序地按圖索驥，最後完成整份文件的所有塊的讀取。
這種情況下讀寫速率很慢，因為就算你有100個機械手臂在讀寫，但是由於你只有讀取到第一個塊，才能知道下一個塊在哪裡，其實相當於只能有1個機械手臂在實際工作。
而對象存儲則將元數據獨立了出來，控制節點叫元數據伺服器（伺服器+對象存儲管理軟體），裡面主要負責存儲對象的屬性（主要是對象的數據被打散存放到了那幾台分布式伺服器中的信息），而其他負責存儲數據的分布式伺服器叫做OSD，主要負責存儲文件的數據部分。當用戶訪問對象，會先訪問元數據伺服器，元數據伺服器只負責反饋對象存儲在哪些OSD，假設反饋文件A存儲在B、C、D三台OSD，那麼用戶就會再次直接訪問3台OSD伺服器去讀取數據。
這時候由於是3台OSD同時對外傳輸數據，所以傳輸的速度就加快了。當OSD伺服器數量越多，這種讀寫速度的提升就越大，通過此種方式，實現了讀寫快的目的。
另一方面，對象存儲軟體是有專門的文件系統的，所以OSD對外又相當於文件伺服器，那麼就不存在文件共享方面的困難了，也解決了文件共享方面的問題。
所以對象存儲的出現，很好地結合了塊存儲與文件存儲的優點。
最後為什麼對象存儲兼具塊存儲與文件存儲的好處，還要使用塊存儲或文件存儲呢？
1、有一類應用是需要存儲直接裸盤映射的，例如資料庫。因為資料庫需要存儲裸盤映射給自己後，再根據自己的資料庫文件系統來對裸盤進行格式化的，所以是不能夠採用其他已經被格式化為某種文件系統的存儲的。此類應用更適合使用塊存儲。
2、對象存儲的成本比起普通的文件存儲還是較高，需要購買專門的對象存儲軟體以及大容量硬碟。如果對數據量要求不是海量，只是為了做文件共享的時候，直接用文件存儲的形式好了，性價比高。