前言：想要寫出一篇引人入勝的文章？我們特意為您整理了傳統(tǒng)關系數(shù)據(jù)庫與大數(shù)據(jù)庫技術淺談范文，希望能給你帶來靈感和參考，敬請閱讀。

1引言

全球多家研究機構統(tǒng)計數(shù)據(jù)顯示，大數(shù)據(jù)產(chǎn)業(yè)將迎來發(fā)展黃金期，IDC預計，大數(shù)據(jù)和分析市場將從2016年的1300億美元增長到2020年的2030億美元以上，中國報告大廳的大數(shù)據(jù)行業(yè)報告數(shù)據(jù)也說明，自2017年起，未來2-3年的市場規(guī)模增長率將保持在35%左右。大數(shù)據(jù)像空氣一樣，隨處可見，日積月累的海量數(shù)據(jù)不得不讓人們重新考慮大數(shù)據(jù)的存儲和管理。

2傳統(tǒng)關系數(shù)據(jù)庫面臨的挑戰(zhàn)

基于二維關系模型的數(shù)據(jù)庫在數(shù)據(jù)管理的發(fā)展歷程中是一個標志性的時期，數(shù)據(jù)結構化存儲，冗余較低、程序和數(shù)據(jù)具有一定的獨立性、易擴充等特點。隨著Internet技術的發(fā)展，涌現(xiàn)出半結構化、非結構化數(shù)據(jù)，對這些結構復雜的大數(shù)據(jù)的高效實時多維分析的需求越來越多。傳統(tǒng)的關系數(shù)據(jù)庫從70年展至今，雖然應用范圍較廣技術較成熟，但在處理海量數(shù)據(jù)方面還存在許多不足。（1）關系模型結構制約了快速訪問大數(shù)據(jù)的能力。在二維關系表中，依據(jù)屬性的值來檢索相應的元組，受這種方式的束縛，在檢索數(shù)據(jù)過程中，將耗費一定的時間，從而使訪問數(shù)據(jù)的時間較慢。在存儲對象設計上雖然可以使用分區(qū)的方法，提高數(shù)據(jù)訪問沖突，但在大量數(shù)據(jù)的前提下，分區(qū)技術改善的性能較微弱。（2）處理大數(shù)據(jù)的靈活性不足。在應用系統(tǒng)中，用戶的各種查詢需求經(jīng)常發(fā)生變化，不受時間和操作對象的約束，用戶希望隨時隨地都能快速得到反饋結果。關系型數(shù)據(jù)庫需要專門的數(shù)據(jù)庫維護人員對用戶的查詢要求進行優(yōu)化處理，不能及時的反饋給用戶查詢結果，這使得使用關系數(shù)據(jù)庫存儲數(shù)據(jù)的企業(yè)不具備對大數(shù)據(jù)的快速響應能力。（3）處理復雜結構數(shù)據(jù)能力較弱。關系型數(shù)據(jù)庫對現(xiàn)實數(shù)據(jù)的處理常見類型為字符、數(shù)值等，對于半結構化和非結構化數(shù)據(jù)的處理只限于二進制代碼文件的存儲，而現(xiàn)今用戶對復雜結構數(shù)據(jù)的要求上升為識別、檢索和多維分析，如何處理占總數(shù)據(jù)量85%的非結構化數(shù)據(jù)，是許多關系數(shù)據(jù)庫產(chǎn)品需要解決的問題。（4）存儲維護管理PB級數(shù)據(jù)導致成本不斷增加。數(shù)據(jù)量遞增使得企業(yè)在硬件存儲上投資不斷增加，雖然存儲設備的投入成本在逐步降低，但總成本卻在逐步提高。此外，大量復雜結構的數(shù)據(jù)維護工作也給數(shù)據(jù)庫管理員增加了很多負擔。

3大數(shù)據(jù)庫技術

隨著大數(shù)據(jù)技術的日趨完善，各大公司及開源社區(qū)都陸續(xù)了一系列新型數(shù)據(jù)庫來解決海量數(shù)據(jù)的組織、存儲及管理問題。目前，工業(yè)界主流的處理海量數(shù)據(jù)的數(shù)據(jù)庫有四種，分別是列式數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)庫、鍵值數(shù)據(jù)庫及流式數(shù)據(jù)庫。

3.1列式數(shù)據(jù)庫

