資料庫存儲方案

『壹』 資料庫有哪幾種

資料庫有：

1、Mysql是一個關系型資料庫管理系統，由瑞典MySQL AB公司開發，屬於Oracle旗下產品。MySQL是最流行的關系型資料庫管理系統之一，在WEB應用方面，MySQL是最好的RDBMS應用軟體之一。

2、SQL Server是由Microsoft開發和推廣的關系資料庫管理系統（DBMS），它最初是由Microsoft、Sybase和Ashton-Tate三家公司共同開發的，並於1988年推出了第一個OS/2版本。

3、MongoDB是一個基於分布式文件存儲的資料庫。由C++語言編寫。旨在為WEB應用提供可擴展的高性能數據存儲解決方案。

4、Redis（Remote Dictionary Server )，即遠程字典服務，是一個開源的使用ANSIC語言編寫、支持網路、可基於內存亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。

5、memcache是一套分布式的高速緩存資料庫系統，由LiveJournal的Brad Fitzpatrick開發，但目前被許多網站使用以提升網站的訪問速度，尤其對於一些大型的、需要頻繁訪問資料庫的網站訪問速度提升效果十分顯著。

『貳』 mysql 資料庫存儲超長字元串的處理方案

其實你的兩種方案都可以,第二種也挺好的,以前我一般都用方案一那種,都存到資料庫里,我沒有測試過超長字元串存到資料庫中的查詢效率,和內存問題,不過你也可以這兩種方案都用,過大的就存文件,小的就存資料庫,用個欄位做標識就行

『叄』 圖片該如何存儲在資料庫裡面，存放路徑好還是以二進制存放在資料庫里好

從項目的角度上來說，圖片存儲和資料庫存儲都是必須要分離的，
否則這一個模塊就能拖垮你的整個工程。

二進制的存儲方式，已經淘汰了，性能非常差，在以後的資料庫版本里已經取消了這個存儲方式。
存放路徑，是一種非常方便的解決方案，不存在什麼其他的問題，容易管理。
比如，你以前用二進制存儲的一個圖片，又要IO又要緩存的才能展示給用戶看。
現在你保存的是地址，僅僅需要把鏈接提取出來即可，這樣減少了數據訪問上的壓力。

『肆』 根據本講要獲得一個好的資料庫需要什麼

要獲得一個好的資料庫需要資源齊全，界面簡便易用，設計美觀大方。

傳統的資料庫方案並不具備強大的彈性伸縮能力，比如說常見的Oracle，MySQL，PostgreSQL等資料庫，在面對數據量的爆發性的增長時，往往很容易遇到存儲的瓶頸。

因此，不得不選用一些集群方案，如 Oracle RAC、 MySQL Sharding等，但這些解決方案同雲計算的彈性伸縮能力想比，還是會有不小的差距。雲時代用戶需要的是可以隨需應變，彈性支撐各種業務的資料庫系統。

企業的資料庫注意

在雲時代，因為所有的資料庫資源都是分布式存儲的，每個資料庫節點出現問題都是很正常的事情，所以就必須有一種可以實現數據一致性的數據復制方式來保證服務的高可用。

雲資料庫雖然可以做到彈性擴容，但當並發大到一定規模，雲資料庫需要在很高的並發下，依然可以維持系統的穩定。因此，雲時代的資料庫必須有合理的架構設計，才能更好的支持系統的需求。

『伍』 海量數據存儲有哪些方式與方法

杉岩海量對象存儲MOS，針對海量非結構化數據存儲的最優化解決方案，採用去中心化、分布式技術架構，支持百億級文件及EB級容量存儲，

具備高效的數據檢索、智能化標簽和分析能力，輕松應對大數據和雲時代的存儲挑戰，為企業發展提供智能決策。

1、容量可線性擴展，單名字空間達EB級

SandStone MOS可在單一名字空間下實現海量數據存儲，支持業務無感知的存儲伺服器橫向擴容，為爆炸式增長的視頻、音頻、圖片、文檔等不同類型的非結構化數據提供完美的存儲方案，規避傳統NAS存儲的單一目錄或文件系統存儲空間無法彈性擴展難題

2、海量小文件存儲，百億級文件高效訪問

SandStone MOS基於完全分布式的數據和元數據存儲架構，為海量小文件存儲而生，將企業級NAS存儲的千萬文件量級提升至互聯網規模的百億級別，幫助企業從容應對幾何級增長的海量小文件挑戰。

3、中心靈活部署，容災匯聚分發更便捷

SandStone MOS支持多數據中心靈活部署，為企業數據容災、容災自動切換、多分支機構、數據就近訪問等場景提供可自定義的靈活解決方案，幫助企業實現跨地域多活容災、數據流轉、就近讀寫等，助力業務高速發展。

4、支持大數據和AI，統一數據存儲和分析

SandStone MOS內置文件智能化處理引擎，實現包括語音識別、圖片OCR識別、文件格式轉換等批量處理功能，結合標簽檢索能力還可實現語音、證件照片檢索，從而幫助企業更好地管理非結構化數據。同時，SandStone MOS還支持與Hadoop、Spark等大數據分析平台對接，一套存儲即可滿足企業數據存儲、管理和挖掘的需求。

『陸』 資料庫是如何實現數據的存儲的

資料庫的存儲文件是以頁為單位(8K)存儲在硬碟上....
http://blog.csdn.net/feixianxxx/archive/2010/01/24/5249919.aspx

『柒』 數據信息的存儲方式可以分為幾類

（1）結構化數據，簡單來說就是資料庫。結合到典型場景中更容易理解，比如企業ERP、財務系統；醫療HIS資料庫；政府行政審批；其他核心資料庫等。這些應用需要哪些存儲方案呢？基本包括高速存儲應用需求、數據備份需求、數據共享需求以及數據容災需求。
（2）非結構化資料庫是指其欄位長度可變，並且每個欄位的記錄又可以由可重復或不可重復的子欄位構成的資料庫，用它不僅可以處理結構化數據（如數字、符號等信息）而且更適合處理非結構化數據（全文文本、圖像、聲音、影視、超媒體等信息）。
面對海量非結構數據存儲，杉岩海量對象存儲MOS，提供完整解決方案，採用去中心化、分布式技術架構，支持百億級文件及EB級容量存儲，具備高效的數據檢索、智能化標簽和分析能力，輕松應對大數據和雲時代的存儲挑戰，為企業發展提供智能決策。

『捌』 圖像的資料庫存儲都有什麼方法詳細點的。謝謝。

建議圖片和文字說明分表存儲，因為表中存在
text、ntext、image
數據類型的欄位時，表查詢的速度非常慢...
怎麼將圖片和文字說明存入資料庫...不懂什麼意思...根據我理解的意思回答下吧，BDE和ADO的話，建議使用ADO，一個是BDE不太穩定，雖然速度快一點，再一個，ADO不但穩定，而且運行過一次後，查詢相對BDE慢也未必感覺出來...

『玖』 誰知道資料庫優化設計方案有哪些

本文首先討論了基於第三範式的資料庫表的基本設計，著重論述了建立主鍵和索引的策略和方案，然後從資料庫表的擴展設計和庫表對象的放置等角度概述了資料庫管理系統的優化方案。
關鍵詞： 優化（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。當然最好利用系統的默認段。另外，利用段可以使備份和恢復數據更加靈活，使系統授權更加靈活。