快閃記憶體資料庫
① 快閃記憶體中能存儲什麼樣的資料庫Access 或者 MySQL.這二個行不行
Access
② 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. 不要收集用戶數據，更不要發到網路上，雖然你們也有很多無奈。用戶也無奈，也無辜，但更無助 平台為開發者准備了這么多的方式固然是一件好事，但我們要認清每一種的優點和缺點，根據實際情況選擇最合適的。還有一個原則就是最簡單原則，也就是說能用簡單的方式處理，就不要用復雜的方式。
③ 全快閃記憶體有哪些應用
全快閃記憶體主要應用在資料庫加速（OracleOLTP）、VDI（VMware）、伺服器虛擬化（VMware）、SAPHANATDI解決方案等場景。華為OceanStorDoradoV3企業級全快閃記憶體存儲系統，滿足資料庫、虛擬化等企業級應用對高性能、高可靠、高效率存儲的需求，助力金融、製造、運營商等行業向快閃記憶體時代平滑演進。
④ 條碼列印機的內存和快閃記憶體的作用是什麼
內存是用來運作主機發送指令的臨時儲存設備，列印機一關機指令就消失了，比如電腦的內存大小會影響它的工作量大小。而快閃記憶體就相當於電腦的硬碟，它可以永久性的儲存一些東西，例如廠商給條碼列印機安裝的一些字型檔之類的。通俗的理解就是，內存只能運行臨時數據，而快閃記憶體可以永久保存。
⑤ 數據存儲的介質
（1）結構化數據，簡單來說就是資料庫。結合到典型場景中更容易理解，比如企業ERP、財務系統；醫療HIS資料庫；政府行政審批；其他核心資料庫等。這些應用需要哪些存儲方案呢？基本包括高速存儲應用需求、數據備份需求、數據共享需求以及數據容災需求。
（2）非結構化資料庫是指其欄位長度可變，並且每個欄位的記錄又可以由可重復或不可重復的子欄位構成的資料庫，用它不僅可以處理結構化數據（如數字、符號等信息）而且更適合處理非結構化數據（全文文本、圖像、聲音、影視、超媒體等信息）。
面對海量非結構數據存儲，杉岩海量對象存儲MOS，提供完整解決方案，採用去中心化、分布式技術架構，支持百億級文件及EB級容量存儲，具備高效的數據檢索、智能化標簽和分析能力，輕松應對大數據和雲時代的存儲挑戰，為企業發展提供智能決策。
⑥ 華為全快閃記憶體在資料庫加速場景的應用
Oracle是當前主流大型企業最常用的資料庫軟體，承載企業大多數業務系統的關鍵數據，如今的信息爆炸給Oracle資料庫系統帶來了性能和成本的巨大挑戰。華為OceanStorDoradoV3全快閃記憶體資料庫加速方案提供強勁性能，幫助在線交易類業務規模提升3倍，減少I/O等待時間，提升存儲和伺服器的資源利用率，顯著減少OracleLicense費用。採用橫向擴展架構提供可預測的線性增長性能，滿足未來不可預期的業務增長。提供豐富的數據保護服務，保障核心應用7x24穩定在線。
⑦ 存儲器的類型
根據存儲材料的性能及使用方法的不同，存儲器有幾種不同的分類方法。1、按存儲介質分類：半導體存儲器：用半導體器件組成的存儲器。磁表面存儲器：用磁性材料做成的存儲器。
下面我們就來了解一下存儲器的相關知識。
存儲器大體分為兩大類，一類是掉電後存儲信息就會丟失，另一類是掉電後存儲信息依然保留，前者專業術語稱之為「易失性存儲器」，後者稱之為「非易失性存儲器」。
1 RAM
易失性存儲器的代表就是RAM（隨機存儲器），RAM又分SRAM（靜態隨機存儲器）和DRAM（動態隨機存儲器）。
SRAM
SRAM保存數據是靠晶體管鎖存的，SRAM的工藝復雜，生產成本高，但SRAM速度較快，所以一般被用作Cashe，作為CPU和內存之間通信的橋梁，例如處理器中的一級緩存L1 Cashe, 二級緩存L2 Cashe，由於工藝特點，SRAM的集成度不是很高，所以一般都做不大，所以緩存一般也都比較小。
DRAM
DRAM（動態隨機存儲器）保存數據靠電容充電來維持，DRAM的應用比SRAM更普遍，電腦裡面用的內存條就是DRAM，隨著技術的發展DRAM又發展為SDRAM（同步動態隨機存儲器）DDR SDRAM（雙倍速率同步動態隨機存儲器），SDRAM只在時鍾的上升沿表示一個數據，而DDR SDRAM能在上升沿和下降沿都表示一個數據。
DDR又發展為DDR2,DDR3,DDR4，在此基礎上為了適應移動設備低功耗的要求，又發展出LPDDR(Low Power Double Data Rate SDRAM)，對應DDR技術的發展分別又有了LPDDR2, LPDDR3, LPDDR4。
目前手機中運行內存應用最多的就是 LPDDR3和LPDDR4，主流配置為3G或4G容量，如果達到6G或以上，就屬於高端產品。
2 ROM
ROM(Read Only Memory)在以前就指的是只讀存儲器，這種存儲器只能讀取它裡面的數據無法向裡面寫數據。所以這種存儲器就是廠家造好了寫入數據，後面不能再次修改，常見的應用就是電腦里的BIOS。
後來，隨著技術的發展，ROM也可以寫數據，但是名字保留了下來。
ROM中比較常見的是EPROM和EEPROM。
EPROM
EPROM(Easerable Programable ROM)是一種具有可擦除功能，擦除後即可進行再編程的ROM內存，寫入前必須先把裡面的內容用紫外線照射IC上的透明視窗的方式來清除掉。這一類晶元比較容易識別，其封裝中包含有「石英玻璃窗」，一個編程後的EPROM晶元的「玻璃窗」一般使用黑色不幹膠紙蓋住， 以防止遭到紫外線照射。
EPROM (Easerable Programable ROM)
EPROM存儲器就可以多次擦除然後多次寫入了。但是要在特定環境紫外線下擦除，所以這種存儲器也不方便寫入。
EEPROM
EEPROM(Eelectrically Easerable Programable ROM)，電可擦除ROM，現在使用的比較多，因為只要有電就可擦除數據，再重新寫入數據，在使用的時候可頻繁地反復編程。
FLASH
FLASH ROM也是一種可以反復寫入和讀取的存儲器，也叫快閃記憶體，FLASH是EEPROM的變種，與EEPROM不同的是，EEPROM能在位元組水平上進行刪除和重寫而不是整個晶元擦寫，而FLASH的大部分晶元需要塊擦除。和EEPROM相比，FLASH的存儲容量更大。
FLASH目前應用非常廣泛，U盤、CF卡、SM卡、SD/MMC卡、記憶棒、XD卡、MS卡、TF卡等等都屬於FLASH，SSD固態硬碟也屬於FLASH。
NOR FLAHS & NAND FLASH
Flash又分為Nor Flash和Nand Flash。
Intel於1988年首先開發出Nor Flash 技術，徹底改變了原先由EPROM和EEPROM一統天下的局面；隨後，1989年，東芝公司發表了Nand Flash 結構，強調降低每比特的成本，有更高的性能，並且像磁碟一樣可以通過介面輕松升級。
Nor Flash與Nand Flash不同，Nor Flash更像內存，有獨立的地址線和數據線，但價格比較貴，容量比較小；而Nand Flash更像硬碟，地址線和數據線是共用的I/O線，類似硬碟的所有信息都通過一條硬碟線傳送一樣，而且Nand Flash與Nor Flash相比，成本要低一些，而容量大得多。
如果快閃記憶體只是用來存儲少量的代碼，這時Nor Flash更適合一些。而Nand Flash則是大量數據存儲的理想解決方案。
因此，Nor Flash型快閃記憶體比較適合頻繁隨機讀寫的場合，通常用於存儲程序代碼並直接在快閃記憶體內運行，Nand Flash型快閃記憶體主要用來存儲資料，我們常用的快閃記憶體產品，如U盤、存儲卡都是用Nand Flash型快閃記憶體。
在Nor Flash上運行代碼不需要任何的軟體支持，在Nand Flash上進行同樣操作時，通常需要驅動程序。
目前手機中的機身內存容量都比較大，主流配置已經有32G~128G存儲空間，用的通常就是Nand Flash，另外手機的外置擴展存儲卡也是Nand Flash。
⑧ 如何在資料庫應用中發揮SSD的優勢
利用固態硬碟(SSD)技術的優勢設計資料庫應用架構是非常有吸引力的一件事。特別值得注意的是，固態硬碟並行訪問數據的能力已經有了很大的提升。這些提升使得固態硬碟對於許多類型的資料庫應用幾乎能達到了隨機訪問內存存儲的性能，而成本只是其八分之一。
在過去的幾年裡，固態硬碟的性能得到了突飛猛進的增長，同時相比於傳統硬碟和RAM，其成本卻在持續降低。但是要利用好這些改進的優勢，需要掌握存儲特性選擇合適的AWS實例大小，理解應用特性並利用合適的編程語言。
掌握AWS選項
AWS IaaS EC2實例可以配置不同級別的存儲：
A)內存。對應於傳統物理計算機的RAM。
B)實例存儲。也稱為臨時存儲。它對應於傳統物理計算機的磁碟大小。
C)靈活的持久化補充存儲(比如EBS和S3)。基本上可以把它視為物理PC的網路存儲。
Amazon現在把SSD作為部署臨時存儲和通用存儲的默認配置，也是EBS的默認配置(早期的實例類型默認不是SSD)。EBS的其它好處是存儲系統可以在資料庫伺服器本身退役以後仍然繼續可用。
此外，AWS還提供SSD存儲作為Amazon DynamoDB的默認選項。SSD同時也是Amazon RDS和Amazon
Redshift的可選配置。這個配置非常好，它可以降低資料庫應用需要的開發代價。但是，如果企業需要部署其它資料庫，也有很多其它可配置項可以幫助他
們利用到SSD的並行特性。
並行存儲的物理原理
物理計算機通常設置有三種主要存儲類型。RAM安裝在主板上，緊挨著CPU，它提供最高的性能，成本代價也最高，計算機關閉以後內容不會保存。
SSD和傳統硬碟是連接到計算機上的補充存儲，通過PCI-e，SCSI和SATA線纜連接，或者在網路上通過eSATA或者光纖通道連接。
傳統硬碟包含有一個物理讀寫頭，一次可以跨多個物理碟片讀取數據流。如果數據可以順序讀取(比如讀取較大的多媒體視頻音頻文件)，或者對於一些
資料庫分析應用(比如Hadoop應用)，這種模式都非常合適。然而，如果讀取數據要搜索碟片的多個扇區，那麼傳統硬碟讀寫頭的性能會急劇下降。
與此相反，快閃記憶體驅動的物理構成就是成百上千個可以隨機訪問的塊，是由分散的許多晶元組成的，讀取哪一塊的數據不會影響訪問性能。快閃記憶體檔有兩個瓶頸：第一就是計算機處理器和個體晶元儲存區之間的存儲控制器;第二是不能從單個晶元上的不同塊區同時讀取隨機數據。
當今時代的大部分資料庫引擎都沒有利用快閃記憶體檔訪問數據隨機位的功能優勢。其結果是，資料庫都比較慢，或者雖然其訪問模式可以被緩存，但需要更多
RAM才能實現同樣的性能效果。而RAM存儲肯定比快閃記憶體檔速度快，不過對於相同數量的存儲空間，RAM的成本是快閃記憶體檔的十倍。在物理層面上，RAM比
SSD有更好的IO處理能力，但是成本也是其大約三到四倍。這些相對成本也被反映到了Amazon Web服務上可用的不同計算機實例相對成本上。
寫入隊列
利用跨多個晶元並行訪問數據能力優勢的關鍵在於編寫程序時要考慮到隊列深度這一特性。在資料庫應用中增加隊列深度可以使應用從SSD不同個體晶元中並行讀寫數據，這對提高資料庫性能有直接的效果。
如果隊列深度設置過大，訪問同一晶元中不同數據位的可能性就增大了，這也會破壞性能。因此，大部分應用的最佳隊列深度是每驅動器32到64個並
發請求，盡管驅動器本身支持更多並發請求。通過優化資料庫應用訪問SSD的隊列深度，應用程序可以花更少的代價就能達到用更昂貴RAM才能實現的更佳性能
狀態。
在應用層面，開發者需要考慮如何實現應用對存儲系統的請求隊列化，以實現並行處理。但是，軟體方面要獲得較好的並行有許多陷阱。要用像
JavaScript、Ruby和Python這樣的編程語言實現並行是很困難的，因為這些語言對實現多線程支持的不太好，Java和C#相對更容易一
些。
C和C++是實現高並發系統代碼最合適的編程語言，因為它們直接操作操作系統核心功能。例如，互斥擴展(也叫互斥量)就是簡化編程生成低級系統並行調用的語言特性。另一種選擇是使用自帶SSD存儲優化方案的商業資料庫，比如Aerospike。
為應用選擇合適的架構
不是所有的資料庫應用都需要快閃記憶體存儲功能來並行訪問隨機數據。處理大量並發用戶Web請求的資料庫很容易看到快閃記憶體存儲的最大優勢。
與此相反，像Hadoop這種分析應用在某種意義上是並行的，但是通常這些應用最後都需要訪問存儲驅動器上的大量數據流來完成數據訪問。例如，
處理一個月的用戶日誌來分析其行為或者分析用戶，本質上都要按順序提取數據，因此遷移到SSD並不能帶來太多益處。在這兩種極端場景之間，還有一些實時分
析類型的應用，它們既需要一定的隨機搜索和也需要數據流處理。
專家建議，充分利用各種層次成本差異的一種方式是，配置資料庫利用臨時存儲讀取數據以獲得最佳性能。這一點可以通過存儲在EBS持久化數據層的數據進行備份。這種方案提供了AWS上價格和性能的最佳平衡組合。
後台進程也需要考慮
資料庫應用架構師還應該考慮其它細微特徵。要理解資料庫軟體如何利用RAM，如何把數據刷到磁碟，這些對於優化SSD應用配置非常重要。這對於
評估資料庫與文件系統交互的各種方式也非常重要。最明顯的讀負載繁重會有大量後台IO競爭。而其他進程像報表系統、日誌文件生成是需要後台維護的。
要想找到合適的平衡點，專家建議以真實世界部署的強大指標為基準進行參考。這樣可以幫助企業判斷部署和優化SSD系統有多大益處。不過，在RAM和SSD之間選擇，最重要的考慮因素是深刻掌握要處理的數據集大小。
配置合適的SSD和RAM容量有許多種組合，會增加資料庫更高的復雜度。更多的是傳統資料庫系統，它們會部署一台主伺服器和許多備用伺服器用於
故障恢復，除了在磁碟級別的情況它們的配置都很簡單。另一方面，分布式資料庫系統根據節點數量不同，RAM數量和網路設置的不同會有更多的變化。
盡管在大多數情況下，如果你關注技術的力量和資料庫系統的可操作性作為選擇硬體驅動器的考慮因素，那麼你需要比較評估的系統應該相對不會很多。