采用列族存儲數(shù)據(jù)，將經(jīng)常被使用的數(shù)據(jù)放到一個列族中，例如，經(jīng)常會查詢學生的學號和姓名，而不是專業(yè)，這樣把學號和姓名放到一個列族中，專業(yè)放到另一個列族中，該數(shù)據(jù)庫通常用來存儲分布式大數(shù)據(jù)，HBase是列式數(shù)據(jù)庫的典型代表。

3.2內(nèi)存數(shù)據(jù)庫

對數(shù)據(jù)庫中所有數(shù)據(jù)的操作都在內(nèi)存中完成，一般數(shù)據(jù)庫也有一定的緩存機制，對大部分數(shù)據(jù)的操作都包含從外存到內(nèi)存的讀取，這一過程在很大程度上降低了系統(tǒng)的性能。由于在內(nèi)存中的讀/寫是以納秒為單位的，所以內(nèi)存數(shù)據(jù)庫的性能極高，Spark是內(nèi)存數(shù)據(jù)庫的典型代表。

3.3鍵值數(shù)據(jù)庫

該數(shù)據(jù)庫主要借助哈希表的結構，使用一個特定的鍵和一個指向特定數(shù)據(jù)的指針，利用鍵來完成對數(shù)據(jù)庫中數(shù)據(jù)的添加、刪除和查詢操作，這種結構具有很好的擴展性，使系統(tǒng)具有較高的性能，Memcached、Redis、MemcacheDB都是鍵值數(shù)據(jù)庫的典型代表。

3.4流式數(shù)據(jù)庫

基本理念是數(shù)據(jù)的價值會隨著時間的流逝而不斷減少，因此，需要使式數(shù)據(jù)庫來實現(xiàn)流式計算。流式計算處理模式是將源源不斷的數(shù)據(jù)視為數(shù)據(jù)流，它總是盡可能快速地分析最新的數(shù)據(jù)，并給出分析結果，也就是盡可能實現(xiàn)實時計算。典型流式數(shù)據(jù)庫：SparkStreaming、Storm。

4大數(shù)據(jù)SQL

大數(shù)據(jù)查詢分析是基于互聯(lián)網(wǎng)的相關服務的增加、使用和交互模式中的核心問題。由ApacheLucene的創(chuàng)始人DoungCutting使用GFS、Map-Reduce技術支持創(chuàng)建的ApacheHadoop，是一個能夠對大量數(shù)據(jù)進行分布式處理的軟件框架。Hadoop技術無處不在，其發(fā)展得益于Google發(fā)表的關于GFS和MapReduce的論文。在開源世界，ApacheHadoop的分布式文件系統(tǒng)HDFS和HadoopMapReduce完全是谷歌文件系統(tǒng)GFS和MapReduce的開源實現(xiàn)。Hadoop項目已經(jīng)發(fā)展成為一個生態(tài)圈，觸及了大數(shù)據(jù)領域的各個方面。由Google的BigTable和Amazon的Dynamo使用的NoSQL數(shù)據(jù)庫，提倡使用非關系型的數(shù)據(jù)存儲，這一全新的思維的注入，打破了關系型數(shù)據(jù)庫管理系統(tǒng)在商用數(shù)據(jù)庫領域幾十年的統(tǒng)治性地位。

5小結

本文在分析了大數(shù)據(jù)研究現(xiàn)狀后，對傳統(tǒng)關系數(shù)據(jù)庫面臨的挑戰(zhàn)進行了介紹，在此基礎上研究分析了當前主流的大數(shù)據(jù)庫技術以及大數(shù)據(jù)查詢分析。對開發(fā)一個大數(shù)據(jù)庫項目而言，技術是不斷更新變換的，哪種技術能被使用的時間越久，關鍵在于誰的生態(tài)系統(tǒng)更強，能夠高效的應對用戶各種隨機變化的需求。

參考文獻

[1]劉鵬.大數(shù)據(jù)庫[M].電子工業(yè)出版社,2018:1-27.

[2]胡世昆.分布式數(shù)據(jù)庫技術在大數(shù)據(jù)中的應用[J].電子技術與軟件工程,2019(01):153.

[3]蔣暉等.大數(shù)據(jù)技術概論[M].清華大學出版社,2017:38-42.

作者：翟霞 單位：哈爾濱華德學院